Windbg：dump分析总结

通用

配置符号路径

1. 目的
   1. 让WinDbg能够将内存地址翻译成可读的函数名，否则调用栈全是地址，无法分析
2. 命令

识别 Dump 类型和架构

1. 目的
   1. 确定是什么类型的dump（full dump? mini dump?）
   2. 32位还是64位程序
   3. 操作系统版本
   4. 是否是WOW64（64位系统运行32位程序）
2. 命令

3. 如果看到WOW64

查看进程和模块信息

1. 目的
   1. 进程名称、PID
   2. 加载了哪些DLL
   3. 哪些是系统DLL，哪些是第三方DLL
2. 进程命令

3. 模块命令

4. 模块地址范围

5. 时间戳的价值

6. 查找特定模块

自动分析

1. 目的
   1. 让 WinDbg 自动分析 dump，给出初步诊断
2. 命令

3. !analyze -v 的输出

3. 根据 !analyze 输出判断问题类型

查看所有线程

1. 目的
   1. 了解程序有多少线程，每个线程在做什么
2. 列出线程概览
   1. Suspend: 0 - 线程可以运行
   2. Suspend: 1 - 线程被挂起（可能正常，也可能异常）
   3. Unfrozen - 线程可调度
   4. Frozen - 线程被冻结（调试器命令导致）

3. 查看所有线程的调用栈

4. 快速扫描所有线程
   1. 看每个线程在做什么：
   2. NtWaitForSingleObject - 等待（正常）
   3. Sleep - 休眠（正常）
   4. 如果都在等待，可能死锁
   5. 如果某线程栈很深，可能递归太深
5. 切换线程

查看寄存器和内存

1. 目的
   1. 查看崩溃时的CPU状态和内存内容
2. 查看寄存器

3. 查看内存

其他

1. symfix
   1. 自动连接到微软的公共符号服务器
   2. 可以下载 Windows 系统文件（kernel32.dll, ntdll.dll等）的符号
   3. 默认储存在 C:\Symbols</li> </ol> </li> <li>sympath+ 路径
      1. 添加你自己程序的符号文件路径
      2. + 号：表示追加，不覆盖已有路径
   1	.sympath+ C:\YourApp\Symbols

   3. reload
      1. 重新加载所有模块的符号
   1 2	.reload /f          # 强制重新加载 .reload YourApp.exe # 只重新加载指定模块

   4. 如何判断符号加载成功
   1	lm    # 列出所有模块

   输出示例：

   1 2 3 4

   start    end        module name 00400000 00450000   YourApp    C:\Symbols\YourApp.pdb    ← 有pdb路径=成功 76690000 76850000   kernel32   (pdb symbols)             ← 有"pdb symbols"=成功 10000000 10050000   BadModule  (deferred)                ← "deferred"=未加载

   5. 常见异常代码
   1 2 3 4 5 6

   c0000005 → Access Violation（访问违例）- 最常见的崩溃 c0000094 → Integer Division by Zero（除零错误） c000001d → Illegal Instruction（非法指令） c00000fd → Stack Overflow（栈溢出） 80000003 → Breakpoint（断点，通常不是错误） c000008e → Float Division by Zero（浮点除零）

   崩溃（Crash）专项

   分析异常信息

   1. 目的
      1. 详细了解崩溃的原因和上下文
   2. 查看异常记录
      1. ExceptionAddress - 崩溃发生的精确地址
      2. ExceptionCode - 异常类型
      3. Parameter[0] - 操作类型（读/写）
      4. Parameter[1] - 访问的地址（0表示NULL）
   1 2 3 4 5 6 7 8 9

   .exr -1         # 查看最后一个异常记录 .exr 地址       # 查看指定异常记录   ExceptionAddress: 00420123 (YourApp!BadFunction+0x00000042)    ExceptionCode: c0000005 (Access violation)   ExceptionFlags: 00000000 NumberParameters: 2    Parameter[0]: 00000000    ← 0=读取，1=写入    Parameter[1]: 00000000    ← 尝试访问的地址

   3. 查看上下文
      1. 执行后，寄存器会切换到崩溃瞬间的状态，然后可以：
      2. 查看崩溃时的准确调用栈
      3. 查看崩溃时的寄存器
   1	.cxr -1         # 查看崩溃时的CPU上下文

   分析崩溃点的代码

   1. 目的
      1. 理解崩溃指令在做什么
   2. 反汇编崩溃点
   1 2 3

   u 地址          # 反汇编指定地址 u eip           # 反汇编当前指令指针 ub eip          # 反汇编指令指针之前的代码

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

   u 00420123 YourApp!BadFunction+0x3c: 00420123 8b08            mov     ecx,dword ptr [eax]    ← 崩溃在这里！                                               ↑                                               从eax指向的地址读取数据 00420125 894dfc          mov     dword ptr [ebp-4],ecx 00420128 8b45fc          mov     eax,dword ptr [ebp-4]   // 如何分析 mov ecx,dword ptr [eax]     ↑              ↑     |              从eax指向的内存读取4字节     存入ecx寄存器   如果 eax=0，则访问地址0 → NULL指针 如果 eax=0xcccccccc，则未初始化变量 → 使用了未初始化的指针 如果 eax=0x12345678，则可能野指针 → 指针已被释放但仍在使用

   3. 反汇编整个函数
   1 2 3 4 5 6 7 8 9 10 11 12

   uf 函数名           # Unassemble Function uf YourApp!BadFunction   YourApp!BadFunction: 00420100 push    ebp 00420101 mov     ebp,esp 00420103 sub     esp,8 00420106 mov     eax,dword ptr [ebp+8]    ← 获取第一个参数 00420109 test    eax,eax                  ← 检查是否NULL 0042010b je      YourApp!BadFunction+0x50  ← 如果NULL则跳转 ... 00420123 mov     ecx,dword ptr [eax]      ← 崩溃点！说明前面的NULL检查没生

   检查函数参数和局部变量

   1. 目的
      1. 查看崩溃函数的输入和内部状态
   2. 查看局部变量
   1 2 3 4 5 6 7 8 9 10 11 12 13

   dv              # Display Variables dv /V           # 详细模式（显示地址和类型） dv /i           # 显示变量类型   dv          pData = 0x00000000    ← NULL指针！          nCount = 0n42         ← 0n表示十进制          szName = 0x0040abcd "Test"   dv /V @ ebp-04         pData = 0x00000000                  ↑                  变量在栈上的位置

   3. 查看函数参数
   1 2 3 4

   dv /i /t         # 包含类型信息   @ebp+08          struct MyData * pData = 0x00000000 @ebp+0c          int nCount = 0n42

   4. 手动查看栈内容
   1 2 3 4 5 6

   dd ebp L4       # 查看栈帧指针附近   dd ebp 0019f910  0019f950 004205a3 00000000 0000002a           ↑        ↑        ↑        ↑           上一帧ebp 返回地址       参数1    参数2

   常见崩溃模式识别

   1. NULL指针访问
   1 2 3 4 5 6

   EXCEPTION_CODE: c0000005 READ_ADDRESS: 00000000 反汇编： mov eax, dword ptr [ecx]    # ecx = 0   诊断：某个指针没有正确初始化

   2. 野指针（已释放的内存）
   1 2 3 4 5 6 7

   EXCEPTION_CODE: c0000005 READ_ADDRESS: 0xdddddddd (或 0xfeeefeee, 0xcdcdcdcd) 0xdddddddd → 被free()释放的内存（Debug模式） 0xcdcdcdcd → 未初始化的栈内存（Debug模式） 0xfeeefeee → 被HeapFree释放的内存   诊断：使用了已释放的对象（Use-After-Free）

   3. 栈溢出
   1 2 3 4 5 6 7 8 9

   XCEPTION_CODE: c00000fd (Stack Overflow) 调用栈： 00 Function A 01 Function B 02 Function A 03 Function B ... 99 Function A    ← 递归太深 诊断：无限递归或栈上分配了巨大的数组

   4. 除零错误
   1 2 3 4

   EXCEPTION_CODE: c0000094 (Integer Divide by Zero) 反汇编： idiv ecx    # ecx = 0 诊断：除数为0

   卡死（Hang）专项

   识别阻塞线程

   1. 目的
      1. 找出是哪个线程卡住了，或线程间是否死锁
   2. 运行hang分析
   1	!analyze -v -hang

   1 2 3 4 5 6 7 8

   BLOCKING_THREAD:  3 ↑ 线程3导致了阻塞   WAIT_CHAIN_ANALYSIS: Thread 0 → Waiting on Mutex A → Owned by Thread 3 Thread 3 → Waiting on Mutex B → Owned by Thread 0 ↑ 死锁！两个线程互相等待

   3. 查看线程CPU使用
      1. 某线程时间特别长→ 可能死循环，切换到该线程查看
      2. 所有线程时间都很短→ 不是CPU问题，可能是在等待I/O或锁
   1 2 3 4

   !runaway          # 查看用户态时间 !runaway 1        # 查看内核态时间 !runaway 2        # 查看创建后的总时间 !runaway 7        # 显示所有信息

   1 2 3 4 5

   User Mode Time Thread       Time 3:1a4c     0 days 0:05:30.123    ← 线程3占用5分30秒 0:2b5d     0 days 0:00:00.045 1:3c6e     0 days 0:00:00.023

   分析等待原因

   1. 目的
      1. 查看线程在等待什么资源
   2. 查看线程调用栈（重点）
   1	~*kb    # 查看所有线程栈

   典型等待模式

   1. 模式1：等待同步对象
   1 2 3 4

   00 ntdll!NtWaitForSingleObject+0xc 01 KERNELBASE!WaitForSingleObjectEx+0x88 02 YourApp!WorkerThread+0x42 → 线程在等待Event/Mutex/Semaphore

   1 2 3

   !handle          # 查看所有句柄 k = kb           # 查看详细栈，获取等待的句柄值 !handle 句柄值 f  # 查看句柄详情

   2. 模式2：等待文件I/O
      1. 线程在读文件（可能网络文件导致慢）
   1 2 3

   00 ntdll!NtReadFile+0xc 01 KERNELBASE!ReadFile+0x60 02 YourApp!LoadConfig+0x23

   1 2 3 4 5 6

   !handle 0 f File    # 列出所有文件句柄   Handle 1234 Type          File Name          \Server\Share\config.txt ↑ 网络路径！可能网络问题

   3. 模式3：等待网络
   1 2 3 4

   00 ntdll!NtDeviceIoControlFile+0xc 01 ws2_32!recv+0x45 02 YourApp!DownloadData+0x67 → 线程在等待网络数据

   4. 模式4：等待消息（UI线程）
   1 2 3 4

   00 win32u!NtUserGetMessage+0xc 01 user32!GetMessageW+0x30 02 YourApp!WinMain+0x123 → UI线程在消息循环（可能正常）

   检查死锁

   1. 目的
      1. 查找线程间的循环依赖
   2. 查看所有锁
   1 2 3

   !locks          # 查看Critical Sections !cs -l          # 列出所有临界区 !cs -l -o       # 只显示被占用的

   1 2 3 4 5 6 7 8 9 10 11

   CritSec YourApp+0x45678 at 0040abcd WaiterWoken        No LockCount          2                ← 2个线程在等待 RecursionCount     1 OwningThread       1a4c             ← 线程1a4c持有 EntryCount         3 ContentionCount    5 *** Locked                          ← 当前被锁定 WaitingThreads: 2b5d    ← 线程2b5d在等待 3c6e    ← 线程3c6e在等待

   3. 检查特定临界区
   1 2	!cs -s          # 显示统计信息 !cs 地址        # 查看特定临界区

   分析线程池

   1. 目的
      1. 查看线程池状态，是否线程池耗尽
   2. 命令
      1. Idle Thread Count = 0→ 线程池饱和，所有线程在忙
      2. Current = Max→ 达到上限，无法创建新线程
   1	!threadpool     # 查看线程池状态

   1 2 3 4 5 6 7 8

   Worker Thread Pool: Current Thread Count: 8 Max Thread Count: 512 Idle Thread Count: 0    ← 没有空闲线程！ I/O Thread Pool: Current Thread Count: 4 Max Thread Count: 1000 Idle Thread Count: 4

   内存泄漏专项

   概述

   1. 需要两个dump对比，或使用内存分析扩展

   查看堆内存状态

   1. 目的
      1. 了解内存使用情况，识别泄漏
   2. 堆概览
      1. Committed：实际占用的物理内存
      2. Reserved：保留的虚拟地址空间
      3. 如果某个堆特别大，可能是泄漏源
   1	!heap -s        # Heap Summary

   1 2 3 4 5 6 7 8

   Heap Address      Size        Committed    Reserved Default Heap      00150000    00100000     00200000 Heap 1            00250000    00050000     00100000 Heap 2            00350000    00A00000     01000000    ← 这个堆占用10MB！ Total:            Size        Committed    Reserved 00B50000    00AA0000     01300000 ↑           ↑            ↑ 总计11.3MB  10.6MB提交   19MB保留

   3. 查看堆详情
   1 2	!heap -a 堆地址    # 显示堆的所有分配 !heap -stat       # 统计信息

   1 2 3 4 5

   Handle allocations: Count    Size 12345    00001000    ← 12345个分配，每个4KB 67890    00000020    ← 67890个分配，每个32字节 如果某个大小的分配数量异常多，可能是泄漏点

   检查句柄泄漏

   1. 目的
      1. 查看是否有句柄（文件、线程、Event等）没有关闭
   2. 统计句柄
      1. 正常程序：几十到几百个句柄
      2. 如果有几千个句柄，可能泄漏
      3. 重点关注Event、Mutex、File类型
   1 2 3

   !handle          # 列出所有句柄 !handle 0 f      # 详细列出所有句柄 !handle 0 f File # 只列出文件句柄

   1 2 3 4 5

   Handle 1234 Type          Event Handle 1238 Type          Event ... (共5000个Event句柄) ← 异常多！可能泄漏

   3. 按类型统计
   1	!handle 0 4      # 按类型统计

   1 2 3 4 5 6

   Handle count by type: Type           Count Event          5234    ← 异常多！ File           23 Thread         12 Mutex          8

   查找内存分配源头

   1. 目的
      1. 找到哪段代码分配了大量内存但没释放
   2. 需要 UMDH 或 LeakDiag
   1 2	!heap -p -a 地址    # 查看某个地址的分配调用栈 !heap -l           # 检测泄漏（需要特殊配置）

   3. 专业的工具
      1. UMDH- 对比两个dump找泄漏
      2. Application Verifier- 运行时检测泄漏
      3. WinDbg Preview的 Time Travel Debugging

   性能问题专项

   CPU热点分析

   1. 目的
      1. 找出哪个函数占用CPU最多
   2. 命令
   1	!runaway 7       # 查看所有线程的CPU时间

   1 2 3 4

   // 找到最耗时的线程后   ~3s              # 切换到该线程 kb               # 查看在做什么

   实战技巧

   保存分析日志

   1 2 3

   .logopen C:\Logs\analysis.txt [执行所有分析命令] .logclose

   对比两个Dump

   1 2 3 4 5 6 7 8 9

   # 在第一个dump中 !heap -s > C:\dump1_heap.txt !handle > C:\dump1_handles.txt   # 在第二个dump中 !heap -s > C:\dump2_heap.txt !handle > C:\dump2_handles.txt   # 对比两个文件，找增长的内存或句柄

   • 通用
   • 配置符号路径
   • 识别 Dump 类型和架构
   • 查看进程和模块信息
   • 自动分析
   • 查看所有线程
   • 查看寄存器和内存
   • 其他
   • 崩溃（Crash）专项
   • 分析异常信息
   • 分析崩溃点的代码
   • 检查函数参数和局部变量
   • 常见崩溃模式识别
   • 卡死（Hang）专项
   • 识别阻塞线程
   • 分析等待原因
   • 典型等待模式
   • 检查死锁
   • 分析线程池
   • 内存泄漏专项
   • 概述
   • 查看堆内存状态
   • 检查句柄泄漏
   • 查找内存分配源头
   • 性能问题专项
   • CPU热点分析
   • 实战技巧
   • 保存分析日志
   • 对比两个Dump