下载地址 ： http://download.csdn.net/detail/zcc1414/7720079
http://blog.csdn.net/mergerly/article/details/8308724
http://blog.csdn.net/ithzhang/article/details/12786393
gflags
/p /enable test.exe /full /unaligned
gflags.exe /p /disabletest.exe
D:WinDDK7600.16385.1Debuggerswindbg.exe -p %ld -e %ld -g
在命令行中运行 PageHeap /enable YourApplicationName.exe 0x01
PageHeap的使用中有几点值得注意：
1:启用PageHeap不能够影响正在运行中的应用程序。如果你需要启用一些正在运行且不能重启的程序的PageHeap，那请运行PageHeap启用后，重新启动机器。
2:要想查看PageHeap把信息放到哪里了，请打开你的注册表，来到
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options
3：PageHeap的原理是这样，它在已分配的内存的后面放上几个守护字节（Guard Bytes），再跟上一个标记为PAGE_NOACCESS的内存页。这样，已分配内存的后面如果被重写了，那么守护字节就会被改变，于是当内存被释放时，PageHeap就会引发一个AV(Access Violation)。大体上就是这样。所以只有最后释放这块问题内存时，才会有PageHeap的报告！这就是PageHeap的局限性吧。
参数0x01的含义：
FLAGS hex value (0x...) has the following structure:
B7-B0 Bit flags 1 - enable page heap
01 - enable page heap. If zero normal heap is used.
In 99% of the cases you will want this to be set.
02 - collect stack traces (default on checked builds)
04 - minimize memory impact
08 - minimize randomly(1)/based on size range(0)
10 - catch backward overruns
看到了吗？你还可以设置参数为0x10，从而可以检查内存向前的越界写！
想要取消对这个程序的监控，请用 “pageheap.exe /disable
应用程序名” 命令即可。
开启pageheap监控和没开启时完全不一样。开启了监控的情况下，一旦执行这段，就马上会报错，帮助你发现问题。
如果不开监控，执行这段会没有反应，这掩盖了问题，不是个好现象，会使运行结果出错、在特殊条件下崩溃发作。
pageheap的原理是，当有堆分配的时候，在分配的内存的后面放上几个守护字节（Guard Bytes），
再跟上一个标记为PAGE_NOACCESS的内存页。 这样的话，一旦有越界的访问，就会触动这些PAGE_NOACCESS的内存，
可以直接放在 C 盘 下 运行 对文件名监控~~~~~~~~~~~~~~~
Gflags是随着微软Debugging tools for windows一起发布的工具。
使用Gflags就能让系统对heap的分配，访问做一些检查，尽早的发现问题。
Gflags的具体用法请参考微软的帮助文档，就不罗嗦了
Run: gflags
-p /enable test.exe /full /unaligned
那么gflags是如何做到这一点的呢
我们在windbg中去观察一下，不难发现原因
0:000> g
(da8.f88): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=01766ff6 ebx=00000000 ecx=0000000a edx=016c5000 esi=00000001 edi=00403378
eip=0040101f esp=0012ff80 ebp=0012ffc0 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
bbb!wmain+0x1f:
0040101f c6400a0a mov byte ptr [eax+0Ah],0Ah ds:0023:01767000=??
0:000> !address eax
016c0000 : 01766000 - 00001000
Type 00020000 MEM_PRIVATE
Protect 00000004 PAGE_READWRITE
State 00001000 MEM_COMMIT
Usage RegionUsagePageHeap
Handle 016c1000
0:000> !address eax+0a
016c0000 : 01767000 - 00059000
Type 00020000 MEM_PRIVATE
Protect 00000001 PAGE_NOACCESS
State 00001000 MEM_COMMIT
Usage RegionUsagePageHeap
Handle 016c1000
这时候我们通过new得到的内存就刚好在heap块的边界处，这样一旦越界访问，程序就自然报错了。
在cmd窗口输入一下命令来开启相应的调试功能。
开启堆尾检查：gflags /i calc.exe +htc
开启释放检查：gflags /i calc.exe +hfc
开启调用时验证：gflags /I calc.exe +hvc
开启参数检查： gflags /I calc.exe +hpc
开启用户态栈回溯：gflags /I calc.exe +ust
开启页堆：gflags /p /enable 程序名 /full
或者gflags /I 程序名 +hpa
需要关闭时只需要将+变为-即可。
C:UsersAdministrator>gflags /I MemoryCheck.exe +hpaCurrent Registry Settings for MemoryCheck.exe executable are: 02000000
hpa - Enable page heap
C:UsersAdministrator>gflags /I MemoryCheck.exe -hpa
Current Registry Settings for MemoryCheck.exe executable are: 00000000
配置正常页堆：
"C:/Program Files/Debugging Tools for Windows (x86)/gflags.exe" /p /enable qq.exe
配置完全页堆：
"C:/Program Files/Debugging Tools for Windows (x86)/gflags.exe" /p /enable qq.exe /full
列出当前启动了页堆的进程列表：
"C:/Program Files/Debugging Tools for Windows (x86)/gflags.exe" /p
取消页堆设置：
"C:/Program Files/Debugging Tools for Windows (x86)/gflags.exe" /p /disable qq.exe
一些特殊选项解释：
/unaligned
这个选项只能用于完全页堆。当我们从普通堆管理器分配一块内存时，内存总是8字节对齐的，页堆默认情况下也会使用这个对齐规则，但是这会导致分配的内存块的结尾不能跟页边界精确对齐，可能存在0-7个字节的间隙，显然，对位于间隙范围内的访问是不会被立即发现。更准确的说，读操作将永远不能被发现，写操作则要等到内存块释放时校验间隙空间内的填充信息时才发现。/unaligned用于修正这个缺陷，它指定页堆管理器不必遵守8字节对齐规则，保证内存块尾部精确对齐页边界。
需要注意的是，一些程序启用这个选项可能出现异常，例如IE和QQ就不支持。
/backwards
这个选项只能用于完全页堆。这个选项使得分配的内存块头部与页边界对齐（而不是尾部与边界对齐），通过这个选项来检查头部的访问越界。
/debug
指定一启动进程即Attach到调试器，对于那些不能自动生成dump的程序，是比较有用的选项。
完全页堆：
当分配一块内存时，通过调整内存块的分配位置，使其结尾恰好与系统分页边界对齐，然后在边界处再多分配一个不可访问的页作为保护区域。这样，一`旦出现内存读/写越界时，进程就会Crash，从而帮助及时检查内存越界。
因为每次分配的内存都要以这种形式布局，尤其对于小片的内存分配，即使分配一个字节，也要分配一个内存页，和一个保留的虚拟内存页（注意在目前的实现中，这个用作边界保护区域的页从来不会被提交）。这就需要大量的内存，到底一个进程需要多少内存，很难估算，因此在使用Page Heap前，至少保证你的机器至少设置了1G虚拟内存以上。
正常页堆
正常页堆原理与CRT调试内存分配函数类似，通过分配少量的填充信息，在释放内存块时检查填充区域。来检测内存是否被损坏，此方法的优点是极大的减少了内存耗用量。缺点是只能在释放块时检测，不太好跟踪出错的代码位置。
页堆能处理的错误类型：
错误类型 正常页堆 完整页堆
堆句柄无效 立即发现 立即发现
堆内存块指针无效 立即发现 立即发现
多线程访问堆不同步 立即发现 立即发现
假设重新分配返回相同地址(realloc) 90% 内存释放后发现 90% 立即发现
内存块重复释放 90% 立即发现 90% 立即发现
访问已释放的内存块 90% 在实际释放后发现 90% 立即发现
访问块结尾之后的内容 在释放后发现 立即发现
访问块开始之前的内容 在释放后发现 立即发现
以下是举例：
前期工作： 将gflags（默认安装在C:/Program Files/Debugging Tools for Windows (x86)）加入到path
案例1：
int _tmain(int argc, _TCHAR* argv[])
{
char *p = new char[8];
p[8] = 10;
delete[] p;
return 0;
}
程序本身是有问题的。数组已经越界，但是debug模式下并不报错，release模式下也很大可能是不crash的。
在命令提示符下运行：
>gflags /p /enable test.exe /full
在release模式运行test.exe。exception将直接定位到 p[8] = 10; 这一行
案例2：
int _tmain(int argc, _TCHAR* argv[])
{
char *p = new char[9];
p[9] = 10;
delete[] p;
return 0;
}
以上代码和案例1仅有一点不同，就是数组大小。但是如果运行
gflags /p /enable test.exe /full
在release模式下并不会出现exception并定位到 p[9] = 10;
原因是没有设置 /unaligned 参数，具体看说明。案例2中，数组有9字节大小，按内存8字节对齐的说法，这块内存应该是
16字节，后面还有7字节的空间，所以 p[9] = 10; 并不会产生exception。设置 /unaligned 参数，禁止8字节对齐，就
可以跟踪到 p[9] = 10; 这个exception
>gflags /p /enable test.exe /full /unaligned
案例3：
class A
{
public:
int a;
void del(){
delete this;
a = 10;
}
};
int _tmain(int argc, _TCHAR* argv[])
{
A* a = new A();
a->del();
return 0;
}
在debug模式下可能产生exception:
HEAP: Free Heap block xxxxxxxx modified at xxxxxxxx after it was freed
在release模式下运行并不报错，但是程序本身是有问题的，delete this; 之后，又给成员变量 a=10;
这显然是不对的。
>gflags /p /enable test.exe /full
此时在debug下运行程序，会产生exception，并定位到 a = 10;
//----------------------------------------------------------------------------------------------------------------
1. 安装：Debugging Tools for Windows (x86) ；
2. 开启gflags： gflags -p /enable ***.exe /full。 “***.exe”为需要调试的进程名，不需要绝对路径。
3. 启动要调试的程序，当执行异常操作后，VS这才变聪明了，直接指定到了直接导致异常的代码处。顿时，晴空万里。
启动了gflags，调试运行就慢了，比较它要变聪明要学习足够的东西。It's the same to ourselves.
不使用gflags时：
gflags -p /disable ***.exe