views:

6983

answers:

5

Hi- I'm getting the error in the subject line. I'm running vs2k8 on server 2k3sp2. I've tried deleting the pdbs, cache directories, verifying that debugging is set up on the specific page. The interesting thing is other pages debug just fine. Just when I go to this one page. Must be a configuration issue but the page directive looks like this:

print("<%@ Page Language='C#' AutoEventWireup='true' CodeBehind='MemberSearch.aspx.cs' Inherits='SurencyPortal.EmployerPortal.MemberSearch' Debug='true' %>");

I've also noticed that when debugging, if I open the modules window, almost all of the symbols show a status of 'Symbol not loaded'. However, after more research from the msdn article below, one of the MSFT posts said that if it's a core .net dll, it will not load symbols so I'm not worried about that. Some of the microsoft modules (like System.Enterpricesservices.wrapper.dll) show an exclamation point with the message 'the module did not load at the default load address'. Not sure why that dll is there as I don't know of any calls to it.

Here are the thing's i've tried:

http://stackoverflow.com/questions/163133/breakpoint-not-hooked-up-when-debugging-in-vsnet-2005

http://social.msdn.microsoft.com/Forums/en-US/vbide/thread/557fdedb-268e-48a8-9944-29b2b4e0dec2/#page:3

Bill

+1  A: 

I usually see this error pop up when I am working with two separate web 'sites'. I have a web front end and a web service back end. If the development server isn't running for the 'site' the code file is for, then you will receive that error message.

This may not be your problem exactly, however this is usually the situation when I see that error message. Another thing you can do is Debug -> Attach to Process if the debugger isn't attached to the correct process.

Redbeard 0x0A
About attaching to the process, when I try to attach to process, w3wp.exe is grayed out. The only ones left are ones that look unrelated (ccapp, ctfmon, smax4pnp and smcgui). So, does that confirm the debugger is attached to the right process?
asp316
Usually when it is greyed out, it has a debugger attached already. I cannot help much more since I am still on VS 2005 and .NET 2.0...
Redbeard 0x0A
Make sure that under "Attach to" it says "Managed code"
Richard Szalay
A: 

usually this happens when the pdb files that vs is using for debugging are different than what the code is actually executing. ie if you have made changes to your assembly. also, make sure that you have in the web.config. i don't know if it has any bearing on the page directive, but that's usually what does it for me :)

Darren Kopp
The web config has a <compilation debug="true"> property set. What does VS use for debugging? I've deleted files from the vs temp cache folder and have removed the pdb file. One note, the pdb file is not recreated in the bin folder when I recompile. Shouldn't it be regenerated?
asp316
usually the website is fine, it's when you are debugging an assembly that is referenced that i see this issue. As long as debug is set to true, it should be generating all the debug symbols it needs, but i don't think they go in the bin, i think they go into the temp files
Darren Kopp
A: 

I agree that I have seen this when I have multiple assemblies that are out of sync and/or one or more pdbs do not match the source. In my case, it was because I had a weirdness with my version control software (ClearCase) and I was not actually compiling what I thought I was.

Andrew Cowenhoven
A: 

Place an inline break statement to be sure you are actually running the code. If you do not stop then it is likely the code you are attempting to debug is just not being run, or you are not debugging it with a managed debugger.

If you do stop but cannot find source, then you likely do not have a pdb for the module. Check the top of the callstack window to see which assembly contains the method you stopped in. That is the assembly for which you need a pdb. The module window will show the location on disk of that assembly. The command line tool "dumpbin -headers assembly.dll" will dump the PE headers. Check the Debug Directory to see where the pdb was placed when the assembly was built. If the Debug Directory does not exist then the assembly was built without debug information. If that is the case your problem is then to determine why that specific assembly was built without debug info. If it did have debug information and a pdb exists, but is not being loaded then it means either the pdb wasn't found by the debugger and you should look at the tools\options\debug\symbol settings. Or the pdb and assembly do not match. If the timestamps are not within 1 sec then they certainly don't match.

If the above doesn't help please update with more information.

Steve Steiner
A: 

The only time I've ever run into an issue like this is if I was trying to debug while the project was in release mode.

blue_fenix