Example of working with a dump.

Let's say that you are looking at a crash dump, so following the first command from this page you do:

 

0:006> !analyze -v

 

Part of what the command prints is:

 

FAULTING_IP: 

YCWebCameraSource+14c7e

1c414c7e 8b01            mov     eax,dword ptr [ecx]




EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)

ExceptionAddress: 1c414c7e (YCWebCameraSource+0x00014c7e)

   ExceptionCode: c0000005 (Access violation)

  ExceptionFlags: 00000000

NumberParameters: 2

   Parameter[0]: 00000000

   Parameter[1]: 00000000

Attempt to read from address 00000000




CONTEXT:  00000000 -- (.cxr 0x0;r)

eax=00000000 ebx=0465c528 ecx=00000000 edx=00000500 esi=0465c498 edi=00000000

eip=77c2e1a4 esp=0465c370 ebp=0465c4f0 iopl=0         nv up ei pl nz ac po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200212




PROCESS_NAME:  chrome.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000000

READ_ADDRESS:  00000000 




FOLLOWUP_IP: 

YCWebCameraSource+14c7e

1c414c7e 8b01            mov     eax,dword ptr [ecx]




BUGCHECK_STR:  APPLICATION_FAULT_NULL_POINTER_READ_INVALID_POINTER_READ_BEFORE_CALL




STACK_TEXT:  

0465cab8 00000000 0465cbc4 096052c0 1c414fe1 YCWebCameraSource+0x14c7e

 

which basically says that there is an attempt to read from NULL:

 

YCWebCameraSource+14c7e

1c414c7e 8b01            mov     eax,dword ptr [ecx]

 

and ECX is 0.

 

The problematic part is the last one: the stack is a single line of text, inside a DLL that you know nothing about. Moving on to the next command,

 

0:006> .ecxr

eax=0bd00048 ebx=000000f0 ecx=00000000 edx=00000500 esi=0465cbc4 edi=00000140

eip=1c414c7e esp=0465cabc ebp=000000f0 iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210202

YCWebCameraSource+0x14c7e:

1c414c7e 8b01            mov     eax,dword ptr [ecx]  ds:002b:00000000=????????

 

confirms what we already know as the debugger loads the context when the exception was received. The stack window shows only one line of text.

 

0:006> k

  *** Stack trace for last set context - .thread/.cxr resets it

ChildEBP RetAddr  

WARNING: Stack unwind information not available. Following frames may be wrong.

0465cab8 00000000 YCWebCameraSource+0x14c7e

 

Looking at the registers show the reason: EBP is 0xF0, which is not a pointer to the stack. ESP looks fine, so let's see what's there using the next command from the list:

 

0:006> dds esp

0465cabc  00000000

0465cac0  0465cbc4

0465cac4  096052c0

0465cac8  1c414fe1 YCWebCameraSource+0x14fe1

0465cacc  0b7b0000

0465cad0  00000140

0465cad4  000000f0

0465cad8  00000500

0465cadc  09710000

0465cae0  00000140

0465cae4  000000f0

0465cae8  000003c0

0465caec  00000000

0465caf0  00000000

0465caf4  00000140

0465caf8  1c40c24e YCWebCameraSource+0xc24e

0465cafc  0b7b0000

0465cb00  00000140

0465cb04  000000f0

0465cb08  00000000

0465cb0c  00000500

0465cb10  09710000

0465cb14  00000140

0465cb18  000000f0

0465cb1c  00000000

0465cb20  000003c0

0465cb24  0465e074

0465cb28  09158124

0465cb2c  091561c8

0465cb30  00000000

0465cb34  09605848

0465cb38  0b8007c8

 

A few pointers to code close to the address that crashed, which is good because it means the control flow before the crash is reasonable. But clearly that code is not using EBP to maintain stack frames (more on that later). So see what else is on the stack:

 

0:006> dds

0465cb3c  0b800960

0465cb40  000003c0

0465cb44  091561c8

0465cb48  00022009

0465cb4c  80004005

0465cb50  1c4238f8 YCWebCameraSource+0x238f8

0465cb54  09605848

0465cb58  00000000

0465cb5c  000000b2

0465cb60  096052c0

0465cb64  00000000

0465cb68  00000000

0465cb6c  00000140

0465cb70  000000f0

0465cb74  00000140

0465cb78  000000f0

0465cb7c  00000500

0465cb80  00022009

0465cb84  0b7b0000

0465cb88  00000001

0465cb8c  1c4238f8 YCWebCameraSource+0x238f8

0465cb90  096046c8

0465cb94  00000000

0465cb98  0465cc28

0465cb9c  00000140

0465cba0  000000f0

0465cba4  000003c0

0465cba8  00021808

0465cbac  09710000

0465cbb0  00000002

0465cbb4  557cf400

0465cbb8  11d31a04

 

Note that issuing the command without an argument just continues where the last invocation left of. Furthermore, just hitting enter repeats the last command so after this point is a matter of keep hitting enter. Which is good because in this case interesting things happen after a long time:

 

0:006> 

0465f22c  f15f2bff

0465f230  0465f27c

0465f234  772b9b03 msvcrt!free+0x65

0465f238  01700000

0465f23c  00000000

0465f240  772b9b10 msvcrt!free+0x84

0465f244  f1a4c16f

0465f248  00000000

0465f24c  0170b3f8

0465f250  00000000

0465f254  00000000

0465f258  0465f238

0465f25c  ffffffff

0465f260  00000000

0465f264  0465f244

0465f268  82eaa80b

0465f26c  0465f98c

0465f270  772dc265 msvcrt!_except_handler4

0465f274  82eaa80b

0465f278  fffffffe

0465f27c  772b9b10 msvcrt!free+0x84

0465f280  732343a5 devenum!ATL::CComObject<CCreateSwEnum>::`scalar deleting destructor'+0x3d

0465f284  0170b3f8

0465f288  73234566 devenum!ATL::CComObject<CCreateSwEnum>::Release+0x23

0465f28c  03290d90

0465f290  031f0b50

0465f294  0465f4bc

0465f298  6fb647db chrome_6faf0000!media::GetDeviceNamesDirectShow+0x3ab

0465f29c  6fb647e5 chrome_6faf0000!media::GetDeviceNamesDirectShow+0x3b5

0465f2a0  0465f2b8

0465f2a4  6faf22b5 chrome_6faf0000!tcmalloc::FL_Push+0x71

0465f2a8  01192308

 

After a while of seeing symbols from various DLLs go through the stack we start to see symbols from Chrome. The last part looks relatively good. Note that at address 0465f298  there is a pointer to Chrome code, and more importantly, 4 bytes before there is a pointer to another place in the stack, some bytes after the current position: 0465f294  0465f4bc. This is the typical pattern of a call to a function that use EBP to track stack frames. Time to use the next command from the list:

 

0:006> k = 0465f294  0465f294  0465f294  

ChildEBP RetAddr  

WARNING: Frame IP not in any known module. Following frames may be wrong.

0465f294 6fb647db 0x465f294

0465f4bc 07554180 chrome_6faf0000!media::GetDeviceNamesDirectShow+0x3ab

0465f4cc 6fb643d2 0x7554180

0465f4e8 6fb64386 chrome_6faf0000!media::VideoCaptureDeviceFactory::EnumerateDeviceNames+0x45

0465f4f4 6fb55ece chrome_6faf0000!base::internal::Invoker<>

0465f5d4 6fb5552d chrome_6faf0000!base::MessageLoop::RunTask+0x50a

0465f718 6fb62bad chrome_6faf0000!base::MessageLoop::DoWork+0x359

0465f744 6fb5503a chrome_6faf0000!base::MessagePumpDefault::Run+0xc7

0465f768 6fb54f2d chrome_6faf0000!base::MessageLoop::RunHandler+0x6e

0465f794 6fb54ec4 chrome_6faf0000!base::MessageLoop::Run+0x65

0465f79c 6fb5291e chrome_6faf0000!base::Thread::Run+0xb

0465f928 6fb52509 chrome_6faf0000!base::Thread::ThreadMain+0x26e

0465f94c 778a850d chrome_6faf0000!base::`anonymous namespace'::ThreadFunc+0xcb

0465f958 77c5bf39 kernel32!BaseThreadInitThunk+0xe

0465f99c 77c5bf0c ntdll!__RtlUserThreadStart+0x72

0465f9b4 00000000 ntdll!_RtlUserThreadStart+0x1b

 

Strictly speaking the format that I just used is not correct, but the debugger does a decent job figuring out what I want just complaining about the first frame. The good part is that now we have a stack that looks reasonable. Time to go up and try to get something better.

 

The pattern that we just saw, a pointer a few bytes ahead followed by a symbol should repeat itself... as in the pointer should point to another pointer followed by a symbol. Se if we search up on the debugger output for 0465f294 we should get to the previous frame. If there is no match, it means that either we reached a function call that doesn't use EBP, or we are following stale data from the stack (traces of something that happened before, and has not been overwritten yet, but it is not the current call sequence).

 

And that's exactly what happens in this case. But going up and following stack manually a few times provides a better stack. Remember that the goal is not to get a perfect stack trace but to get enough information to do something about it. We already know that get the actual stack will be impossible because close to the crash point there's no EBP and no symbols. But the type of symbols that you see going through while executing dds gives you a rough idea of how the flow ends up at the code that crashes.

 

0:006> k = 0465e0ac  0465e0ac  0465e0ac  

ChildEBP RetAddr  

WARNING: Frame IP not in any known module. Following frames may be wrong.

0465e0ac 76ec7543 0x465e0ac

0465e11c 76ec4fdf combase!CServerContextActivator::CreateInstance+0x18b

0465e15c 76ec7610 combase!ActivationPropertiesIn::DelegateCreateInstance+0x5c

0465e1b0 76ec7334 combase!CApartmentActivator::CreateInstance+0x75

0465e1d4 76ec6d52 combase!CProcessActivator::CCICallback+0x3b

0465e1f4 76ec72cf combase!CProcessActivator::AttemptActivation+0x2c

0465e22c 76ec73a9 combase!CProcessActivator::ActivateByContext+0x97

0465e25c 76ec4fdf combase!CProcessActivator::CreateInstance+0x5d

0465e29c 76ec50d7 combase!ActivationPropertiesIn::DelegateCreateInstance+0x5c

0465e4fc 76ec4fdf combase!CClientContextActivator::CreateInstance+0xdd

0465e53c 76ec5ba6 combase!ActivationPropertiesIn::DelegateCreateInstance+0x5c

0465ede8 76ebc9c2 combase!ICoCreateInstanceEx+0xfb6

(Inline) -------- combase!CComActivator::DoCreateInstance+0x11a

(Inline) -------- combase!CoCreateInstanceEx+0x14e

0465ee3c 732352c3 combase!CoCreateInstance+0x169

0465eef0 70cedfbd devenum!CDeviceMoniker::BindToObject+0x1ac

0465f0e0 70ce59df chrome_6faf0000!media::VideoCaptureDeviceWin::GetDeviceFilter+0x234

0465f3ac 70ce56a2 chrome_6faf0000!media::GetDeviceSupportedFormatsDirectShow+0x335

0465f3c0 6fb64995 chrome_6faf0000!media::VideoCaptureDeviceFactoryWin::GetDeviceSupportedFormats+0x20

0465f44c 6fb648c1 chrome_6faf0000!content::VideoCaptureManager::ConsolidateDevicesInfoOnDeviceThread+0xc1

0465f46c 6fb64883 chrome_6faf0000!base::internal::RunnableAdapter<>::Run+0x2e

0465f488 6fb64848 chrome_6faf0000!base::internal::InvokeHelper<>::MakeItSo+0x25

0465f4b8 6fb64800 chrome_6faf0000!base::internal::Invoker<<media::VideoCaptureDevice::N+0x33

0465f4cc 6fb643d2 chrome_6faf0000!base::Callback<>::Run+0x17

0465f4e8 6fb64386 chrome_6faf0000!media::VideoCaptureDeviceFactory::EnumerateDeviceNames+0x45

0465f4f4 6fb55ece chrome_6faf0000!base::internal::Invoker<2,base::internal::BindState<>::Run+0x10

0465f5d4 6fb5552d chrome_6faf0000!base::MessageLoop::RunTask+0x50a

0465f718 6fb62bad chrome_6faf0000!base::MessageLoop::DoWork+0x359

0465f744 6fb5503a chrome_6faf0000!base::MessagePumpDefault::Run+0xc7

0465f768 6fb54f2d chrome_6faf0000!base::MessageLoop::RunHandler+0x6e

0465f794 6fb54ec4 chrome_6faf0000!base::MessageLoop::Run+0x65

0465f79c 6fb5291e chrome_6faf0000!base::Thread::Run+0xb

0465f928 6fb52509 chrome_6faf0000!base::Thread::ThreadMain+0x26e

0465f94c 778a850d chrome_6faf0000!base::`anonymous namespace'::ThreadFunc+0xcb

0465f958 77c5bf39 kernel32!BaseThreadInitThunk+0xe

0465f99c 77c5bf0c ntdll!__RtlUserThreadStart+0x72

0465f9b4 00000000 ntdll!_RtlUserThreadStart+0x1b

 

Note how this stack is slightly different right where the previous stack started, but it flows nicely into a sequence of com calls. There's usually no point in going too deep into code we don't control, so that is all we need in this case.