在一个生产站点上，我们的应用程序(*) 反复崩溃，但无法重现。分析崩溃转储清楚地表明它是堆损坏:崩溃发生在不同的位置，但始终在 kernel32!HeapFree/ntdll!RtlpLowFragHeapFree 内访问冲突。 Win Dbg !analyze -v 也报告堆损坏。
到目前为止我们尝试的是使用 GFlags 运行应用程序选项 Page Heap .问题是页面堆的内存开销使得应用程序将不再运行(达到 32 位进程的虚拟内存限制)。
所以，我们不能使用页面堆。还有哪个flags添加将很有用，这样我们要么
- 在腐败现场撞车
- 或者至少可以从我们在
HeapFree中崩溃时最终生成的故障转储中获取更多信息？
我们目前正在尝试这些标志:
希望下一个故障转储将包含更多有关错误原因的信息。
我考虑过这些标志，但暂时将它们排除在外:
- Enable heap parameter checking ... 当系统每次调用堆函数时进行检查时，我预计会有相当多的开销
- Enable heap free checking ...不确定这是否真的能给我买任何东西
- Enable heap validation on call ...这里甚至连文档都警告过高的开销
我(也)遇到的一个问题是，我不确定这些标志在发生内存损坏时如何提供帮助。 Page Heap 显然会在保护页写入内容时产生访问冲突，但其他标志如何操作？
我是否必须使用 Application Verifier 运行应用程序才能获得这些其他标志的帮助？还是检查代码检测到异常时会抛出异常？
这些标志的哪种组合最有意义，以便应用程序仍然可以在生产中以良好的性能和内存消耗运行？
<子> (*) : 它是工业自动化中的 32 位 Windows 桌面应用程序。在这种情况下在 Win7 64 位上运行(它在很多其他站点上运行得很好)。
最佳答案
gflags GUI 中的“启用页面堆”启用完整 页面堆验证，这可能会导致您描述的问题。 gflags 命令行为您提供更多控制，并允许您启用标准 页面堆验证，它使用较少的内存但功能较弱。命令行还使您能够使用/size、/dlls 和/address 选项混合使用标准和完整。
以下是 debugger.chm 帮助文件中列出的选项:
*To enable and configure page heap verification:
gflags /p /enable ImageFile [ /full [/backwards] | /random Probability | /size SizeStart SizeEnd | /address AddressStart AddressEnd | /dlls DLL [DLL...] ] [/debug ["DebuggerCommand"] | /kdebug] [/unaligned] [/notraces] [/fault Rate [TimeOut]] [/leaks] [/protect] [/no_sync] [/no_lock_checks]*
关于windows - GFlags 设置以捕获堆损坏(Page Heap 除外)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19023230/