views:

372

answers:

3

Hi,

I am trying to debug some code in my ASP.NET web app.

I set a breakpoint in one of the page events of the page's codebehind, and this once came up with a special icon in place of the red breakpoint saying symbols have not been loaded and the breakpoint will not be hit.

This error has not repeated itself but why can't I hit the breakpoint?

Also, when I press stop, I get a popup in VS stating:

Stop Debugging In Progres...

Debugging is being stopped but is not yet complete. You can force debugging to stop completely, but any processes attached may terminate.

This window will automatically close when debugging has completely stopped.

Completely stop


I also don't get the website appear in my browser either when starting to debug. :(

To make things worse, I have a line of code like this in my page's codebehind:

            RssFeedSites = opml.Parse(filestream);

I am putting the problematic breakpoint on this line. But I have a programatic breakpoint in the Parse() method of opml, but this does not get hit, either.

Thanks

A: 

the debugging host could not find the correct pdb's to match your executable or the debugging host is failing.

Check your build, are your PDB's all up to date and in the correct directory to be found ? Check the debugging host process if its having problem. If your using visual studio hosting process, then has the vshost.exe process somehow terminated prematurely ? If your remote debugging, check the remote debugger. Check your web server as well. If the debugging host process fails to respond, visual studio will be stuck when trying to debug.

Andrew Keith
A: 

I don't recall the specific reason for the message when I have seen it, but I always ignore it, because the symbols get loaded when the page is executed and it always hits the breakpoint assuming it's in the process flow of the page.

If you can't hit ANY debug points and you are running from local IIS, you will need to attach to the working process(w3wp.exe). Tools->Attach to Process.

jaywon
A: 

Could you check if the dll is perhaps in the GAC? If it is it is probably an older version and the GAC has priority over local dll's. So if the dll is in the GAC visual studio is using that (older) version instead of the newly built one.

Colin