3
votes

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.

1
You should be able to get a .dmp file even with heap corruption. According to Microsoft you need to use a separate process to generate a .dmp for your crashed process. We use code from " Matt Pietrek, Microsoft Systems Journal, May 1997" so our process can generate stack back traces about itself if it gets an exception.brian beuning
Depends on what heap got corrupted. If it is the default process heap then all bets are off with high likelihood that it deadlocks. The only safe way is to let a guard process take the minidump.Hans Passant

1 Answers

2
votes

As long as your application crashes and doesn't exit right away, i.e. the process is still there, you can use procdump by sysinternals ( http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx ) with procdump -ma xxxx.exe to write a full memory dump, which you then can analyze with WinDbg.