Its very easy to forget how bloody large Visual Studio can be, whatever the incarnation. Every now and then, you'll stumble across something that just makes you think "damn, thats pretty cool", and wonder why you didn't know about it sooner. Yesterday, I had one of those times. It was just a small thing, but I think its changed how I'll be debugging applications from this point forward, especially tricky components that dont always play nice with the debugger out the box (I'm looking at you, shonky legacy ActiveX controls).

I was in the process of wrestling with a custom BizTalk Pipeline Component, trying to figure out why the hell I was getting some really random issues while trying to debug my component. There's also a blog post there, but I wanted to share this first.

I came across an article (and, stupid me, didn't bookmark it at the time) that showed you how to load specific debug symbols during debugging. If you weren't aware of it, this is called the "Modules" window in Visual Studio, and seems to be in all of the versions from 2010 to 2015. To get to it, start debugging your application, and hit a breakpoint somewhere, just so you get it to break. If you then go to the Debug Menu, and select Windows -> Modules, you'll get a shiny little view which shows all the DLLs currently in scope! It also lists the path the specific DLL, so where it's actually being referenced from, and similar columns for the symbols files. How did I not know about this sooner!?

Modules Window

From here, you can right click on the offending DLL that isn't loading the symbols you expect, and actually navigate to a PDB file, and attempt to load them from there. An interesting thing to note is, that if you get an error about a mismatch between the files, it means the PDB file is out of sync with the DLL you're currently debugging (or, obviously, it's the incorrect PDB file for the DLL!). In my case, this was because the DLL was being loaded from the GAC (ugh, thanks BizTalk), rather than the local DLL in my bin folder.

Another interesting thing I discovered during this little adventure, was if you right click on a DLL, and click "Symbol Load Information", it will show a screen that shows all the possible places it's trying to look for the PDB files!

Symbol Information

So if you really wanted to, you could dump a whole bunch of PDB files in some specific system folders, and debugging should just work™.

Have a good night, and hope it helped (or at least reinforce what you already knew!) :)