what could cause breakpoints to be ignored?

Rudolf Meier 291

Sometimes I have the problem that break points don't stop. And instead of guessing around, I'd rather like to understand how they work and why the sometimes fail. Now, from my understanding, a break point is a special cpu command "int 3" which triggers the cpu to jump into the debugger (easily explained).

The debugger then does it's stuff by detecting what to show to the developer. Here, at this point, I could imagine, that something goes wrong. In this case I'd expect to see "hey, I hit a debug-break and I have no idea why... I'm showing assembly code" ... but... sometimes when debugging a native (C++) application, nothing happens at all... and sometimes even not when I add a "DebugBreak();" into the code... and the same is true for .net... sometimes, even the hardcoded "System.Diagnostics.Debugger.Break();" has no effect. And I'm wondering why. Because I cannot imagine, that the cpu didn't jump into its interrupt table. So... who the hell handled this? And why did the debugger not get called? Or did it get the info and ignored it? ... why? ... some information would be great.

David Lowndes 2,445 Reputation points MVP

2024-05-14T22:18:01.56+00:00

Have you considered that whatever you're debugging isn't the version you think it is?
Rudolf Meier 291 Reputation points

2024-05-14T22:41:59.37+00:00

Yes, I have.
David Lowndes 2,445 Reputation points MVP

2024-05-14T23:21:12.7133333+00:00

When in the breakpoint ignored state, if you manually break into the debugger (use Debug, Break All), do the breakpoints you have show as enabled or disabled?

Can you set a breakpoint in that state?
Rudolf Meier 291 Reputation points

2024-05-16T19:59:07.9133333+00:00

yes, they are shown as reachable... and I can set them... but they still don't work

I have created a test project that demonstrates this: https://github.com/meirumeiru/BreakpointDemonstrator

info.txt contains the steps to reproduce my problem
David Lowndes 2,445 Reputation points MVP

2024-05-16T21:50:26.0966667+00:00

I'm afraid your project doesn't build for me with VS 2022
Error C2039 'SwitchToMainThreadAsync': is not a member of Microsoft::VisualStudio::Threading::JoinableTaskFactory'
However, as its a C++/CLI project, do you perhaps need to set the debugger to a mixed or managed mode?
Rudolf Meier 291 Reputation points

2024-05-17T07:29:37.2466667+00:00

I had that too... You must make sure, that all the references you link are from the PublicAssemblies folder of the Visual Studio installation and the Threading assembly comes from the subfolder PublicAssemblies\Microsoft.VisualStudio.Threading.16.0 (or whatever the version is for 22).

And, the mode of the debugger doesn't change anything. I tried them all (even the .net core one, which can never be the correct one... but, just wanted to be sure that I don't miss anything).
David Lowndes 2,445 Reputation points MVP

2024-05-17T10:25:57.51+00:00

OK, replacing the Microsoft.VisualStudio.Threading.dll reference with the one found in C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.Threading.17.x allows that project to build, however the VSIXBreakpointDemonstrator project reports loads of warnings starting with:

Found conflicts between different versions of "envdte" that could not be resolved.warning MSB3277: There was a conflict between "EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "envdte, Version=17.0.0.0,...

Presumably you don't get those?
Rudolf Meier 291 Reputation points

2024-05-17T23:41:29.59+00:00

well... I did build the sample for VS2019... the problem is, that in VS2022 you need completely different assembly references... I have such projects too, but unfortunatelly this one is for 2019 since it's still the VS-version we are mainly working with here

Share via

what could cause breakpoints to be ignored?