DebugBreak() 导致 Win7 x64 在一台特定计算机上挂起？可能设置有问题？
我们使用 DebugBreak() 和/或 asm int 3 作为在发生断言时停止单元测试框架的方法。单元测试框架作为用户模式应用程序运行。
我们运行的是win 7 x64企业版，通常使用vs2008，但也使用Windbg。通常，当调用 DebugBreak 时，会弹出“检查解决方案/关闭/调试”对话框。
在一台用户的计算机（Dell T5500，8 核，12GB）上，DebugBreak 调用导致整个计算机停止。时钟小部件停止滴答作响，鼠标停止移动，键盘停止响应。即使我们检查了它的配置，该对话框也不会弹出。我们需要强制关闭机器才能执行进一步的操作。
有谁知道任何类型的 Windbg 或其他 JIT 调试选项可能会导致此问题？该用户猜测他的机器可能表现得像为远程调试设置的那样，但这不是内核断点。我们经常使用远程调试，但是挂起的机器通常是调试器，而不是被调试者。
We're using DebugBreak() and/or asm int 3 as a method to stop our unit test framework when an assertion happens. The unit test framework runs as a user mode application.
We're running win 7 x64, enterprise edition, and generally using vs2008, but also Windbg. Usually, when the DebugBreak is called, the "check for solutions/close/debug" dialog pops up.
On one user's machine (Dell T5500, 8 cores, 12GB) the DebugBreak call causes the whole machine to stop. The clock widget stops ticking, mouse stops moving, keyboard stops responding. The dialog does not pop-up, even though we've checked that it is configured to. We need to force shutdown the machine to do anything further.
Is anyone aware of any kind of windbg or other JIT debug option that might cause this? This user has guessed that his machine might be acting like its set up for remote debugging, but this isn't a kernel breakpoin. We often use remote debugging but the machine that is hanging is usually the debugger, not the debugee.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因此，经过重新考虑和重新调查后，发现开发人员很久以前就在他的开发系统上启用了调试器，因此 DebugBreak 实际上是在停止内核。在他的机器上：
C:\>bcdeditWindows Boot Manager--------------------
标识符 {bootmgr}
设备分区=\Device\HarddiskVolume1
描述 Windows 启动管理器
区域设置 en-US
继承{全局设置}
默认{当前}
超时 30
恢复对象 {fdc7f9bc-32c9-11df-8189-b982443308cd}
显示顺序{当前}
工具显示顺序 {memdiag}
Windows 启动加载程序-------------------
标识符{当前}
设备分区=C:
路径 \Windows\system32\winload.exe
描述 Windows 7
区域设置 en-US
继承{bootloadersettings}
恢复序列 {fdc7f9c0-32c9-11df-8189-b982443308cd}
恢复启用 是
osdevice 分区=C:
系统根\Windows
恢复对象 {fdc7f9bc-32c9-11df-8189-b982443308cd}
nx 选择加入
debug Yes
禁用后一切正常。感谢您抽出时间。
So, after reconsidering and re-investigating, it turns out the developer had enabled the debugger on his development system a long time ago, so the DebugBreak was actually stopping the kernel. From his machine:
C:\>bcdeditWindows Boot Manager--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
timeout 30
resumeobject {fdc7f9bc-32c9-11df-8189-b982443308cd}
displayorder {current}
toolsdisplayorder {memdiag}
Windows Boot Loader-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows 7
locale en-US
inherit {bootloadersettings}
recoverysequence {fdc7f9c0-32c9-11df-8189-b982443308cd}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {fdc7f9bc-32c9-11df-8189-b982443308cd}
nx OptIn
debug Yes
Disabling that made everything work correctly. Thanks for your time.