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.

Example of working with a dump.的更多相关文章

  1. PMON failed to acquire latch, see PMON dump

    前几天,一台Oracle数据库(Oracle Database 10g Release 10.2.0.4.0 - 64bit Production)监控出现"PMON failed to a ...

  2. oracle dump数据库

    最近正在看老白的<DBA的思想天空>,了解数据块结构,想通过dump data block验证oracle对于行尾的NULL,是不占用存储空间的. 我们先来看一下怎样dump数据块: 1. ...

  3. Dump类型说明

    通过使用windbg提供DbgHelp库中的MiniDumpWriteDump函数在程序崩溃时写dump文件记录程序当时状态,为后续分析问题提供现场. 该函数提供了DumpType参数,让程序员根据具 ...

  4. 使用GDB 追踪依赖poco的so程序,core dump文件分析.

    前言 在windows 下 系统核心态程序蓝屏,会产生dump文件. 用户级程序在设置后,程序崩溃也会产生dump文件.以方便开发者用windbg进行分析. so,linux 系统也有一套这样的东东- ...

  5. 转:CentOS, 找不到dump命令:command not found

    dump 功能说明:备份文件系统.语 法:dump [-cnu][-0123456789][-b <区块大小>][-B <区块数目>][-d <密度>][-f &l ...

  6. slave IO流程之二:注册slave请求和dump请求

    slave IO流程已经在http://www.cnblogs.com/onlyac/p/5815566.html中有介绍 这次我们要探索注册slave请求和dump请求的报文格式和主要流程. 一.注 ...

  7. 使用MAT(Memory Analyzer Tool)工具分析dump文件--转

    原文地址:http://gao-xianglong.iteye.com/blog/2173140?utm_source=tuicool&utm_medium=referral 前言 生产环境中 ...

  8. 认识Java Core和Heap Dump

    什么是Java Core和Heap Dump Java程序运行时,有时会产生Java Core及Heap Dump文件,它一般发生于Java程序遇到致命问题的情况下. 发生致命问题后,Java进程有时 ...

  9. sublime text 乱码生成.dump问题的解决方法

    title: sublime text 乱码生成.dump问题的解决方法 tags: sublime text,sublime text 3,.dump,乱码 grammar_cjkRuby: tru ...

  10. Oracle数据泵(Data Dump)错误汇集

    Oracle数据泵(Data Dump)使用过程当中经常会遇到一些奇奇怪怪的错误案例,下面总结一些自己使用数据泵(Data Dump)过程当中遇到的问题以及解决方法.都是在使用过程中遇到的问题,以后陆 ...

随机推荐

  1. m_Orchestrate learning system---十五、如何快速查错

    m_Orchestrate learning system---十五.如何快速查错 一.总结 一句话总结: a.删除代码法 b.添加提示代码法 c.仔细看错误信息 1.评论板块和论坛板块的实时更新? ...

  2. ORACLE里锁的几种模式

    0:none  1:null 空  2:Row-S 行共享(RS):共享表锁  3:Row-X 行专用(RX):用于行的修改  4:Share 共享锁(S):阻止其他DML操作  5:S/Row-X ...

  3. correct ways to define variables in python

    http://stackoverflow.com/questions/9056957/correct-way-to-define-class-variables-in-python later say ...

  4. JavaScript中Number常用属性和方法

    title: JavaScript中Number常用属性和方法 toc: false date: 2018-10-13 12:31:42 Number.MAX_VALUE--1.79769313486 ...

  5. matlab张量工具初步

    最近从桑迪亚实验室下载了张量工具包.但是不太会用. 很多网上的方法, addpath(pwd) cd met; addpath(pwd) savepath M=ones(4,3,2); X=tenso ...

  6. HDU 2120 Ice_cream's world I【并查集】

    解题思路:给出n对点的关系,求构成多少个环,如果对于点x和点y,它们本身就有一堵墙,即为它们本身就相连,如果find(x)=find(y),说明它们的根节点相同,它们之间肯定有直接或间接的相连,即形成 ...

  7. CDR X6设计师的福利,3折特惠!

    最新消息称,即日起CorelDRAW官方为回馈新老用户长期以来的支持,特别推出CorelDRAW X6降价活动.目前CorelDRAW X6售价仅为2399元,照这个价格,CDR 2017     会 ...

  8. Vrtualbox虚拟机中共享文件夹配置

    虚拟机装的是ubuntu 16.0.4版本的linux,本机是macOs 10.12.1版本 Vrtualbox进行如下配置 在Vrtualbox-->设置-->共享文件夹-->添加 ...

  9. Promise语法

    转自:廖雪峰的官方网站 在JavaScript的世界中,所有代码都是单线程执行的. 由于这个“缺陷”,导致JavaScript的所有网络操作,浏览器事件,都必须是异步执行.异步执行可以用回调函数实现: ...

  10. Linux 添加挂载硬盘(包含挂载大于2T以上硬盘)

    转自:http://blog.csdn.net/season_hangzhou/article/details/36423223 由于事先规划问题或者业务需求量激增,总会出现机器硬盘空间不够用的情况 ...