fgokey / crashrpt

Automatically exported from code.google.com/p/crashrpt
0 stars 0 forks source link

0xE06D7363 - got this exception - but there is no dump! #214

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
So - in our program we are using DrMingw lib - for creating proper files with 
stacktraces - because your tool does not produce such files (IMHO this should 
be done as enhancement). And your tool - which should create a minidump in bad 
cases ;)
More or less all was fine till today. All test cases with small pieces of 
problematic code (like int y=11/0, char *p=0; *p=10; and etc.) have passed 
successfully. But real life looks like has much more interesting examples of 
bad situations. Today our server has got only one file with stacktrace and NO 
corresponding file with minidump. Small investigation shows that all is fine 
regarding http connection between client program and server and with procedure 
of files' sending to our server. Indeed in this case only one file with 
stacktrace was generated. And no file with minidump.

0xE06D7363 - this exception was caught by DrMingw lib and was not parsed by 
your tool. Can you give to us some more details/explanations/suggestions - what 
is wrong? 
Your tool has a bug? This specific MS exception for some reasons - do not 
parsing by tool's engine?

Original issue reported on code.google.com by graphEle...@gmail.com on 20 Jul 2013 at 11:56

GoogleCodeExporter commented 9 years ago
no comments?
Or such situation - non generating of minudumps in some cases - are acceptable 
behavior? Feature "by design"?

P.S. As you can understand - generating of stacktraces in independent log files 
in parallel with generating of minidumps - could safe our hours of analyzing 
what is wrong. And why we did not receive minidump file.
I assume that this feature could be successfully coded at next major release of 
your tool.

Original comment by graphEle...@gmail.com on 3 Aug 2013 at 12:52

GoogleCodeExporter commented 9 years ago
CrashRpt doesn't produce stacktraces, because this requires PDB files to be 
present on the side of the installed application, which is undesired for 
commercial software.

Related to your exception code . I found this information about the exception 
0xE06D7363 : http://support.microsoft.com/kb/185294/en-us

"All Visual C++ exceptions thrown from code generated by the Microsoft Visual 
C++ compiler contain this error code. Because this is a compiler-generated 
error, the code is not listed in the Win32 API header files. The code is 
actually a cryptic mnemonic device, with the initial "E" standing for 
"exception" and the final 3 bytes (0x6D7363) representing the ASCII values of 
"msc". To properly handle the error, you need to wrap the offending code in a 
try...catch block. This allows the developer to identify the actual Visual C++ 
exception that was thrown. "

So, this error seems to related to a C++ exception thrown by your code. To 
better understand how to fix this, I need to have reliable way to reproduce 
this error. Can you reproduce this with WTLDemo or MFCDemo test applications?

Original comment by zexspect...@gmail.com on 5 Oct 2013 at 3:42

GoogleCodeExporter commented 9 years ago
Sorry, there is no way for reproducing this problem anymore....
As a suggestion - maybe you can follow the description you've mentioned.
Write a code which will throw a C++ exception - but do _not_ use any try-catch 
blocks.
This should do the trick.

PS. A stacktrace generation - can be an option. IF I've chosen this option - I 
understand that there are some restrictions/conditions which I must follow....
So it will be my problems - to have pdb files or not to have.

Original comment by graphEle...@gmail.com on 15 Oct 2013 at 2:06

GoogleCodeExporter commented 9 years ago
Which RTC checking options required to work in Release mode for 64 bit 
applications.?

Original comment by srinivasmca25 on 20 Dec 2013 at 1:54