VS2008 C++ breakpoint becomes permanently inactive after access violation error (no executable code associated with line)

Question

I am reproducing the following behavior in VS2008 (native C++):

• attach to an executable that consumes a custom dll (for which I have the source)
• debug the code from the dynamic lib
• encounter an access violation error (probably caused by the code in the executable - closed source)
• break on access violation error with the attached debugger

After this, no matter how many times I reattach, rebuild, restart the application, computer, any breakpoint I will set in the .dll source code becomes inactive (No executable code associated with this line is the alleged cause, according to VS).

I suspect this is an issue with VS2008, as I did the same on a different machine and now I have two machines where debugging is no longer possible.

Are there any recorded solutions of this issue? What can be done to overcome it?

---

What I have done:

• deleting everything (the entire solution, pdbs, binaries, etc.) and starting with the code from scratch (cloning the latest version from the repository)
• restarting the machine
• changing the machine (it worked once, until the error occurred, then the other computer exhibited the same behavior)

What I cannot do:

• change compiler/VS version
• debug the executable (sadly no source code available and lack of assembly skills)

Answer 1

The root of the issue was more subtle. Although the project was intended to be native C++, I have found that on the configuration I was testing the code, the entire project was built with CLR support.

When attaching to the application the first time on any machine, in native debugging mode, the breakpoints would trigger. However, when encountering the native access violation error, these breakpoints became permanently inactive thereafter. After deciding to check what happens if I let the debugger attach in auto mode, I have discovered that the breakpoints became active and hence found out that all code had been compiled with the /clr flag except for the entrypoint in the consumed dll, which had no CLR support.

The question here is why VS2008 behaves like this and does not directly disable breakpoints whenever one attempts to debug a managed context using native debug settings.

---

TL;DR: check if your C++ project is built with CLR support and attach either as native or managed, depending on your needs. Alternatively, if only some of your files require C++-CLI usage, enable the /clr flag only for those. It is more often a better choice since C++-CLI often clashes with certain native libraries (e.g. not std::mutex support, linking against native static libs Linking unmanaged C++ DLL with managed C++ class library DLL, etc.).