Crash Dump completion notification

I am forcibly crashing the process and trying to analyze the crash dump. I am facing the race condition between crash the process and crash dump generation (flush).

If the crash dump is too big then it takes some cputime, is there any callback function in windows debugger (or watson) which can tell about the crash dump开发者_Go百科 completion?

Or is there any mechanism through which I can flush the crash dump forcibly and start analysis.

I am not looking for poll based solution.

1. Add WER registry entry
2. Crash the process
3. Run your self-written tool, which 3a) finds werfault.exe process and 3b) join on that process (wait until it completes)
4. Analyze the dump file

Step 3b does not use polling. A process is a synchronization object which gets signaled.

Note that step 3a will not work before crashing and if the crash dump is small, werfault.exe may already have exited, so it might wait forever. To bypass this, you might want to register your application as the debugger for werfault.exe, which internally forwards the arguments to werfault.exe and then waits until it completes.

The complete sequence then looks like this:

1. Add WER registry entry
2. Add debugger entry for werfault.exe
3. Crash the process
4. Instead of werfault.exe, your application will run. 4a) Start werfault.exe to create the dump and 4b) join on that process (wait until it completes)
5. Maybe remove the debugger entry, if you don't want it permanently
6. Analyze the dump file

Finally I would say you can achieve your goal with some implementation effort. The question is: how many seconds will this save and how many hours will you need for implementation?