-
July 13th, 2012, 09:20 PM
#1
Calling MiniDumpWriteDump from the same process that crashed
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:
Originally Posted by MSDN
MiniDumpWriteDump should be called from a separate process if at all possible, rather than from within the target process being dumped. This is especially true when the target process is already not stable. For example, if it just crashed. A loader deadlock is one of many potential side effects of calling MiniDumpWriteDump from within the target process.
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....
-
July 14th, 2012, 05:00 AM
#2
Re: Calling MiniDumpWriteDump from the same process that crashed
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.
-
July 14th, 2012, 11:22 AM
#3
Re: Calling MiniDumpWriteDump from the same process that crashed
Of course, it will not work in some cases
Confirmed.
Best regards,
Igor
-
July 14th, 2012, 11:42 AM
#4
Re: Calling MiniDumpWriteDump from the same process that crashed
Thank you, guys.
Originally Posted by Igor Vartanov
Confirmed.
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.
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...
-
July 14th, 2012, 11:48 AM
#5
Re: Calling MiniDumpWriteDump from the same process that crashed
"Oops" - double posted....
-
July 14th, 2012, 12:32 PM
#6
Re: Calling MiniDumpWriteDump from the same process that crashed
Originally Posted by ahmd
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.
Looks much more complicated than direct MiniDumpWriteDump call.
-
July 14th, 2012, 12:48 PM
#7
Re: Calling MiniDumpWriteDump from the same process that crashed
Originally Posted by Alex F
Looks much more complicated than direct MiniDumpWriteDump call.
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.
-
July 14th, 2012, 03:03 PM
#8
Re: Calling MiniDumpWriteDump from the same process that crashed
Originally Posted by ahmd
So, Igor, you're confirming "stack overflow, and low memory" conditions, right?
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.
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.
These days the default stack size remains as it were in old NT days. For properly designed thread 1Mb is more than enough.
Also any idea how to make a minidump for those situations?
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.
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...
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.
Last edited by Igor Vartanov; July 14th, 2012 at 03:05 PM.
Best regards,
Igor
-
July 15th, 2012, 05:42 PM
#9
Re: Calling MiniDumpWriteDump from the same process that crashed
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:
Code:
int i = 0;
LPCTSTR p = NULL;
_stscanf_s(_T("1_s"), _T("%s_%d"), &p, &i);
It does not catch an exception in this case. It beats me why?
-
July 15th, 2012, 07:12 PM
#10
Re: Calling MiniDumpWriteDump from the same process that crashed
Originally Posted by ahmd
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.
Please clarify what you mean by "useless".
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
-
July 15th, 2012, 07:35 PM
#11
Re: Calling MiniDumpWriteDump from the same process that crashed
This one:
Originally Posted by Paul McKenzie
2) Did the program crash, but the crash handler (this is not the MiniDumpWriteDump() function) didn't get invoked?
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:
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
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."
My conclusion is that I should've listened to Alex and Igor from the get-go and gave up on the idea...
-
July 15th, 2012, 08:03 PM
#12
Re: Calling MiniDumpWriteDump from the same process that crashed
Originally Posted by ahmd
It crashed in a debugger build and the TopLevelExceptionFilter handler never got called.
You are supposed to run it standalone (no debugger) to see the results. Running it under the VC++ debugger nullifies your crash handler.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; July 15th, 2012 at 08:05 PM.
-
July 15th, 2012, 08:04 PM
#13
Re: Calling MiniDumpWriteDump from the same process that crashed
Originally Posted by Paul McKenzie
You are supposed to run it standalone (no debugger) to see the results. Running it under the VC++ debugger nullifies your crash handler
I'm obviously running it standalone outside a debugger. It's just a debugger build executable.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|