Visual C++ program crashed, but no dumpfile generated. why?

Question

I have a very strange situation. I'm running IOCP Server Program programmed by Visual studio 2010 in C++.

It uses 'minidump', so When there is a logical bug like pointer misuse, Program crashes with dump file so I can find out where is the crash point in codes.

Sometimes (very rarely), the program crashes and there are no dump files.

What situation makes SetUnhandledExceptionFilter() not working? Anybody knows this problem? I can't figure out.

Disremember

msdn.microsoft.com/en-us/library/windows/desktop/… – Strohben

Answer 1

Well, of course you don't know because you don't have a minidump to look at. You should do the absolute minimum when the SetUnhandledExceptionFilter callback fires. The process is in a perilous state. It crashed. Locks might be held, the heap locks are particularly troublesome. You can't expect MiniDumpWriteDump() to succeed.

What you need is a little guard process that waits on a named event. Start it up as early as possible in your main() function and pass it your process ID. The guard process waits on both that event and your process handle. In your exception callback, just signal the event and immediately sleep for a long time. That wakes up the guard process, it calls MiniDumpWriteDump() plus whatever else is necessary to let you know about the crash. And kills your main program.

Nedrud

I don't understand how MiniDumpWriteDump has any more of a chance to succeed when run from another process. If locks are held then those locks are held. It doesn't matter which process is trying to access the locked resource. Plus, since MiniDumpWriteDump is not thread-safe you are doomed either way. Unless you can synchronize all threads (which you cannot, since your program is in an indeterminate state) there is no guarantee for success. What you say sounds plausible, but doesn't provide a rationale of why the guard process will have a higher chance for success. – Askins

Thread-safety is of no concern, you only have one thread calling MiniDumpWriteDump(). Whether the process is so corrupted that basic calls like CreateFile() and HeapAlloc() that MDWD needs to get its job done can fail most certainly is a concern. It is a filter of sorts, if you do it in-process then you'll never get to see the really bad crashes that are impossible to debug. Good thing, perhaps. – Nedrud

Thanks for the response. Still not quite convinced here: If a process is so corrupted that CreateFile fails (correct me, but can it fail unless kernel memory is corrupted?) then you could also argue that SetEvent will. The same goes for HeapAlloc basically, unless it fails for OOM. I would assume that MDWD works on 'preallocated' static data, though - this would also explain why it is not thread-safe. On a less technical note, have you had a minidump generated out-of-context that an in-process solution would probably not have? – Askins

Not so sure I have to convince you of anything, sounds like a lot of work. Please click the Ask Question button. – Nedrud

Of course you don't have to convince me. But since I challenged the accuracy of your proposed answer it would be foolish not to if you can. I'm genuinely interested. – Askins