我正在尝试使用boundschecker来分析一个相当复杂的程序。使用boundschecker运行程序几乎太慢而无法使用它，因为我需要将近一天的时间来运行程序到我怀疑问题存在的代码中。任何人都可以给我一些关于如何在Visual Studio 2005中使用boundschecker（DevPartner）检查我的软件的某些部分的想法吗？
提前感谢您的帮助！
答案 0 :(得分：2)
几年前我上次使用过BoundsChecker，并遇到了同样的问题。对于大型项目，它使一切运行得如此缓慢以至于无用。我们最终放弃了它。
但是，我们仍然需要它的一些功能，但是和你一样，不是整个程序。所以我们必须自己做。
在我们的例子中，我们主要使用它来尝试跟踪内存泄漏。如果这也是你的目标，还有其他选择。
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif
那些帮助很多，但通常还不够。在任何地方添加该代码段并不总是可行的。如果您使用工厂类，知道分配内存的位置根本没有帮助。所以当其他所有方法都失败时，我们会利用＃2。
添加以下内容：
#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}
然后，用“LEAK（”leak1“）胡椒你的代码;”管他呢。运行该程序，然后退出。您的新泄漏字符串将显示在Visual Studio的泄漏转储中，围绕现有泄漏。继续添加/移动您的LEAK语句并重新运行程序以缩小搜索范围，直到您确定了确切位置为止。然后修复泄漏，删除你的调试漏洞，你就完全了！
答案 1 :(得分：0)
BoundsChecker极其详细地跟踪所有内存分配和发布。例如，它知道这样的内存分配是从C运行时堆完成的，而后者又是从Win32堆中获取的，而Win32堆又开始作为VirtualAlloc分配的内存。如果应用程序已经过检测（FinalCheck），它还会提供有关哪些指针引用内存的详细信息。
这是（很多）原因之一的原因之一。
如果BC要迟到一个应用程序连接，它将不会建立这些数据，并且会（1）一次性全部挖掘，或者（2）开始猜测事情。这两种解决方案都不太实用。
答案 2 :(得分：0)
减轻BoundsChecker的一种方法是从仪器中排除除了你感兴趣的几个模块之外的所有模块。我知道这不是很好，因为如果你知道泄漏的位置，你将不需要BoundsChecker。我通常建议您首先使用BC的主动检查模式，仅提供内存跟踪。您错过了API验证，但您可以随时重新运行。运行Active Check并获得有关哪些模块往往存在问题的线索后，才会启用对感兴趣的模块或模块及其依赖项的检测。我们知道最终检查非常缓慢，但正如Mistiano正确指出的那样，最终检查不仅BC保留了所有已分配块的图形，而且还保留了所有指针和上下文的图形。最终检查如何在发生时确定泄漏和损坏，而不仅仅是应用程序关闭或故障，这就是神奇的。无耻的插件：我在DevPartner团队工作。我们将于2011年2月4日发布DPS 10.5，并在BC提供x64应用程序支持。与仅提供Active Check的相对古老和未售出的Itanium BC64不同，DPS 10.5为x64应用程序提供完整的Final Check支持，包括纯C ++和在.NET进程中运行的本机模块。有关详细信息，请参阅MF Developer下的microfocus.com。