The breakpoint will not currently be hit. No symbols have been loaded for this document


  • I have now wasted 8+ hours trying tot fix this problem.  I have read many of the dozens of threads already related to this issue and I have not solved the problem.

    • VS 2005
    • .NET 2.0
    • Windows Server 2003
    • Project is on my local machine, database is on a remote server within network
    • This is not a web service or a hand-help application, it's just a plain old data-base driven website.
    What I know:
    • I am in debug mode
    • I have deleted all files in the Temporary ASP.NET folder multiple times
    • The problem is not related to the machine.config file
    • I am quit certain it is NOT an IIS problem (keep reading)
    • I have un-installed the 2.0 framework and VS 2005 and re-installed both
    • I have done EVERYTHING that other people have suggested.  NOTHING has worked.
    The problem seems to be related to the fact that when I compile, all of the .pdb files are not being created.  Looking that the "Output" window after entering debug mode, there are all kinds of lines that look like this:

    'WebDev.WebServer.EXE' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Xml\\System.Xml.dll', No symbols loaded.

    When looking in the TEMPORARY ASP.NET directory, there are SOME .pdb files, and all of these load correctly when trying to debug.  Not suprisingly, however, in each case where the output window says "No symbols loaded" there is no .pdb file.

    I just can NOT spend any more time on this.  For the love of God, can someone help?  All I want to do is hit break points when I de-bug.  Is that so wrong?

    Tuesday, April 24, 2007 9:26 PM


  • Hi,


    Maybe you have checked this already but although you may be running in debug mode you may still be compiling your code in release. Check through your configuration manager that all the projects are configured to be compiled for debug. Thats all I can think of, hope you get it sorted because no debug would be the biggest pain in the neck.

    Wednesday, April 25, 2007 9:33 AM

All replies

  • Hi,


    Maybe you have checked this already but although you may be running in debug mode you may still be compiling your code in release. Check through your configuration manager that all the projects are configured to be compiled for debug. Thats all I can think of, hope you get it sorted because no debug would be the biggest pain in the neck.

    Wednesday, April 25, 2007 9:33 AM
  • Yes, that was one of the first things I checked.  Thanks, however.
    Wednesday, April 25, 2007 12:57 PM
  • I was having the same problem.  I went to Project Properties, selected the Compile tab, clicked Advanced Compile Options and changed Generate Debug Info from None to .pdb-only.  This solved the problem for me.

    Monday, May 14, 2007 7:36 PM
  • Where in the heck is the "Compile Tab"?? There are not tabs in VS 2005, there is a tree control only.
    Thursday, July 12, 2007 3:39 PM
  • Hi,


    I dont normally have time to answer questions about problems but as this one is so annaoying and I managed to resolve it for myself more or less by coincidence I thought I should showyou what I discovered...


    I saw the despair in all sites with this question and decided I did not have the time to sort the problem so I carried on without debugging which meant I had to really think why my sall change did not work...


    I had recently created this page very quickly as the copy of another page. Whilst copying the aspx and cs files I forgot to modify the class name in the cs and also forgot the page directive in the aspx. It was inheriting the cs file that I had copied and using the wrong codefile! As soon as I changed these properties to the correct values and restarted my app it stopped on the debug breakpoint!


    Hope it helps - at least it indicates that we can be at fault (in the coding) and not just the VS software.


    Good Luck!



    Friday, July 13, 2007 7:09 PM
  • A naive answer andguess on this question is that the just in time parser and compiler is not there jet the first time and so the break point is not recognized until you reach that form in the execution. I notice that message in my code as well  but while  running the applicaiton  and as soon the web page is needed then the break point becomes functional. So this naive anwer suggest to not worry about it  because it will be enable once the code is generated on demand.




    Friday, July 27, 2007 8:09 PM
  • Lucho ... you just saved me a couple hours of hairpulling there.  Good advice.  Worked for me Smile

    Monday, August 13, 2007 11:09 AM
  • Hi


    I have the same problem in remote debugging with an application written in C#. I use VisualStudio 2005.

    The exe file is compiled in debug, with all proper debug info. I can even debug it locally.


    So here is my walkthrough:


    - I copy the bin\debug folder on the remote host

    - I am administrator on the remote host

    - I start msvsmon with "/noauth /anyuser" options

    - I do "Tools->Attach to Process..."

    - I set Transport to "Remote (Native only with no authentication)

    - I set Qualifier to my remote host

    - Attach

    - I am connected (my loggin is traced in msvsmon)


    But all my breakpoints are disabled. Does anyone knows how it works ?

    Thanks a lot

    Tuesday, September 11, 2007 6:03 PM

    NicolasMeyer - i have the same problem as you but with sharepoint remote debuggin, anyone figure out how to solve it????
    Thursday, January 10, 2008 6:53 PM

    Same problem here!! None of us can get any breakpoints to fire at all .... help!


    Running remote debugger on a server, installed it giving a local account with 'log on as service' set.

    We've connected from our local machines using 'connect to process' but none of our breakpoints ever get hit, and appear as unshaded red circles in our code .... any ideas what we might be doing wrong?



    Monday, January 14, 2008 4:04 PM

    What i did was, remove the dlls from the GAC on the remote computer and copy the dlls and pdb file from the bin directory on the development computer to the c:\inetpub\www\virtual....\port num\bin folder on the remote and add a safe control entry to the webconfig.


    hope this helps,

    Monday, January 14, 2008 6:40 PM
  • Perhaps this will save someone 3 hours:

    Identify a Windows account that is available on both the debugger and debugee machine.

    * On the remote server (the debugee)
    o Ensure the Windows account identified above is a member of the Administrators group
    o Ensure the Windows account identified above is a member of the Debugger Users group
    o If necessary, edit the application’s web.config file:
    * /configuration/system.web/compilation@debug=”true”
    * (Symbols are loaded from the debugee)
    o Start msvsmon.exe under the account identified above
    o Configure msvsmon.exe (Tools/Options) to run with Windows Authentication
    * Click the Permissions button and ensure the account specified above has the appropriate permissions
    * On the local machine (the debugger)
    o From the VS2K5 main menu – Debug/Attache to Process
    * Transport:  Default
    * Qualifier:  domain\user@debugee_machine
    * Attach to w3wp.exe
    o Open the source file in question
    o Add a breakpoint
    o Request a page with your browser

    Some helpful links:

    * If you’re unsure if you’re symbols match your DLL, try this tool:  (http://www.debuginfo.com/tools/chkmatch.html)
    * http://blogs.orcsweb.com/jeff/archive/2007/08/24/remote-debugging-in-vs-2005.aspx
    * http://aspnet2holes.blogspot.com/2006/11/debug-aspnet-20-running-under-iis-60.html


    • Proposed as answer by Sougandh Saturday, March 13, 2010 12:03 PM
    Tuesday, April 01, 2008 4:06 PM
  • This works for me. It can be a debug symbol version mismatch so that debug symbols don't load. At VS2005 VB start the debugger (F5). Click debug -> windows -> modules. In the window that opens right click on the module of interest and then 'symbol load information'. Use 'symbol settings' to find the correct symbol (.pdb) file (which has matching date and time to the module). This path you find manually will be remembered subsequently because the debugger searches a number of paths looking for valid symbols. If you can't find correct symbols then you may need to update your SDK to get them, perhaps because windows update has changed your executables alone, or you may need to do a debug build that generates a pdb file. 

    Wednesday, April 02, 2008 5:49 PM
  • I faced a similiar problem where the debugger was not hitting a breakpoint at all, for this I googled at many places and most of the solutions provided more or less were misleading, until I finally figured out myself where I was going wrong.  And it came to my notice that, I was running the VS 2005 development environment over MS Windows Vista without Admin privilages.  Solution to the problem was pointing to [Microsoft Visual Studio 2005] within programs folder and again pointing to [Microsoft Visual Studio 2005] application then right clicking and selecting [Run As Administrator] option from the context menu.  And when I did this, without any problem the issue was sorted.

    So the issue was pertaining to permissions of the account under which the VS 2005 IDE was being run.

    Saturday, March 13, 2010 12:15 PM
  • My Visual Studio 2008 started giving this error all of a sudden. I tried most things mentioned in forums but it did not work for me. Finally I tried the instructions mentioned here: http://techemployee.blogspot.com/2010/03/visual-studio-2008-breakpoint-will-not.html and it worked! I am so relieved I finally got rid of this annoying problem.

    I am hoping this will be helpful to others.

    Wednesday, March 31, 2010 5:00 AM
  • old,

    I'd already tried and checked the other items except for:
    * /configuration/system.web/compilation@debug=”true

    This was key.  Without this flag on, the debugger will not load the symbols.


    Tuesday, May 11, 2010 12:29 AM
  • I have the same breakpoint problem. can anyone help me solve it. do i have to enable something.

    VS2010- 64 bit.

    Monday, July 05, 2010 5:35 PM
  • Struggeled with this for hours !

    My simple sollution was:

    "Identify a Windows account that is available on both the debugger and debugee machine."


    I just created a new user on the client machine with same credentials as the machine running VS2010.

    Then i chose windows authentication, then it worked.

    So problem seemed to be that i was using no authentication (native only), i guess "native only" should have been a hint.....

    Monday, October 18, 2010 2:05 PM
  • Make sure that you're using the correct version of msvsmon.exe!!!


    That's all it was! i had the same problem while remote debugging a C# application. I was using x64 msvsmon.exe because the server runs Windows Server 2008 64-bit, but the application was written for x86, so I had to run the x86 version of msvsmon.exe in order to get rid of this annoying error.


    Nothing else was needed. Just run the version of msvsmon.exe that corresponds to the target architecture of your application ^_^

    Friday, March 25, 2011 6:54 PM
  • I had a similar error but was trying to debug a Windows Forms appliication, not an aspx website.  The solution to my problem was different from those for the websites so I thought I would share it.


    • Local Machine x64 Windows 7 running Visual Studio 2005 with administrator privileges
    • Remote machine Windows Server 2003 R2 Standard Edition (x86)
    • Application to debug on remote machine .NET 2.0 Windows Forms app, compiled in debug mode, installed via MSI file created via a Setup project in Visual Studio

    I tried rebuilding the project in Visual Studio, and rebuilding the Setup project to create a new MSI.  On the remote machine I removed the application using Add or Remove Programs then reinstalled it via the new MSI file.  Still had the same problem.

    The fix was to copy the contents of the bin\debug folder from the Visual Studio project on my local machine to the remote machine, rather than install the files via the MSI.  Running the copied files, as opposed to the files created via the MSI, the breakpoints I'd added to the project on my local machine were suddenly being hit.

    I noticed the version of the application installed via the MSI did not have any pdb files, even though it was compiled in debug mode and the Setup project was configured to take the Active output of the application project, not just the Release output.  I tried copying the pdb files across from the version of the application which I had manually installed.  Still couldn't hit the breakpoints when attached to the version of the application installed via the MSI. 

    Haven't time to investigate further so at this stage it appears installing a Windows Forms app via MSI will prevent breakpoints from being hit during remote debugging, whereas installing the app via manually copying the files will allow the breakpoints to be hit.

    Thursday, April 28, 2011 11:52 PM
  • Lucho's advice was correct for my situation.  I'm using VS 2010 with an MVC Razor web application.  I put a breakpoint in a view.

    When I first launch the application, the breakpoint bullet is disabled and shows "The breakpoint will not currently be hit. No symbols have been loaded for this document."  That message continues to be displayed until I navigate to the view where the breakpoint exists.

    Once I've navigated to that page in the browser, the breakpoint is enabled (it turns red) and works properly when conditions that trigger that breakpoint occur.

    Tuesday, August 21, 2012 12:45 PM