Harvesting Memory Dumps (1)

August 28th, 2009

In the previous article, we have a HelloCrash program that will crash. If the crash is on your local machine, it’s simple to debug because we can attach a debugger to it. What if the crash is on customer’s machine? We’ve already shown that we can get related information from Windows Event Log. However, most of the time we would need better help than that. For example, when we need to peek at register values. Remote debugging can be an option, but most of the time it’s hard to deal with all sort of firewall issues, and most customers are reluctant to let you monkeying their machines for hours. This is where the memory dumps kick in.

Microsoft has posted a detailed article about how to use ADPlus to generate memory dump. ADPlus came along with Debugging Tools for Windows. Let’s follow the instructions provided in Microsoft document and give it a try. When we crashed HelloCrash, we can install Debugging Tools for Windows, launch an elevated Command Prompt and type following commands to get a crash dump:

cd <Debugging Tools for Windows folder>
tlist /p HelloCrash.exe
adplus -crash -p <PID acquired from tlist /p>

We shall have a dump in the Debugging Tools for Windows folder. Let’s open WinDBG, and use File->Open Crash Dump to open that dump. Let’s do some typical analysis here:


0:000> !analyze -v
*********************************************
*
* Exception Analysis
*
*********************************************

FAULTING_IP:
+0
00000000 ?? ???

EXCEPTION_RECORD: ffffffff — (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD: 000009c8

DEFAULT_BUCKET_ID: STATUS_BREAKPOINT

PROCESS_NAME: HelloCrash.exe

ERROR_CODE: (NTSTATUS) 0x80000003 – {EXCEPTION} Breakpoint A breakpoint has been reached.

NTGLOBALFLAG: 400

APPLICATION_VERIFIER_FLAGS: 0

LAST_CONTROL_TRANSFER: from 77519e89 to 774f075a

STACK_TEXT:
0035fcf0 77519e89 ffffffff c0000005 0035fd40 ntdll!ZwTerminateProcess+0x12
0035fd00 7754d058 c0000005 7c4c2188 00000000 ntdll!RtlExitUserProcess+0x7a
0035fd40 7754d1ff 001712c8 7efde000 00000000 ntdll!__RtlUserThreadStart+0x84
0035fd58 00000000 001712c8 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: ~0s; .ecxr ; kb

FOLLOWUP_IP:
ntdll!ZwTerminateProcess+12
774f075a c20800 ret 8

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: ntdll!ZwTerminateProcess+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ntdll

IMAGE_NAME: ntdll.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 4791a783

PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT

BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT

FAILURE_BUCKET_ID: APPLICATION_FAULT_STATUS_BREAKPOINT_ntdll!ZwTerminateProcess+12

BUCKET_ID: APPLICATION_FAULT_STATUS_BREAKPOINT_ntdll!ZwTerminateProcess+12

Followup: MachineOwner
———

Wait a minute, this does not look right at all. Why is the dump saying breakpoint? Also, the stack does not look right. That is because the secure CRT (C-Runtime) already unwinded the failure and called TerminateProcess(). So, what shall we do with ADPlus? In the case of secure CRT in the play, we need to use this command line instead

adplus -crash -bp kernel32!TerminateProcess -sc <full path of HelloCrash.exe>

It will record three dumps for us, and the !analyze -v for these dumps makes more sense.

C++/C#, Debugging, Technical, Windows | Comments Jump to the top of this page

Comments are closed.

Chef Peon's Melange

Archives

Meta

Social Links