【问题标题】:Visual Studio breaks on breakpoint on start randomly while debuggingVisual Studio 在调试时随机启动断点中断
【发布时间】:2016-08-06 01:11:30
【问题描述】:

在 Visual Studio 2015 调试器中启动 Visual C++ ATL/WTL 应用程序时,有时一旦启动调试,Visual Studio 就会在不存在的断点处中断,并在经典异常窗口中声明:

"Appname.exe 已到达断点"
休息 |取消 |继续

没有提供有关异常的其他信息。当我闯入时,有时它会说

没有可用的源代码

而其他时间是

框架不在模块中

不管怎样,当我点击“显示反汇编”时,我看到的是这样的:

...
77038EFD  ?? ?? 
77038EFE  ?? ?? 
77038EFF  dec         dword ptr [ecx-76FBDBBCh]  
77038F05  pop         esp  
77038F06  and         al,8  
77038F08  jmp         __RtlUserThreadStart@8 (77025D93h)  
77038F0D  lea         ecx,[ecx]  
_KiFastSystemCall@0:
77038F10  mov         edx,esp  
77038F12  sysenter  
77038F14  lea         esp,[esp]  
77038F1B  jmp         _KiFastSystemCallRet@0 (77038F20h)  
...

它恰好在

77038EFF  dec         dword ptr [ecx-76FBDBBCh] 

如果我跨步、跨步或继续,应用程序将启动并正常运行。

应用程序在编译时没有优化并且所有调试标志都打开。 正如我在一开始所说的那样,它只发生在某些时候,比如说 1/3 的时间。应用程序在启动之间始终相同。

如果我在 VS 之外启动相同的应用程序,它可以正常工作。

关于什么可能导致这种奇怪行为的任何想法?

【问题讨论】:

  • 尝试删除所有断点,清理并重建项目。
  • @RawN 完成,没有区别
  • 你能看到断点在哪个模块吗?可能是一些 dll 被加载到进程故障中

标签: c++ visual-studio debugging exception visual-c++


【解决方案1】:

事实证明,这种奇怪的行为似乎是通过启用条件断点触发的。

即使断点被禁用,该行为也会继续保持,直到 VS 重新启动。

【讨论】:

  • 更优质的微软工程。
猜你喜欢
  • 2014-03-29
  • 2018-02-08
  • 1970-01-01
  • 1970-01-01
  • 2018-09-09
  • 1970-01-01
  • 2019-03-22
  • 2023-03-08
  • 1970-01-01
相关资源
最近更新 更多