在调试程序中遇到提示“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 <address>)或者是给出Break caused by hard coded breakpoint instruction.,在这样的情况下,只要让调试继续进行即可(按下F5键)。
值得注意的是当程序涉及到全局性的共享内存(对象)时,如CShareFile,这些对象维护着一个全局性的内存块,如果因为程序的疏忽对仍然锁定的对象 (locked object)进行释放内存的话,则在NT下也会出现User breakpoint called from code at <address>这样的提示。
此外,在低版本的Visual C++调试器中,在不少地方(例如一些有关打印设备的操作)都用到GlobalLock,编程不当也会导致上述的提示出现,不过在win32中,很多这样的调用已经不再必要了。
希望这些信息能对您有所帮助,建议您检查一些是不是程序当中有一些涉及到释放全局性内存的操作。
- 微软全球技术中心 VC技术支持
例如在Windows NT下当正被调试的应用程序获得焦点时,如果F12键按下,则Windows NT调用一个类似于DebugBreak()函数的函数,这个被调用的函数执行一个hard coded breakpoint instruction,于是调试器捕捉到这个操作产生的例外,所以中断并给出上述的提示(User breakpoint called from code at <address>)或者是给出Break caused by hard coded breakpoint instruction.,在这样的情况下,只要让调试继续进行即可(按下F5键)。
值得注意的是当程序涉及到全局性的共享内存(对象)时,如CShareFile,这些对象维护着一个全局性的内存块,如果因为程序的疏忽对仍然锁定的对象 (locked object)进行释放内存的话,则在NT下也会出现User breakpoint called from code at <address>这样的提示。
此外,在低版本的Visual C++调试器中,在不少地方(例如一些有关打印设备的操作)都用到GlobalLock,编程不当也会导致上述的提示出现,不过在win32中,很多这样的调用已经不再必要了。
希望这些信息能对您有所帮助,建议您检查一些是不是程序当中有一些涉及到释放全局性内存的操作。
- 微软全球技术中心 VC技术支持