如何调试trashed heap / no .dmp / user的机器

Question

I've got a two-year-old C++/Win32 program with hundreds of users. A couple of days ago, one user reported the following crash. It's happening on startup before the program receives any user input. Nobody else is having this problem.

Problem signature:
Problem Event Name: APPCRASH
Application Name: xyz.exe
Application Version: 0.0.2.94
Application Timestamp: 50b92e99
Fault Module Name: StackHash_dec5
Fault Module Version: 6.0.6002.18541
Fault Module Timestamp: 4ec3e39f
Exception Code: c0000374
Exception Offset: 000abc4f
OS Version: 6.0.6002.2.2.0.768.3
Locale ID: 1033
Additional Information 1: dec5
Additional Information 2: cef9e6e9412cee8472af82d5cdb064b7
Additional Information 3: 5d30
Additional Information 4: 7ad67f8281216f819f54c76815aefb56

The program uses a SetUnhandledExceptionFilter handler to write a minidump but the user tells me there's no minidump. I guess that's normal since it's code c0000374 (heap corruption).

After the user reported the problem, I gave him a special build with a bazillion trace statements, including logging every message that goes through the message pump, but all I learned from it is that the last message received by GetMessage was a new message that I put in that special build as part of the debugging stuff. That message and the code it invokes can't be the source of the crash because I added them after his crashes started. Maybe this implies that the crash is happening in some other thread, not the thread that handles messages. The program creates a bunch of threads when it starts.

Can anybody suggest a strategy for debugging this? I'm lost without a .dmp file.

Answer 1

只要您的应用程序崩溃并且不立即退出，即进程仍然存在，您可以使用procdump通过sysinternals（ http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx ）使用procdump -ma xxxx.exe写一个完整的内存转储，然后你可以使用WinDbg进行分析。