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

i reproducing following behavior in vs2008 (native c++):

• attach executable consumes custom dll (for have source)
• debug code dynamic lib
• encounter access violation error (probably caused code in executable - closed source)
• break on access violation error attached debugger

after this, no matter how many times reattach, rebuild, restart application, computer, breakpoint set in .dll source code becomes inactive (no executable code associated line alleged cause, according vs).

i suspect issue vs2008, did same on different machine , have 2 machines debugging no longer possible.

are there recorded solutions of issue? can done overcome it?

---

what have done:

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

what cannot do:

• change compiler/vs version
• debug executable (sadly no source code available , lack of assembly skills)

the root of issue more subtle. although project intended native c++, have found on configuration testing code, entire project built clr support.

when attaching application first time on machine, in native debugging mode, breakpoints trigger. however, when encountering native access violation error, these breakpoints became permanently inactive thereafter. after deciding check happens if let debugger attach in auto mode, have discovered breakpoints became active , hence found out code had been compiled /clr flag except entrypoint in consumed dll, had no clr support.

the question here why vs2008 behaves , not directly disable breakpoints whenever 1 attempts debug managed context using native debug settings.

---

tl;dr: check if c++ project built clr support , attach either native or managed, depending on needs. alternatively, if of files require c++-cli usage, enable /clr flag those. more better choice since c++-cli clashes native libraries (e.g. not std::mutex support, linking against native static libs linking unmanaged c++ dll managed c++ class library dll, etc.).