Windbg DUMP分析(原创汇总)

1. 引入篇
  1.1 下载安装
  1.2 调试器
  1.3 操作界面
2. 命令篇
  2.1 按照来源划分
    2.1.1 基本命令
    2.1.2 元命令
    2.1.3 扩展命令
  2.2 按照功能划分
    2.2.1 系统信息
    2.2.2 进程
    2.2.3 模块
    2.2.4 符号
    2.2.5 线程
    2.2.6 内存
    2.2.7 事件
3. 探讨篇
  3.1方法内联
  3.2 字符串驻留池

1. 引入篇

引入篇
  1.1 下载安装
  1.2 调试器
  1.3 操作界面

所谓技术分享,其实是一个自我总结和相互学习、不断成长的过程。

考虑到之前原创的文章http://www.cnblogs.com/LoveOfPrince/p/6032523.html《记一次内存泄漏DUMP分析》被转载,而且有的没有说明出处,这里所有的图片都打了标记,不好意思啊。

1.1 下载安装

WinDbg是微软发布的一款免费而十分强大的调试工具,从官网下载Microsoft Windows SDK,选择安装“Debugging Tools for Windows”。

1.2 调试器

安装目录下,有四个调试器程序。

cdb.exe和 ntsd.exe只支持用户模式调试;Kd.exe主要用于内核调试,有时候也用于用户模式。上述三者只能在控制台界面以命令行形式工作。

Windbg.exe采用可视化的用户界面,支持用户模式和内核模式调试。在两种模式下,都支持实时调试模式和事后调试模式。另外,还支持源码级的调试。

1.3 操作界面

2. 命令篇

命令篇
  2.1 按照来源划分
  2.2 按照功能划分

2.1 按照来源划分

  按照来源划分
    2.1.1 基本命令
    2.1.2 元命令
    2.1.3 扩展命令

2.1.1 基本命令

用?查看基本命令

2.1.2 元命令

用.help查看元命令

2.1.3 扩展命令

用.chain查看扩展模块,再查看指定模块下的所有扩展命令

2.2 按照功能划分

  按照功能划分
    2.2.1 系统信息
    2.2.2 进程
    2.2.3 模块
    2.2.4 符号
    2.2.5 线程
    2.2.6 内存
    2.2.7 事件

2.2.1 系统信息

为了下载和本地系统匹配的符号,可用如下命令查看本地系统信息。


这里列出了操作系统版本、系统持续运行时间、调试时间等信息。

2.2.2 进程

WinDbg能够同时调试多个进程。可以直接附加已经存在的进程,也可以创建新的进程并附加上去。 需要先切换到目标进程,检查当前进程的环境信息,以确认是否切换成功。 最后,结束对当前进程的调试。




查看进程信息,以及包含的程序域。


2.2.3 模块

模块信息相关的命令。

列出了当前调试进程要加载的模块符号信息,将指定模块保存为程序集,反编译看看效果还不错,不过有些变量名不是能直接看懂的。


比如查看模块镜像文件重定位信息,可以发现基本上都是最优的。也可以查看PE头信息研究一下。


2.2.4 符号

在创建二进制镜像文件时,伴生的后缀名为.dbg、.sym或.pdb的文件称为符号文件,包含如下符号信息:
  1)源文件路径以及每个符号的行号。
  2)变量的名字和地址。
  3)函数名称、地址及其原型。
  4)帧指针优化数据。
  5)变量、结构等的类型信息。

符号路径用于告诉调试器去哪里寻找符号文件,调试过程中,只有正确设置了符号路径,使得调试器能够将调试目标、符号文件以及源码文件一一对应起来,才能够最好地发挥调试器的强大功用。


如果涉及到成千上万个符号文件,以及同一个符号文件存在不同平台下的不同版本的时候,那么一一手动设置符号路径肯定是不现实的,于是引入符号服务器的概念。符号服务器有一套命名规则,使得调试器能够正确找到对应平台和版本的符号文件。

WinDbg访问符号需要两个文件(SYMSRV.DLL 和 SYMSTORE.EXE),需要设置系统变量告诉他这两个文件放在什么地方。

2.2.5 线程

查看线程的基本信息。

比如列出所有(托管)线程。


线程号是由调试器软件内部维护的线程ID值,是一个从0开始的整数,在外部是没有太大意义的。
线程ID是系统维护的系统唯一的ID值。
线程的冻结状态,决定了是否分发CPU时间给它。

查看线程的堆栈信息。

查看线程的时间信息,包括三个方面:自创建之初到现在的总消耗时间、用户模式执行时间、内核模式执行时间。


除了耗时,还可以查看线程池的信息。

2.2.6 内存

内存是存储数据、代码的地方,通过内存查看命令可以分析很多问题。通过查看堆上的大对象,以及对象的持有者,了解没有被回收的原因等。



通过查看堆上的大对象,以及对象的持有者,了解没有被回收的原因等。


2.2.7 事件

Windbg是事件驱动的。


比如程序故障分析,电脑蓝屏故障分析等。


查看C盘确实发现百度浏览器目录,卸载百度杀毒、删除C盘百度浏览器(也可清理下注册表),重启电脑,恢复正常。

3. 探讨篇

探讨篇
  3.1方法内联
  3.2 字符串驻留池

3.1方法内联

默认情况下,Release版本进行了各种优化,其中,将被调用方法的方法主体移入调用方的主体,就可以避免某些方法的调用开销,这一操作称为方法内联。


可以发现,DoCalc方法被内联,而Calc方法却不会。这里提到一个问题,什么是优秀的代码,我的理解是除了让人看的舒服,还要更贴近编译优化后的代码。

3.2 字符串驻留池

程序启动时,系统域中的驻留池负责管理被驻留的字符串。抓取DUMP分析,查找这些字符串的根,发现都在一个object数组中,查看这个数组,果然是驻留池



引用架构师修炼中的一段话:

发现问题永远都比解决问题更加重要。一般来说,从问题暴露的点,一点点去溯源查找,一定会找出来谁的问题,以及是什么问题。
最坏情况就是当我们时间或者能力有限,实在是无法定位出是谁的问题的时候,比如系统出故障,也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本,尽量去隔离问题影响的范围,留出时间和空间去识别真正的问题。

时间: 2024-11-10 20:40:32

Windbg DUMP分析(原创汇总)的相关文章

Windbg DUMP

Windbg DUMP分析(原创汇总) 1. 引入篇 1.1 下载安装 1.2 调试器 1.3 操作界面2. 命令篇 2.1 按照来源划分 2.1.1 基本命令 2.1.2 元命令 2.1.3 扩展命令 2.2 按照功能划分 2.2.1 系统信息 2.2.2 进程 2.2.3 模块 2.2.4 符号 2.2.5 线程 2.2.6 内存 2.2.7 事件3. 探讨篇 3.1方法内联 3.2 字符串驻留池 1. 引入篇 引入篇 1.1 下载安装 1.2 调试器 1.3 操作界面 所谓技术分享,其实是

调试技巧 —— 如何利用windbg + dump + map分析程序异常

调试技巧 —— 如何利用windbg + dump + map分析程序异常 逗比汪星人2011-09-04上传 调试技巧 —— 如何利用windbg + dump + map分析程序异常 http://blog.csdn.net/wangningyu/article/details/6748138 http://download.csdn.net/detail/wangningyu/3575167

Java线程Dump分析工具--jstack

jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项"-J-d64",Windows的jstack使用方式只支持以下的这种方式:      jstack [-l][F] pid      如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题.另外,jstack工具还可

面向.Net程序员的dump分析

背景 Dump文件是进程的内存镜像.可以把程序的执行状态通过调试器保存到dump文件中.在 Windows 系统上, dump 文件分为内核 dump 和用户态 dump 两种.前者一般用来分析内核相关的问题,比如驱动程序:后者一般用来分析用户态程序的问题. 一般的程序员可能接触不到dump文件,反而是运维会用的多一些.不过如果你抗战在第一线,学会dump的分析无疑是掌握一柄利器.因为很多场景下,在线下的单元测试或者性能测试中由于测试用例的不充分或者生产与测试环境的硬件以及pv量级的不同等等情况

dump 分析模式之 INCORRECT STACK TRACE - djm2005dy的专栏 - 博客频道 - CSDN.NET

Dump 分析模式之 INCORRECT STACK TRACE dump 分析模式之 INCORRECT STACK TRACE 翻译自 MDA-Anthology Page288 初学者常犯的错误是认为 WinDbg 的 !analyze 和 kv 给出的信息是准确的. WinDbg 只是一个工具, 有时候会缺少一些必要的信息来得到正确的栈信息, 因此我们需要自己明辨正确的与错误的栈信息. 我称之为 Incorrect Stack Trace, 它通常有以下特征: WinDbg给出警告: "

android-async-http 请求分析<原创>

android-async-http发送请求时,真正执行请求的地方是在AsyncHttpRequest类中的,有两个方法: private void makeRequest() throws IOException { if (isCancelled()) { return; } // Fixes #115 if (request.getURI().getScheme() == null) { // subclass of IOException so processed in the call

性能分析之-- JAVA Thread Dump 分析综述

性能分析之-- JAVA Thread Dump 分析综述 一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工具.每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力,虽然各个 Java虚拟机打印的thread dump略有不同,但是大多都提供了当前活动线程的快照,及JVM中所有Java线程的堆栈跟踪信息,堆栈信息一般包含完整的类名及所执行的方法,如果可能的话还有源代码的行数. 1.2 T

性能分析之-- JAVA Thread Dump 分析综述【转】

一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工具.每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力,虽然各个 Java虚拟机打印的thread dump略有不同,但是大多都提供了当前活动线程的快照,及JVM中所有Java线程的堆栈跟踪信息,堆栈信息一般包含完整的类名及所执行的方法,如果可能的话还有源代码的行数. 1.2 Thread Dump特点 1. 能在各种操作系统下使用 2.

通过 thread dump 分析找到高CPU耗用与内存溢出的Java代码

http://heylinux.com/archives/1085.html通过 thread dump 分析找到高CPU耗用与内存溢出的Java代码 首先,要感谢我的好朋友 钊花 的经验分享. 相信大家在实际的工作当中,肯定会遇到由代码所导致的高CPU耗用以及内存溢出的情况. 通常这种情况发生时,我们会认为这些问题理所当然的该由开发人员自己去解决,因为操作系统环境是没有任何问题的. 但实际上,我们是可以帮助他们的,效果好的话还可以定位到具体出问题的代码行数,思路如下: 1.通过对CPU与内存的