3

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.

4

1 回答 1

2

只要您的应用程序崩溃并且没有立即退出,即进程仍然存在,您就可以使用 sysinternals ( http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx ) 的procdumpprocdump -ma xxxx.exe来编写一个完整的内存转储,然后您可以使用 WinDbg 对其进行分析。

于 2012-12-02T21:36:30.800 回答