因此，我的公司使用了一个令人愉悦的bug程序，称为Rational Purify（作为Microsoft Visual Developer Studio的插件）来管理内存泄漏。 该程序的设计是让您在遇到内存泄漏后单击它，然后跳到发生泄漏的那一行。
不幸的是，Purify发生了故障，Purify不会跳到发生泄漏的地方，它只提到发生泄漏的类别和方法。不幸的是，有时这与雇用指南来帮助您猎杀熊并让他指点一样有用。到森林里，告诉你那里有熊。
有Purify经验的人对我如何解决此问题有任何想法，或者有好的手册可供参考吗？
净化就像瑞士刀。 如果您知道如何使用它，将会得到一些结果，虽然不是最好的，但仍然会得到结果。 如果您不这样做，它将崩溃，因为它只是Windows上运行的另一个程序。
最后，您将需要大量的耐心，重建和一点运气。
Purify带有一个名为ScanVSSolutionForPurifyPlus.pl的脚本，该脚本将确保您的项目文件具有Purify正常运行的所有正确设置。 如果尚未运行，请尝试一下。
（我在大型解决方案上亲自使用过ScanVSSolutionForPurifyPlus.pl，它像一个魅力一样工作。一个警告：当给它命名.sln文件时，可能需要给它完整的路径名。）
通常，您有两种选择，一种是从Purify的检测中排除模块DLL，这有时会有所帮助。 第二个是获取BoundsChecker，这确实会使编译时工具慢得多，但细节水平却好了一个数量级。
当我们知道存在错误/崩溃时，通常会在签入，健全性检查和BoundsChecker中使用Purify。
BoundsChecker具有一些不错的功能，例如仅乐器文件A.cpp和B.cpp，不包括所有其他文件。
请注意，这两个应用程序均不能在64位操作系统上运行，并且BoundsChecker不会安装在64位操作系统上。 如果您切换到具有32位后置端口的本机64位开发，则最令人沮丧！
我大约5年前使用Purify。 那时真是片状。 他们一直承诺会修复“下一个版本”中的所有错误。 最后我们放弃了。 只能怀疑他们是否在产品上使用了自己的质量检查工具。 讽刺的是...
您确定您有调试版本吗？ 还是您已启用所有PDB？ 在可执行文件上尝试WindDbg，然后使用！lmi命令检查可见的内容。
是否正确检测了整个代码？
还可以考虑使用其他免费软件，例如免费的Visual Leak Detector或Microsoft的工具LeakDiag。
