0

In order to write a crash dump on windows I am catching unhandled exceptions, all using SetUnhandledExceptionFilter and MiniDumpWriteDump

Now this works (as good as it can) but my question is, once I am in my exception filter function, what am I allowed to do?

Can I theoretically still allocate new resources, write stuff onto my HD, start other processes etc.? I know basically my application crashed but does this impose any restrictions on what can be done once that happened? What do I have to keep in mind?

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
Navie
  • 164
  • 1
  • 8
  • Be specific with your terminology. "Exception" has a particular meaning in C++, and I'm pretty sure that's not what you're talking about. You're going to get responses referring to C++ exceptions, I'm sure. Unfortunately, they will be completely wrong. – Sam Varshavchik Apr 19 '18 at 10:53
  • 1
    this is undefined. you may do anything or almost nothing, depend on exception reason. say for example process heap corrupt. on first new heap allocation - you can again got exception. the same if corrupted another process global data (say PEB). but this not very usual case. in most case you can do almost all - start new processes, write to files, etc – RbMm Apr 19 '18 at 11:08
  • 2
    See `google breakpad` [design rationale](https://github.com/google/breakpad/blob/master/docs/exception_handling.md) and [in-process handling guidelines](https://github.com/google/breakpad/blob/master/docs/client_design.md#exception-basics) – dewaffled Apr 19 '18 at 11:12
  • It seems common sense to me that if stack overflow happens you shouldn't use the stack, but I could be wrong. This means calling `MiniDumpWriteDump` could just terminate the whole process. But I could be wrong. – Dialecticus Apr 19 '18 at 11:26
  • Thanks guys, this is all already very helpful. It seems to be an unsafe situation by nature and probably starting a new process to handle additional stuff seems to be the safest way. Cheers everyone! – Navie Apr 19 '18 at 12:12
  • If your goal is to collect dumps for debugging, I'd recommend either using [WER](https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx) or [ProcDump](https://learn.microsoft.com/en-us/sysinternals/downloads/procdump) to collect a memory dump for you automatically when/if the process dies. See also [this](https://serverfault.com/a/822675/363620) at ServerFault. – theB Apr 19 '18 at 12:55
  • 1
    Most important insight: You **cannot** safely call `MiniDumpWriteDump` from an unhandled exception filter. This has nothing to do with the exception or the program state, but rather with the way `MiniDumpWriteDump` is implemented. I have written down some information in [this answer](https://stackoverflow.com/a/41433641/1889329). – IInspectable Apr 19 '18 at 13:19
  • It is just plain risky. Something very nasty happened and you can't assume that OS functions still do what they are supposed to do. The global lock that protects the default process heap was one I discovered the Hard Way for example. It is not like this doesn't often come to a good end anyway, but you'll miss out on all the truly nasty ones. The boilerplate approach is to do almost nothing and leave the minidump creation to a "guard process". SetEvent() to wake it up is pretty safe, never yet seen that go wrong. But then again, I wouldn't know :) – Hans Passant Apr 19 '18 at 14:16
  • @Dialecticus: The exception filter has its own stack frame. Allocating data on the stack in an exception filter is safe, even in face of a stack overflow exception. Although not impossible, I have never seen `MiniDumpWriteDump` terminate a process. The far more common error mode is for it to deadlock the process, if called in-context. – IInspectable Apr 19 '18 at 18:18

0 Answers0