While starting a Visual C++ ATL/WTL application in the Visual Studio 2015 debugger, sometimes as soon as debug is launched Visual Studio breaks on a non existing breakpoint stating, on the classic Exception window:
"Appname.exe has hit a breakpoint"
Break | Cancel | Continue
No other information is given about the exception. When I break into, sometimes it says
No source code available
while some other times is
Frame not in module
Either way, when I click on "Show disassembly", this is what I see:
...
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)
...
It breaks exactly on
77038EFF dec dword ptr [ecx-76FBDBBCh]
If I step over, step into or continue, the application starts and works normally.
The application is compiled with no optimization and with all debug flags on. As I stated at the beginning, it happens only sometimes, let's say 1/3 of the times. The application is always the same between launches.
If I start the very same application outside VS, it works normally.
Any ideas on what could cause this strange behaviour?
As it turns out, it seems that this strange behaviour is triggered by enabling a conditional breakpoint.
Even if the breakpoint is disabled, the behaviour continues to remain until VS is restarted.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With