0

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)
teodron
  • 1,410
  • 1
  • 20
  • 41
  • 1
    A newer version of VS perhaps? – EDD Nov 10 '16 at 13:45
  • Hmm, if it is "closed source" then it isn't very obvious how you set a breakpoint on the source code. The breakpoint isn't going to work and turn from a hollow ring to a solid red blob until the DLL gets loaded and the debugger found the matching PDB file. Use the Debug > Windows > Modules list to verify that this happened. – Hans Passant Nov 10 '16 at 13:51
  • @HansPassant I do have the source code for the dynamic library that is consumed by the executable. The breakpoint is, during the first run, active and gets triggered. After the invalid access occurs, VS2008 simply refuses to recognize the breakpoint. The module window confirms the symbols are loaded. – teodron Nov 10 '16 at 13:53
  • @HansPassant I have found the issue - I must admit it was a bit frustrating to not having noticed that the project was built with /clr support, although the dll entrypoint unit was compiled with no /clr flags. – teodron Nov 11 '16 at 08:02

1 Answers1

0

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.).

Community
  • 1
  • 1
teodron
  • 1,410
  • 1
  • 20
  • 41
  • 1
    since this issue has been resolved, please mark it as the answer, so it could help other community members:) Have a nice day! – Jack Zhai Nov 14 '16 at 11:20