Printable View
I'm trying to create my own app crash handler that collects the minidump files following this somewhat outdated sample. It uses the MiniDumpWriteDump() API but after reviewing the latest MSDN page for it I came across this statement in the Remarks section:
So my question is, if I can't call MiniDumpWriteDump from the same process that crashed, how is it suggested to be called? I mean it won't have access to the stack context if I call it from another process....Quote:
Originally Posted by MSDN
I call MiniDumpWriteDump from the same process, it is OK. Of course, it will not work in some cases, like stack overflow, or low memory. But in most situations it works and allows to add post-mortem debugging feature to our project.
MiniDumpWriteDump should be called in some kind of global exception handler, as shown in the CodeProject article. So, when something unexpected happens, but the program is still able to run, call MiniDumpWriteDump and kill the process.
Confirmed.Quote:
Of course, it will not work in some cases
Thank you, guys.
So, Igor, you're confirming "stack overflow, and low memory" conditions, right? Just curious, how often can those occur in a modern OS. I mean I haven't looked into the default size of the stack these days, but it should be plenty to cause an overrun. Although, as I think about it, some recursive process can run a muck and cause it pretty easily.Quote:
Originally Posted by Igor Vartanov
Also any idea how to make a minidump for those situations?
Let me give you my initial idea. I thought to run a special designated service to collect app crashes. (And again, it's not that my app crashes all the time, it's that having those .dmp files helps a lot when one occurs.) So in case one of my processes crashes it passes its process ID & thread ID to this crash dump service right from the TopLevelExceptionFilter handler, that the service uses to call MiniDumpWriteDump with. The obvious issue here is passing those IDs to the service. My preferred method is a named pipe, but the question that comes up is whether doing a named pipe communication with the service from a crashed process is actually even possible, or reliable at all? So tell me if I'm going too far with it? It'd be nice to hear your guy's take on it before I jump into coding all this...
"Oops" - double posted....
Looks much more complicated than direct MiniDumpWriteDump call.Quote:
Originally Posted by ahmd
You bet, Alex :) I'm just trying to follow what it says in MSDN. I'm assuming that it's there not just for nothing.... right? Although, I'm with you. I'll probably end up just calling it from the process that crashes.... it's too much work to do it like I proposed above.Quote:
Originally Posted by Alex F
No. I literally confirmed the quoted: It fails to work in some cases. One time it creates zero size dump file, other time it creates a dump with some meaningless call stack. Unfortunately, our customers run 24/7 systems, so I never was at luxury to be given with time enough to understand the root cause. But most of the times minidump works satisfactorily.Quote:
Originally Posted by ahmd
These days the default stack size remains as it were in old NT days. For properly designed thread 1Mb is more than enough.Quote:
Just curious, how often can those occur in a modern OS. I mean I haven't looked into the default size of the stack these days, but it should be plenty to cause an overrun. Although, as I think about it, some recursive process can run a muck and cause it pretty easily.
Sorry, no idea. Frankly saying, I spend lesser and lesser time on Windows C++ projects because of moving to other platforms and languages. No time to research such kind of things. :(Quote:
Also any idea how to make a minidump for those situations?
You know, my favorite approach is waiting for event. Which means, the monitor should be aware of the PID beforehand (this just means early registration with the monitor) and waiting on a specially named global event. Besides, while you establish a connection there might be not enough time even to connect to a pipe.Quote:
Let me give you my initial idea. I thought to run a special designated service to collect app crashes. (And again, it's not that my app crashes all the time, it's that having those .dmp files helps a lot when one occurs.) So in case one of my processes crashes it passes its process ID & thread ID to this crash dump service right from the TopLevelExceptionFilter handler, that the service uses to call MiniDumpWriteDump with. The obvious issue here is passing those IDs to the service. My preferred method is a named pipe, but the question that comes up is whether doing a named pipe communication with the service from a crashed process is actually even possible, or reliable at all? So tell me if I'm going too far with it? It'd be nice to hear your guy's take on it before I jump into coding all this...
Thanks for the info, Igor.
I did more tests and can pretty much conclude that the MiniDumpWriteDump() API is useless -- it works in 75% of times with a C++ program. For instance, my third test with it failed. Here it is:
It does not catch an exception in this case. It beats me why?Code:int i = 0;
LPCTSTR p = NULL;
_stscanf_s(_T("1_s"), _T("%s_%d"), &p, &i);
Please clarify what you mean by "useless".Quote:
Originally Posted by ahmd
1) Did the code you wrote actually crash, or did the code just kept going without error?
2) Did the program crash, but the crash handler (this is not the MiniDumpWriteDump() function) didn't get invoked?
3) Did the program crash, the crash handler called, but the MiniDumpWriteDump() didn't write the crash dump?
Regards,
Paul McKenzie
This one:
The code sample above is actually a typo that I compiled and ran (so technically it would be a real-life example that I would've needed caught). It crashed in a debugger build and the TopLevelExceptionFilter handler never got called. Instead the regular Windows 7 app crash window showed up. I also got this in the event log:Quote:
Originally Posted by Paul McKenzie
Unless I don't understand something about top level exception handler for a process, there's no reason to use one if its OS implementation works "only in some situations."Quote:
Faulting application name: my_app_name.exe, version: 1.0.2.0, time stamp: 0x50035f45
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0xfefefefe
Faulting process id: 0xb40
Faulting application start time: 0x01cd62e96a5acda8
Faulting application path: C:\Users\Dev\C++\my_app_name\Debug\my_app_name.exe
Faulting module path: unknown
Report Id: a8575e1d-cedc-11e1-8494-c8aecf56d8a1
My conclusion is that I should've listened to Alex and Igor from the get-go and gave up on the idea...
You are supposed to run it standalone (no debugger) to see the results. Running it under the VC++ debugger nullifies your crash handler.Quote:
Originally Posted by ahmd
Regards,
Paul McKenzie
I'm obviously running it standalone outside a debugger. It's just a debugger build executable.Quote:
Originally Posted by Paul McKenzie