解决“User breakpoint called from code at XXXX”Bug

最新推荐文章于 2021-11-12 10:10:11 发布

ayw_hehe

最新推荐文章于 2021-11-12 10:10:11 发布

阅读量723

点赞数

分类专栏： C/C++ 文章标签： user debugging 工具 delete exception output

C/C++ 专栏收录该内容

119 篇文章

订阅专栏

本文探讨了在NTDLL中出现的意外用户断点问题，分析了其背后的原因及如何利用DebugWin32Heap、BoundsChecker和PageHeap机制进行诊断。通过详细步骤指导读者定位并解决内存操作错误。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

原贴地址：http://blog.vckbase.com/hyj/archive/2006/06/28/21006.html

除虫记之十二：费解的NTDLL断点

处理在NTDll中意外的用户断点

很久没有写东西了，这次是为了完善很久很久以前写的一个培训ppt(VC的使用与调试技巧)，才想起来写点东西的。下面的文章参考了http://www.debuginfo.com/tips/userbpntdll.html，但不是翻译，偶英语太烂了。

我们在调试程序的过程中，有时会突然的显示一个对话框，上面显示这样一条信息： User breakpoint called from code at 0x77fa018c 或者是 Unhandled exception at 0x77f767cd (ntdll.dll) in myapp.exe: User breakpoint. 不过我遇到过的都是第一条信息，没有遇到过第二条信息。

怎么回事？我们没有设置断点呀！为什么会有一个用户断点？并且这个问题看起来并没有那么严重，不在调试状态下，程序正常运行，即使在调试状态下我们把这个对话框按了确定后，再继续F5，好像什么事情也没有发生，程序仍然在正常运行！

隐患！千万不要忽视她！这个信息告诉我们，程序中某个地方已经开始溃烂，如果你频繁的碰到这个对话框，就说明溃烂已经扩大了。

如果你够仔细，你会发现在你点了这个对话框的确定按钮之后，会在Output窗口中发现多了一行信息： HEAP[DebugInfo2.exe]: Heap block at 00030FD8 modified at 00031010 past requested size of 30

查看堆栈窗口，里面显示这样的信息： NTDLL! 7c921230() NTDLL! 7c97db9c() NTDLL! 7c98cd11() NTDLL! 7c980af8() KERNEL32! 7c85e7af() _CrtIsValidHeapPointer(const void * 0x00031000) line 1697 _free_dbg(void * 0x00031000, int 0x00000001) line 1044 + 9 bytes operator delete(void * 0x00031000) line 49 + 16 bytes WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00151f15, int 0x00000001) line 13 + 15 bytes WinMainCRTStartup() line 198 + 54 bytes KERNEL32! 7c816d4f()

重现这样的现场很容易的，只需几行代码就可以了 char *p = new char[4]; lstrcpy(p, "this is a test"); delete p;

为什么会有这样的信息消息框出现呢？这是因为如果我们在调试状态下，操作系统用DebugWin32Heap来替代正常的heap分配内存空间。在这个堆上的任何操作，debug的堆管理器会检查堆的数据完整性，如果它发现了一个错误，就会报告一个消息上来。

那么，我们怎么样才能知道造成错误的原因呢？如果只是类似上面的演示代码，不用任何技巧都能发现并且定位的。但是，绝大多数情况下，Output窗口和CallStack窗口告诉我们的信息都不能让我们精确定位。

用BoundsChecker做运行期的检查可以查到这个错误的原因，并且我个人认为在程序发布之前，在BoundsChecker下完整的跑一遍，检查内存和资源是非常有必要的。但是每次都用BoundsChecker是比较麻烦的。

还有一个办法，可以让这种定位更准确一点。

那就是windows 2000 SP2之后提供的PageHeap机制。

下面的这段文字是别人写的，我抄的，：）当一个应用程序的PageHeap机制被激活时，该应用程序的所有的堆分配被放到内存中，这样堆的边界就与虚拟内存的边界排在一起了。与堆相邻的虚拟内存页面被设置为NO_ACCESS。在该应用程序中对堆后面的空间的访问就会立刻引起错误，这就可以在一个调试工具中被捕获。在释放堆时，过程与之类似。PageHeap修改释放的应用程序虚拟页面为NO_ACCESS，这样，如果应用程序试图读写该内存时就会发生访问错误。如果为一个应用程序运行PageHeap特性，应用程序要比正常时运行得慢，并且需要更多的虚拟内存，因为每一个堆的分配都需要两个完整的虚拟内存页面。随着应用程序对堆的使用的增加，可能需要增加系统的虚拟内存的大小，否则会出现虚拟内存不够的错误信息。除非系统有相当大的虚拟内存，否则建议不要同时运行两个以上的激活了PageHeap特性的应用程序。

让我们的程序启用Full Page Heap机制，只需在注册表中 HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options/YourAppName.exe下增加如下设置： GlobalFlag，字符串类型，值是x02200000 PageHeapFlags，字符串类型，值是0x3 VerifierFlags，DWORD类型，值是00000001 其中YourAppName.exe换成你的程序的名字，不要带路径。

如果嫌麻烦，你可以到http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx下载Debugging Tools for Windows，安装后，有一个gflags工具，使用下面的命令： gflags –p /enable YourAppName.exe /full 这个工具帮你写好了上面的注册表项目。这个工具是一个GUI的程序，你可以双击并且设置相关调试入口。

如果设置了Full PageHeap模式，我们在调试运行的时候，那么就会在弹出那个令人费解的断点对话框之前出现一个断言对话框，哈哈，这个对话框可是有一个Retry按钮的，点击之后进入CallStack，你可以看到此时发生了什么了。

如果你编写的是一个dll，也可以使用这个机制的，不过注册表项下的值就要设置成如下： GlobalFlag，字符串类型，值是0x02000000" PageHeapTargetDlls，字符串类型，值是调试的dll名称，不带路径 VerifierFlags，DWORD类型，值是00000001 PageHeapFlags，字符串类型，0x403

或者使用命令行 gflags –p /enable YourAppName.exe /full /dlls YourDll.dll