If there is a consistent repro, I would definitely prefer Early Debugging. However in the real life postmortem debugging seems to be unavoidable.
There are three concepts I wish to clarify before digging into the details:
AeDebug is a set of registry keys which specify the behavior when unhandled exception happened in an user mode application.
By default AeDebug is configured to use drwtsn32.exe, which would capture a dump and terminate the application in problem.
Just-In-Time Debugging (a.k.a. JIT Debugging) is a feature provided by most debuggers (e.g. CDB, NTSD, WinDBG and Visual Studio Debugger), which allows the debugger to be launched and attached to the application in problem.
The JIT debugger shipped with Visual Studio is called vsjitdebugger.exe, which would pop up a window and let you decide the next step. Visual Studio stepped further by allowing JIT debugging for scripts.
Needless to mention, JIT Debugging is normally built on top of AeDebug.
Postmortem Debugging is an overloaded term which could mean debugging a dump, or JIT debugging.
Since I will cover JIT debugging in another article, I would prefer referring dump file debugging as Postmortem Debugging.
Okay, now let's go back to the topic, what would you do after receiving a dump file?
If it's a user mode dump, additional information needs to be retrieved from the dump.
(to be continued...)