Question

在一个生产现场，我们的应用程序^（*）反复崩溃，但不可重现。分析崩溃转储清楚地表明它是一个堆损坏：崩溃位于不同的位置，但总是访问kernel32!HeapFree / ntdll!RtlpLowFragHeapFree内的违规行为。 Win Dbg !analyze -v也报告堆损坏。

到目前为止，我们尝试使用GFlags选项Page Heap运行应用程序。问题是页面堆的内存开销导致应用程序不再运行（达到32位进程的虚拟内存限制）。

所以，我们不能使用Page Heap 。添加哪个其他flags非常有用，以便我们

在腐败网站上崩溃
或者至少可以从我们在HeapFree崩溃时最终生成的崩溃转储中获取更多信息？

我们目前正在试用旗帜：

希望下一个崩溃转储包含更多关于出错的信息。

我考虑了这些标志，但暂时将它们排除在外：

Enable heap parameter checking ...每次调用堆函数时系统会检查时会产生很大的开销
Enable heap free checking ...不确定这是否真的会给我带来任何东西
Enable heap validation on call ...这里甚至是文件警告高开销

我（也）遇到的一个问题是，我不确定这些标志在发生内存损坏时如何起作用。当某些内容写入保护页面时，页面堆显然会产生访问冲突，但其他标志如何操作？

我是否必须使用Application Verifier运行应用程序以获取其他标志才能提供帮助？或者在检查代码检测到某些内容时会引发异常吗？

这些标志的哪种组合最有意义，以便应用程序仍可以在生产中以良好的性能和内存消耗运行？

<子> （*）：它是工业自动化中的32位Windows桌面应用程序。在这种情况下运行在Win7 64bit上（它在许多其他站点上运行得很好）。

Answer 1

来自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]*

Answer 2

恕我直言，控制所有这些检查的最简单方法是使用ApplicationVerifier。你有一个完美的UI，你可以玩各种旗帜。
堆免费检查是一个很好的标志，没有太多的开销。因此，如果堆块被严重修改并且块被释放，那么您将进入调试器。如果在分配和释放块附近发生损坏，这可能会有所帮助。
AFAIK“堆参数chechking”只是一个轻量级的“调用堆验证”。我从来没有取得任何成功。
堆尾检查和标记简单快捷。有时为我工作。

你知道你也可以使用gflags在每个应用程序基础上控制它。

gflags.exe / i Testapp.exe e0

但是：找到这些问题的最好方法是完全使用Debug-CRT ......如果可能的话。因此，如果有机会在生产环境中使用Debug-Version，请执行此操作。在Debug-CRT里面你还可以使用很多标志并设置....

GFlags设置为捕获堆损坏（除了页面堆）？

2 个答案: