I'm working on a small app on Windows.
It uses CImage to write a PNG file on disk.
It just goes like this:
CImage theImage;
...
theImage.Save("D:\\xxx.png");
After the file was written on the disk and I clicked the close button on the top-right corner to exit the program. The console showed me a message like this:
Thread 0x**** has exited with code 1 (0x1)
Program "[*****] xxx.exe" has exited with code 0 (0x0).
Code 0x1 should indicate an error, right? Seems something wrong happened when the thread created by CImage::Save was writing the file.
The image file is perfectly on the disk, nothing wrong with it. And I checked the return value of Save, it also indicated success.
I have walked through all my code and I'm sure it is definitely caused by the invocation of CImage::Save, if I don't call it, this message never pops up. That is, the console would look like this:
Program "[*****] xxx.exe" has exited with code 0 (0x0).
I did some search and I found this post, but they didn't work it out either.
Even though the program didn't crash, but this message still annoys me.
Any idea? Thanks a lot.
"Code 0x1 should indicate an error, right?"
Only in the most abstract meaning of 'error'. Whoever authored the creation and destruction of the thread decided what value to return, and what that value meant. Could be that someone used some library that required cleanup which didn't get done in time, or another of 1000 possible causes. Not something to spend time on.
Related
I'm working on a Windows Store app and I'm getting a WinRT error that doesn't really give me any information so I would like to know how to understand these sorts of errors.
Basically I get the error on the following line which is called inside OnPointerPressed:
m_gestureRecognizer->ProcessDownEvent(args->GetCurrentPoint(nullptr));
The error is:
First-chance exception at 0x76F54B32 (KernelBase.dll) in DXAML2.exe: 0x40080201: WinRT originate error (parameters: 0x80070057, 0x00000044, 0x03CEE72C).
This error didn't used to appear, the only thing I've changed is that this line is now wrapped in an if clause which tests if the current pointer's PointerId is the same as one I've stored just using == such as:
if(args->GetCurrentPoint(nullptr)->PointerId == m_UIPointerID)
I have no idea why this has started happening.
So my question is in two parts:
More generally, how do I understand what an error such as the above means?
And does anyone know this error has suddenly started happening now that I check the pointerId?
Thanks for your time.
P.S. I guess another thing that has changed is that there will already be 2 pointers on the screen (the one that gets pushed into this GestureRecognizer) as well as another one, hence the PointerId check.
"How to Decipher such an error"...
For any WinRT originate error, you can take the third address in the parameters list (in your example, 0x03CEE72C), and find a description of your error in the memory window.
While debugging, break when your error is thrown and open the memory window via Debug -> Windows -> Memory -> Memory 1
Copy and paste the address to get your "easy-to-find" error message.
As Raman said - it's good to look up the hex values shown. The first one is the memory location which won't tell you much without the symbols/source, which in this case is reported directly by Windows. Perhaps the public symbols can shed some more light on where the error came from, but the error code lookups are more helpful.
If you Bing for 0x80070057 you will find an MSDN article on Common HRESULT Values which lists
E_INVALIDARG : One or more arguments are not valid : 0x80070057
It doesn't give you all the details of course, so you're off to theorize. Perhaps you can only call args->GetCurrentPoint(nullptr) once and you should store/reuse the value? Maybe gesture recognizer is not configured correctly? Maybe the app window is not visible at the time the exception is thrown or the thread is wrong. Maybe some expected calls to gesture recognizer were missed due to filtering those out with these "if" statements.
Appropriate code provided below. I had this working once but have since messed up due to having to change some of the other code. Can't figure out what I've done. The encrypt function creates a thread and makes a call to function EncryptProc to process one or more files. Once each file is completed it should print the name to a textctrl. In the codes current state it waits until all threads/files are processed before printing. It then prints evrything in one go. During processing the textctrl also completely disappears. Any help would be much appreciated as its starting to drive me nuts, lol.
---EDIT---
CODE REMOVED
There should be no GUI access from within threads - in your case EncryptProc is writing to the text control directly - you need to either:
Use CallAfter in the thread to update the text control after the thread exits or
Raise custom event an event in the thread that carries the file name information
and have a hander in the main thread that updates the text control
on receiving the event.
Okay so my MFC application was working fairly well until I cleared the application from the system registry. Now I am unable to run the program. Whenever I try running the program I get an exception. Checking the stack I noticed that CreateEx in LoadFrame for CMainFrame was crushing. This crash occurs when ProcessShellCommand is called in the derived CwinApp of the application.However, I have not been able to pinpoint the exact cause of the crash. I have a hunch it might have something to do with the loading of resource but I don't know exactly how. I have checked the .rc include file and it looks fine to me. I just don't understand how clearing the registry could cause such a mess. Been at it for the past 4 hours.
So basically I am asking if any of you have faced this problem before, and how did you managed to fix it without starting right from scratch? I am not sure of the exact part of the code I should put here to clarify my question so I hope this is clear enough.
Thanks
I have problem with me51n. I have an include in EXIT_SAPLMEREQ_010 that has a bunch of codes which we use it to receive errors. The problem of mine is;
-When i run me51n with required datas(mat. number, quantity, etc.) I get some errors which also includes the error that I'm expecting on the first time, however when i terminate me51n and run it again with the same exact data, i dont get my error. I have debugged it and put a break point on my include in EXIT_SAPLMEREQ_010 and it never gets to my breakpoint on the second run. (It gets to the breakpoint on the first run but not the second one).
I dont know how but with the same material it works fine later again at the first time but still on the second time i cant get the error again.
Can anyone please help me on this?
Basically problem was the developement system from the beginning (sigh -_-). While having other errors rather than my errors, i assume my error gets stuck sometimes and never pop up because of the standard SAP procedure. So in test system (QA) me51n works perfectly when I'm just trying to have only my error.
Thanks for anyone who actually tried to help and I hope this might be useful sometime for someone in future.
Talha
I was wondering how someone can specify an exit code when shutting a XULRunner application.
I currently use nsIAppStartup.quit() described in MDC nsIAppStartup reference to shutdown the application, but I can't figure out how to specify a process exit code.
The application is launched from a shell script and this exit code is needed to decide if it should be restarted or not.
NOTE : Passing eRestart to the quit function is useless in my situation because restarting depends on factors external to the application (system limits etc.)
Thank you and any help would be appreciated.
A quick look at XRE_main function shows that it will only return a non-zero value in case of errors - and even then the exit code is fixed. If everything succeeds and the application shuts down normally the exit code will be 0, no way to change it. XULRunner isn't really meant to be used in shell scripts, you will have to indicate your result in some other way (e.g. by writing it to a file).