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.