2

I've looked through the answers to about 5 similar questions, and particularly the top page of answers to this 1.5k upvoted question, but none of the fixes in there do anything for me.

I've inherited a C# project and am trying to debug it. I'm a bit new at C#, but have more than a decade experience with Visual C++. So I know my way around the debugger a bit at least, and have had to deal with debugging DLL's before. However, this one has me stumped.

I can set breakpoints in the main project's .cs files and they work just fine, but when I try to set one in a sub-project dll ("assembly"?) all the breakpoints show up at runtime with "The breakpoint will not currently be hit. No symbols have been loaded for this document."

What I've tried:

  • Clean and rebuild.
  • Clean, delete all copies of the dll and pdb from my hard drive, rebuild.
  • Verified the project props are set to Define DEBUG constant, Define TRACE constant.
  • Set the subproject (assembly) as the startup project, with the main exe (in the same directory as the DLL and PDB) as the Start external program
  • In the project build settings, Debug Info is set to full, and Optimize code is not set.
  • The debug option Enable Just My Code is not checked (I checked it, there's no checkmark in the box).
  • I'm not trying to build or debug in a Release configuration.

I've also checked the loaded DLL in process explorer and the Symbol Load Information in the debugger, and they match:

Process Explorer: enter image description here

VS 2012's Symbol Load Information: enter image description here

So its clearly got some PDB loaded, its in the same directory as the DLL, and they both get built when I build the project. The timestamp on the two files is identical. Yet VS'debugger doesn't think symbols are loaded for that file.

T.E.D.
  • 44,016
  • 10
  • 73
  • 134
  • It seems like you've covered a lot of bases. The only other thing I can think of is to confirm that the symbols are loaded in DEBUG -> Windows -> Modules. – itsme86 May 20 '20 at 22:22
  • 1
    @itsme86 - It is. That's what the second picture is from. But thank you for looking my question over. I was afraid nobody would. – T.E.D. May 20 '20 at 22:24
  • So the things we don't know is what is special about that .exe you have to select to start debugging. And why you have to use such an ancient version of VS and whether it had all of its service packs applied (5 of them iirc). [Also relevant](https://devblogs.microsoft.com/devops/switching-to-managed-compatibility-mode-in-visual-studio-2013/). – Hans Passant May 20 '20 at 23:33
  • @T.E.D. Find `symcheck` among the installed SDK(s) and see what `symcheck dcn_lib.dll` reports. You'll probably need to enter the full path at the cmd prompt e.g. `"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\symchk.exe"`. – dxiv May 21 '20 at 00:10
  • @dxiv - symchk dcn_lib in that directory returns with: "SYMCHK: FAILED files = 0 SYMCHK: PASSED + IGNORED files = 0" – T.E.D. May 21 '20 at 17:24
  • @HansPassant - There's nothing special about this .exe that I know of (which is actually relatively unusual for us). It reads in a mess of XML files and VS project files and performs some code generation (off in another directory). As for why its VS2012, our company doesn't upgrade quickly due to really complex cross-tool and hardware compatibility issues with our main product (which is not this program). I might be able to bump it up to VS2016 with only a day or so of work, but I *just* inherited this code, and step 1 is to get familiar with it in its natural habitat. – T.E.D. May 21 '20 at 17:32
  • We do support our stuff long after we release it, which means I often have to make do with some rather old tools. I had to tweak something to work under VS6 a couple of years back. We have quite a few pre-Linux Unix platforms out there too, and not too much earlier than that I had to help move a PDP-11 installation onto an emulator. – T.E.D. May 21 '20 at 17:47
  • @T.E.D. All of failed/passed/ignored being `0` looks like nothing was processed. Try entering the full name *with* extension. – dxiv May 21 '20 at 18:15
  • @dxiv - Huh. Now with *that* I at least get something interesting: "SYMCHK: dcn_lib.dll \t FAILED - dcn_lib.pdb mismatched or not found". I just checked and the pdb is right there with the DLL, with an identical date/timestamp. I don't suppose there's a way to check that it isn't picking up (or failing to pick up) the PDB from somewhere else? – T.E.D. May 22 '20 at 00:01
  • @T.E.D. Add `/od /v` at the end of the command line, and look at names and signatures in particular. Maybe also add `/s .` to force picking up the .pdb from the current dir. – dxiv May 22 '20 at 00:12

0 Answers0