https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/ Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics Wed, 06 May 2026 01:04:34 +0000 http://wordpress.org/?v=2.3.3 https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-71976 Crash Dump Analysis » Blog Archive » Blocked thread, historical information, execution residue, hidden exception, dynamic memory corruption, incorrect stack trace and not my version: pattern cooperation Thu, 23 Apr 2009 21:01:09 +0000 https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-71976 [...] thread was blocked in a destructor of MyPrinter class. However we see some historical information, faultrep.dll unloaded, and this means that some exception happened prior to the process [...] […] thread was blocked in a destructor of MyPrinter class. However we see some historical information, faultrep.dll unloaded, and this means that some exception happened prior to the process […]

]]> https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-60715 Crash Dump Analysis » Blog Archive » Crash2Hang Mon, 29 Dec 2008 15:43:19 +0000 https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-60715 [...] and exit process upon its dismissal. If several threads in a problem process experience an unhandled exception then Crash2Hang process is launched several times which may result in several such message boxes. Without arguments Crash2Hang process hangs infinitely causing the problem thread with an unhandled exception to hang indefinitely too (see my old post Who calls the postmortem debugger?).   [...] […] and exit process upon its dismissal. If several threads in a problem process experience an unhandled exception then Crash2Hang process is launched several times which may result in several such message boxes. Without arguments Crash2Hang process hangs infinitely causing the problem thread with an unhandled exception to hang indefinitely too (see my old post Who calls the postmortem debugger?).   […]

]]> https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-47796 Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 77) Tue, 21 Oct 2008 10:32:11 +0000 https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-47796 [...] in an application itself calls a postmortem debugger specified by AeDebug registry key (see also Who calls the postmortem debugger? post for detailed [...] […] in an application itself calls a postmortem debugger specified by AeDebug registry key (see also Who calls the postmortem debugger? post for detailed […]

]]> https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-37292 Crash Dump Analysis » Blog Archive » Who saved the dump? Fri, 08 Aug 2008 12:55:23 +0000 https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-37292 [...] the post Who calls the postmortem debugger? I showed that the default unhandled exception filter launches a default postmortem debugger. [...] […] the post Who calls the postmortem debugger? I showed that the default unhandled exception filter launches a default postmortem debugger. […]

]]> https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-24968 Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 60) Tue, 29 Apr 2008 11:28:57 +0000 https://www.dumpanalysis.org/blog/index.php/2007/04/30/who-calls-the-postmortem-debugger/#comment-24968 [...] The second crashed thread has much more symbolic information in it overwriting previous thread startup residue. It is mostly exception handling residue because exception handling consumes stack space as explained in the post Who calls the postmortem debugger?: [...] […] The second crashed thread has much more symbolic information in it overwriting previous thread startup residue. It is mostly exception handling residue because exception handling consumes stack space as explained in the post Who calls the postmortem debugger?: […]

]]>