Thursday, July 23, 2009

The breakpoint will not currently be hit. No symbols have been loaded ... CHECK YOUR PROCESSES!

Ok its been a while since i posted on this blog but i'm going to try and start doing better. It doesn't help that the web filter at my new job blocks the blogger.com site. By the time i get home my thoughts seem to dissipate as i take care of my 18 month old till bedtime. Anyway...

So today i got the infamous "The breakpoint will not currently be hit." message in my project. To be specific, the project I'm working on is an n-tier enterprise app containing some C# interop user controls that are gradually replacing the functionality in an older VB6 application. Basically when debugging i would run the VB6 application, attach the the VB6.exe process from visual studio 2008, and break in the user control as needed.

Well, two days ago i started getting the "No Symbols" error. I tried all the solutions that you will find when googling the problem: deleting bin directories, rebuilding the project, playing with configuration properties etc etc. Basically crossing my fingers and praying it would go away. But it didnt.

Research led me to discover the "Modules" window, which is available from the debug menu when debugging. This is where it gets interesting. The modules window, as you will find discussed in many blog posts and forums, shows if the debug symbols have been successfully loaded for your assemblies. It also allows you to load symbols manually and see what location items are being loaded from. The problem is, the dlls i was trying to break in weren't even in the modules window. How do i get them there??

What i came to realize (and this may be apparent to veteran programmers, but it wasn't to me) is that the Modules window shows all of the assemblies that are loaded into the processes that visual studio is attached to. I needed to see exactly what assemblies were loaded as i was running my project, so i downloaded the Process Explorer app from Technet (link below). This handy tool lets you select a running process and view all of the assemblies in that process. Sure enough i booted up VB6, ran the tool, and my project assemblies weren't there!

This is when the light came on in my dense skull. How could the VB6 run my interop controls if it hadn't loaded the assemblies?? It couldn't. Once i clicked on the form containing the controls, my project dlls showed up in the process explorer window. It wasn't loading the assemblies until they were needed. Once the process had the right dlls loaded, i could attach to VB6 from visual studio and set the breakpoints. (Important to note, if you have this similar issue you must detach and reattach the debugger for it grab the just loaded dlls.) Furthermore, once the assemblies are loaded the first time you can start and re-start the VB6 project and they will remail loaded.

You may notice a similar issue if you are running a web or WCF service locally while debugging. When i started working on the project i could set a break anywhere, but once i started having this issue, i had to manually go in and attach to the WCF service to set breaks in the bottom tiers. I've yet to figure out exactly what changed that started the whole "No Symbols" problem, and i probably won't pursue it at this point...i'm just happy to be able to finish my work.



http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

No comments: