对 User breakpoint called from code at XXX 问题分析汇总

分析一，转自独奏的同名Blog

      今天调试程序时在Debug版跳出这个错误，我程序根本没设置断点，而其好像说是我的堆有问题，而编译了个Release版本运行正常，后来google下，查到如下解释：

      说是调试状态下，操作系统用DebugWin32Heap来替代正常的heap分配内存空间。在这个堆上的任何操作debug的堆管理器会检查堆的数据完整性，如果它发现了一个错误，就会报告一个消息上来。当一个应用程序PageHeap机制被激活时，该应用程序的所有的堆分配被放到内存中，这样堆的边界就与虚拟内存的边界排在一起了。与堆相邻的虚拟内存页面被设置为NO_ACCESS。在该应用程序中对堆后面的空间的访问就会立刻引起错误，这就可以在一个调试工具中被捕获。在释放堆时，过程与之类似。PageHeap修改释放的应用程序虚拟页面为NO_ACCESS，这样，如果应用程序试图读写该内存时就会发生访问错误。

      既然是Heap的问题我就查遍了所有源代码的new和delete操作的代码，感觉没有任何问题，该分配的都分配了该释放的也都释放了，而且没有错误情况。后来没办法弄个极端的，我把程序的中所有delete 的语句全部注释，再运行程序果然没问题了- - 。我又继续查了下程序，感觉还是没问题。后来定位到一条delete， 只要有它程序就报错，没有就正常。这个delete位于一个移除服务的函数中，这里有必要说下我的程序结构

      我将服务全部存入dll中，主要函数一个四个(其他的就不说了)
      createSrv 建立服务 removeSrv 移除服务 runSrv 运行服务 stopSrv 停止服务

      而这个delete正好位于removeSrv中，但是我的delete没有任何问题。后来没办法又google下，找到了一个和我遇到同样问题的人，引用原文如下：

      "重复释放导致的问题,User breakpoint called from code at 0x77f9193c ,以上原因是由于释放了一个类的员，最后在作该类的析构时由于它的成员已经被释放导致出错(该成员被释放但是没有设 NULL)"

      看完这句话后我立刻去看我的类的析构函数(由于我的dll为了通用并不是导出类而是导出函数，而我调用方编写了调用类来调用dll导出函数，到统一管理和封装的目的)。果然 - -|| ：我怕万一我的调用没有" stopSrv 停止服务"和"removeSrv 移除服务" ，我在析构函数中又调用了这个两个函数，郁闷我从9点陆陆续续调试到现在 - - ......写此文章警示后人......

分析二，转自除虫记之十二：费解的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

分析三，转自jiahehao的同名Blog

在调试程序中遇到提示“user  breakpoint  called  from  code  at  0x......(地址)”时，这并不一定是因没用户设置了断点的关系，而是因为系统执行了一个硬编码断点操作(hard  coded  breakpoint  instruction)。    

例如在Windows  NT下当正被调试的应用程序获得焦点时，如果F12键按下，则Windows  NT调用一个类似于DebugBreak（）函数的函数，这个被调用的函数执行一个hard  coded  breakpoint  instruction，于是调试器捕捉到这个操作产生的例外，所以中断并给出上述的提示（User  breakpoint  called  from  code  at 

）或者是给出Break  caused  by  hard  coded  breakpoint  instruction.，在这样的情况下，只要让调试继续进行即可（按下F5键）。   
 
值得注意的是当程序涉及到全局性的共享内存（对象）时，如CShareFile，这些对象维护着一个全局性的内存块，如果因为程序的疏忽对仍然锁定的对象 (locked  object)进行释放内存的话，则在NT下也会出现User  breakpoint  called  from  code  at 

这样的提示。    
 
此外，在低版本的Visual  C++调试器中，在不少地方（例如一些有关打印设备的操作）都用到GlobalLock，编程不当也会导致上述的提示出现，不过在win32中，很多这样的调用已经不再必要了。    
 
希望这些信息能对您有所帮助，建议您检查一些是不是程序当中有一些涉及到释放全局性内存的操作。