1. WinDbg 查看内存的情况：
!address -summary : 内存概况，显示当前内存的使用情况
!address : 查看内存的情况，详细情况
!dh [module addres] : 查看模块的内存详细信息
!heap 查看堆的使用情况
!address -f:stack ： 查看栈的使用情况
~* kp 可以查看每一个线程的栈的情况
2. 公司符号服务器地址
srv*F:\symbols* http://symbol1.corp.qihoo.net/QihooSymbols/index.php;C:\Windows\System32
3. 内存错误调试一 ---- 栈
1. 通过 dc 将指针的内容打印出来，如果看到了字符串，则可以通过da 或 du 打印出来
2. 通过!address 收集关于内存的信息。其中包括了内存的类型（比如私有内存），保护级别（读取，写入与执行），状态（提交或保留）以及用途
（堆或是栈）
3. dds 命令将内存转储位双字或者字符。有助于将内存与特定的类型联系起来。
4. dpp命令对指针解引用，以双字形式转储内存的内容，如果有一个双字匹配了某个符号，这个符号将被显示。如果指针指向的内存包含了
一个虚函数表，那么它将非常有用。
5. dpa 和 dpu命令将指向的内存分别显示为ASCII码和Unicode格式
6. 如果内存的内容是一个很小的数值（4的倍数），那么它可能是一个句柄，通过扩展命令 !handle 来转储这个句柄的信息。
7. 如果没有任何结果，可以在整个地址空间中搜索这块内存的地址。
内存破坏的检测工具：
针对栈内存的破坏，编译器是比较好的工具，编译器可以在程序中添加对栈进行验证的代码
对于堆内存破坏，最好的工具就是应用程序验证器，Application Verifier。
栈结构：
| 函数参数s |
| 函数调用返回地址 |
---------------------
| 保存ebp |
| 函数内的局部变量 |
前导指令：
8bff mov edi, edi
55 push ebp
8bec mov ebp, esp
后继指令：
8be5 mov esp, ebp
5d pop ebp
c3 ret // 函数调用方式不同，ret 指令也不同
这条指令很奇怪，似乎没有用。
8bff mov edi, edi
一般情况下，这条指令就是一条NOP操作，在特定情况下实现动态修补 Hot Patching。
即对运行中的代码打补丁，这样就无需停机，额可以降低系统的停机时间。
动态修补的基本原理是用一个jmp指令来替代mov edi,edi指令，从而使得程序跳转到执行新的代码。
这个指令就有两个字节，因此是一个短跳转，可以向前或向后跳转127个字节。而在该指令之前，有5个Nop
指令，因此可以将该指令替换为一个短跳转，而将5个Nop指令替换为一个长跳转，突破了跳转的限制。
栈溢出：
当线程覆盖了为其他用途所保留的栈空间时，就是发生了栈溢出（Overflow，也称为上溢）。
栈溢出的种类：
1. 数据复制，造成返回地址等栈信息被覆盖，造成错误。 strcpy函数，在给栈上一个有限大小的字符数组复制字符串时就会发生
2. 局部变量无效：一个函数栈上申请的局部变量被传递给一个线程或函数，当该函数返回后，局部变量无效，其他函数或线程写
该局部变量造成其他的函数崩溃。
3. 调用约定不匹配：调用函数和被调用函数定义的一组规则，双方都需遵守。
__cdecl C/C++的一种调用约定，可以支持变长数量的参数。由调用方清理栈。在函数名字前面加"_"
__stdcall 被调用方清理参数，函数名字前加"_",在后面加"@"以及栈空间所需字节数
__fastcall 快速调用。被调用函数清理栈。前两个参数由ECX，EDX传递，在函数名前面加"@"，函数名后面也加"@"以及所需栈空间字节数
__thiscall this指针通过ecx传递，其余参数通过栈传递。被调用函数清理栈。
当栈遭到毁灭性破坏时，通过如下的方式手动分析栈：栈回溯
1. dd esp esp+100 显示当前的栈帧（所有的，如果栈太深，可以用更大数字。）
2. 查看其中的有效地址（在我们程序模块的地址中，lm可以查看我们模块地址范围，然后将在这个范围的地址使用 ln 查看附近的符号）
3. ln addr 来查看这些有效地址附近的一些符号，用于寻找有用的函数调用过程。
这样可以分析出一些有意义的函数调用过程。
同时要查找是什么原因造成了栈的破坏。
u eip 查看当前执行代码是什么
r 查看当前所执行的代码的位置。eip，esp，ebp
4. 内存错误调试二 ---- 堆
堆的管理是由堆管理器完成的，堆管理器分为前端和后端两部分，前端负责分配小的内存块，当前端没有时，再调用后端分配。
如果分配内存较大，则直接放入虚拟分配块列表中，直接分配。
堆的一些信息被放入了 _PEB 进程信息结构体中，其中的ProcessHeaps 项是一个指针数组，其中包含了堆的地址
堆破坏：
扩展命令 !heap 可以有效调试堆破坏情况。
堆破坏的种类：
1. 使用未初始化的状态，例如一个指针未分配内存便使用，造成访问违规。
2. 堆的上溢或下溢：错误的代码覆盖了元数据，堆的完整性被破坏，程序出错。最好的例子就是字符串复制，将一个字符串复制到有限堆空间上。
!heap -s 给出了进程的堆的分配情况
!heap -a addr 显示指定堆的信息，堆列表的信息中可以找到被破坏堆的一些信息。
比较简单的方法是使用 应用程序验证器，它会跟中堆破坏时将使用Heaps测试设置。也称为页堆。
页堆的工作机制是在堆块的周围加上保护层，用来将各个堆块分开，如果堆块被覆盖了，那么它可以在尽量接近
破坏的地方中断程序。
普通堆块和页堆块的区别在于页堆元数据，页堆元数据包含了一定信息，堆块的大小，时机大小，以及栈回溯。
通过这个栈回溯，可以得到该栈分配的操作的完整栈回溯，可以缩小代码肥西范围。
比如HeapAlloc 分配了指针，0019e260，转储页堆元数据内容，首先要减去32(0x20)字节，才能得到元数据。
元数据在内存中设置： 32字节
常规元数据 前置填充 页堆元数据 填充模式
常规元数据 ABCDAAAA 页堆元数据 DCBAAAA // 已分配堆块
常规元数据 ABCDAAA9 页堆元数据 DCBAAA9 // 空闲堆块
页堆元数据 _DPH_BLOCK_INFORMATION
堆 请求大小 实际大小 空闲队列 跟踪索引 栈回溯
使用 dds 命令，可以将"栈回溯" 指向的地址中的栈信息显示出来。
3. 堆句柄不匹配
从两块不同的堆块上分配的内存，释放时，将不同的内存释放到了非分配堆块上，造成错误。
4. 重用已删除的堆块
两次释放同一个堆块，会造成堆管理器的前端的 旁视列表 出现链表循环，造成访问错误。
这种错误只有在再次访问堆管理器前端时，才会出现。
!heap -p -a <heap blockaddr> 通过这个命令查看页堆块的详细信息，找出释放两次的堆块地址。
5. 安全
6. 进程间通信
本地通信分析：
本地通信是通过 LPC通信协议实现的。 LPC通信的调试时通过内核调试实现的。
内核态调试器的扩展命令 !lpc 可以使用这个标识来跟踪调用路径。
通过 !thread扩展命令获取正在处理的LPC请求，与当前请求相对应的消息标识。
!lpc 获取与消息相关的信息。 !lpc message addr
!lpc port <port_id> 获取端口信息
!lpc thread 获取系统上的所有LPC行为
LPC协议的调试功能很强大，当服务器线程处理消息时，客户端线程将被阻塞，可以通过扩展命令 !lpc 分析内核结构发现
7. 资源泄漏
跟踪资源泄漏的工具：任务管理器，性能监视器
任务管理器打开后，选择多列：内存使用，内存使用增量，内存使用高峰值，虚拟内存大小，句柄计数，线程计数，GDI对象
Process Explorer 可以查看进程中打开的资源类型，以及名称，对应的句柄值。
!htrace 命令通过操作系统来跟踪所有打开句柄或者关闭句柄的调用，以及相应的栈回溯。
!htrace -?
!htrace [handle [max_traces]]
!htrace [-enable [max_traces]]
!htrace -disable
!htrace -snapshot
!htrace -diff
内存泄漏：
LeakDiag工具可以监控内存泄漏
!address 命令显示当前进程的内存使用情况。
!heap -s 显示进程的堆使用统计信息
!heap -s addr 显示指定的堆的情况，分配，使用等。
!heap -l 检测泄漏，-l 选项可以让命令以内存回收的形式列举出进程中处于活跃状态，但是没有被引用的内存。
!heap -p -a addr 可以看到堆分配操作的栈回溯。
8. 同步
同步的基础知识：
事件(Event)：
使用!handle 命令可以查看当前进程的Handle，以及其对应的类型。
0:001> !handle
Handle 4
Type Directory
Handle 8
Type File
!handle id f 命令来查看句柄的详细信息， id为 !handle 所列举的句柄的值 比如 4 ，8等
临界区(Critical_section)：
临界区的内存布局为RTL_CRITICAL_SECTION结构体。
dt RTL_CRITICAL_SECTION 可以查看结构体的成员。
0:001> dt RTL_CRITICAL_SECTION
uxtheme!RTL_CRITICAL_SECTION
+0x000 DebugInfo : Ptr32 _RTL_CRITICAL_SECTION_DEBUG
+0x004 LockCount : Int4B
+0x008 RecursionCount : Int4B
+0x00c OwningThread : Ptr32 Void
+0x010 LockSemaphore : Ptr32 Void
+0x014 SpinCount : Uint4B
DebugInfo是系统分配的结构，包含临界区的信息。
LockCount 表示有多少个线程正在等待进入临界区
RecursionCount 表示统一线程进入临界区多少次
OwningThread 标识拥有该 临界区的线程
LockSemaphore 表示临界区是否空闲，是否可以进入
SpinCount 多CPU系统中，等待进入临界区时会进行spin操作，这个是进入之前进行操作的次数
!cs 命令可以列举出当前进程的所有临界区的信息
互斥体(Mutex)：
信号量(Semaphore)：
死锁调试：
!runaway 列举出当前所有线程的执行时间
!runaway 7 列举出执行时间的详细信息
!locks 列举出死锁的信息
~*kb 查看当前在进程中运行的所有的线程堆栈
0:002> ~*kb
0 Id: c9c.131c Suspend: 1 Teb: 7ffde000Unfrozen
ChildEBP RetAddr Args toChild
002dfe04 77486a64 77472278 00000474 00000000 ntdll!KiFastSystemCallRet
002dfe08 77472278 00000474 00000000 00000000ntdll!ZwWaitForSingleObject+0xc //等待锁
002dfe6c 7747215c 00000000 00000000 00a7336c ntdll!RtlpWaitOnCriticalSection+0x13e
002dfe94 6ffbc20c 00a7336c 7720c326 0000046cntdll!RtlEnterCriticalSection+0x150
002dfeac 00a710fd 00a7336c 00a733a4 002dff0cvfbasics!AVrfpRtlEnterCriticalSection2+0x4d
002dfec8 00a712b0 00000001 0307bfd0 0302df68 memory1!main+0x9d [c:\users\guotao\desktop\memory1\main.cpp@ 58]
002dff0c 7720ee1c 7ffdf000 002dff58 774a37ebmemory1!__tmainCRTStartup+0x10f[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 582]
002dff18 774a37eb 7ffdf000 760d4651 00000000kernel32!BaseThreadInitThunk+0xe
002dff58 774a37be 00a713f8 7ffdf000 00000000ntdll!__RtlUserThreadStart+0x70
002dff70 00000000 00a713f8 7ffdf000 00000000ntdll!_RtlUserThreadStart+0x1b
1 Id: c9c.63c Suspend: 1 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr Args toChild
032efb34 77486a64 77472278 00000470 00000000 ntdll!KiFastSystemCallRet
032efb38 77472278 00000470 00000000 00000000ntdll!ZwWaitForSingleObject+0xc //等待锁
032efb9c 7747215c 00000000 00000000 00a73384ntdll!RtlpWaitOnCriticalSection+0x13e
032efbc4 6ffbc20c 00a73384 6e5561a2 6ffbc290ntdll!RtlEnterCriticalSection+0x150
032efbdc 00a71031 00a73384 00000000 02e68fe0vfbasics!AVrfpRtlEnterCriticalSection2+0x4d
032efbec 6ffc42f7 00000000 6da35f20 00000000 memory1!ThreadProc+0x31[c:\users\guotao\desktop\memory1\main.cpp @ 19]
032efc24 7720ee1c 02e68fe0 032efc70 774a37ebvfbasics!AVrfpStandardThreadFunction+0x2f
032efc30 774a37eb 02e68fe0 750e4579 00000000kernel32!BaseThreadInitThunk+0xe
032efc70 774a37be 6ffc42c8 02e68fe0 00000000 ntdll!__RtlUserThreadStart+0x70
032efc88 00000000 6ffc42c8 02e68fe0 00000000ntdll!_RtlUserThreadStart+0x1b
很明显两个线程都在等待事件对象，而停止运行了。
!cs addr 可以显示内存处临界区的内容
0:002> !cs 0x00a73384
-----------------------------------------
Critical section = 0x00a73384 (memory1!cs_DB2+0x0)
DebugInfo = 0x02b3afe0
LOCKED
LockCount = 0x1
WaiterWoken = No
OwningThread = 0x0000131c
RecursionCount = 0x1
LockSemaphore = 0x470
SpinCount = 0x00000fa0
该临界区被锁住了，所属的线程id是 131c
!cs -s 显示每个临界区的初始堆栈回溯
!cs -l 仅显示锁定的临界区
!cs -? 显示 !cs 的帮助信息
~~[tid] tid为线程id，查看当前线程等待的锁是什么
会产生死锁的集中情况：
1. 孤立临界区的情况 —— 异常
临界区被放入 try 中，在临界区中的代码发生了异常，这直接导致执行catch代码，而不会执行LeaveCriticalSection的代码
因此调用其他接口时，需要注意是否会出现这种异常而直接跳出的情况。
比较好的解决办法是将进入和离开临界区的代码封装成类对象，声明局部变量，从而实现跳出作用域即解锁。
因此发生异常，出现栈回退时，该局部变量即被销毁，从而解锁。
2. 孤立临界区的情况 —— 线程结束
在线程过程中，进入临界区后，直接调用TerminateThread，退出了线程，而没有机会执行LeaveCriticalSection
3. 动态库
动态库在加载时，Windows为了确保DLL的加载过程与卸载过程的完整性，使用了一个加载器锁来将所有对DLLMain函数的
访问串行化。这么做的目的是防止并发执行DllMain函数可能出现的问题。
这样如果在DllMain函数中调用了线程创建，并等待线程结束，就会出现问题。
当前线程在调用DllMain时，会对加载器锁进行加锁，而当线程创建时，会再一次调用到本DllMain中，
这时就会等待加载器锁的释放，而前一个线程正在等待这个线程结束的事件。造成了死锁。
因此在DllMain中应该做尽量少的工作，尽快返回。
4.竞争锁
出现"锁护送"的问题。
解决的方法就是使用自旋计数。
管理临界区：
使用临界区之前没有初始化
在临界区删除之后，仍然使用它
过度释放临界区
没有充分释放临界区
9. 64位调试：
64位函数调用方式：
一种是类似x86的fastcall调用，rcx，rdx，r8，r9四个寄存器分别保存前四个参数，剩余参数通过压栈传递
新的调试命令：
.effmach x86 转到兼容模式调试，即32位模式调试
!straddr 列举出当前线程的PEB，在兼容模式进程中，每个线程都有两个TEB，64位和32位的。
当前执行指令 依旧 在 $ip中。
x64的栈，依旧是向低地址方向增长，但是在调用函数之前要按照16字节对齐的。
调用者依旧会给这些通过寄存器传递的参数分配空间，但是不会去初始化它，也不会用它。
而被调用函数，可以使用这些参数空间。比如被调用函数中要使用传参寄存器，可以将寄存器值放入这些分配的参数空间中
10. 事后调试
Windbg 生成dump文件：
.dump /mf /m 表示生成mini dump /f 表示包括所有可访问的和已提交的内存页。
.dump /ma filename 生成一个完整的minidump
分析转储文件
windbg -z C:\Awdbin\dumfile.dmp来启动一个dump调试分析
