Breakpoint will not currently be hit. No symbols loaded for this document. RRS feed

  • General discussion

  • I have been 'developing' with Visual Studio 2005 for about 3 weeks now - primarily .NET class libraries developed with VB. I am coming from VB6, although I did a lot of development with Visual C++ several years ago, so I am still trying to come to terms with the debugger.

    I have read many threads posted by people who are having a problem with breakpoints, specifically with the message in the subject line above. There have been many suggestions on how to fix this problem. Sometimes these suggestions work, sometimes they do not. Most of the suggestions involve deleting DLL and PDB files and rebuilding, or restarting Visual Studio. None of them suggest any problem with something the developer has done or any problem with the configuration of the development machine.

    To me, the inability to reproduce the behaviour at will, and the fact that the'work arounds' work some of the time but not all, indicates to me that this is a bug. People have denied it but to my mind the evidence is there.

    For example, just now I have had this problem. I deleted all files from the Debug directory, rebuilt the project, rebuilt the TLB and re-installed in the GAC. No good, the breakpoint still shows the 'will not be hit' message. Totally frustrated, I decided to try running the client anyway, which I did. Naturally it did not stop at the breakpoint. I shut down the debugger, started it again (attaching to a process) and lo and behold, the breakpoint is now working. So what did I do to make it start working? If starting and stopping the debugger fixes the problem, how can it be anything I have done wrong or failed to do?

    This problem is very frustrating and it has made my current development task take much longer than expected. Something as simple as step through debugging should be a given in a development tool like this, as it is in VB6.

    What I would very much like is for someone who knows to explain what I am doing wrong, if such is the case, or explain how this is not a bug. If it is a bug, then I would like to hear from someone at MS regarding whether or not it is being looked at, and if so, when we can expect a service pack. This issue is costing people time and money and I know I'm not the only one experiencing this problem. Alternatively, if someone can tell me that I am doing something wrong, tell me what I should be doing, and I can move on to what I am supposed to be doing, I would be very grateful .
    Friday, July 14, 2006 1:26 AM

All replies

  • This might be a case of your class library being gac'd, then a rebuild occurs. The application will load the old gac'd assembly which the debugger will see as not matching your local PDB file.

    The solution is to ungac your old assembly (gacutil -u <assembly name>) and then regac your newly built assembly. You'd have to do this after every build.

    Another solution is not gac your assemblies while debugging, although that might not be possible based on how your application is loading them.

    Friday, July 14, 2006 8:08 PM
  • Sorry, I thought of some more info.

    Using the modules window you can also check to see what version of your dll is loaded into your application.

    If the version showing up in the modules window doesn't match the PDB that would explain why it can't load.

    The version number you want to see in the modules window should match the DLL you just built. You should be able to check the DLL just built using windows explorer. 

    I'm going to add a suggestion for VisualStudio that we do a better job of pointing out why a PDB doesn't load. I know the GAC problem (if that's what your issue is) is a very common problem. 


    Friday, July 14, 2006 10:49 PM
  • Thanks for the reply. I have been re-installing the dll in the GAC after each compile and that seems to deal with the issue partly. I'm calling from VB6 and I've found that if I attach to the VB6.exe process, make a call from the VB client code, stop the .NET debugger, reattach to the VB6.exe process, then my breakpoints work. I don't understand how or why that works but it does seem to be repeatable.

    I guess where I am coming from is that the whole debugging process is now way more complicated than it was under VB6. For me, this is a fairly serious time waster. However, I'm prepared to try and understand it better and maybe I can get on with it.

    Thanks for the tips, I'll try them out.
    Sunday, July 16, 2006 11:31 PM
  • I am developing a Addin in VB.NET using VS 2005 IDE.

    I have started getting the same problem "Breakpoint will not currently be hit. No symbols loaded for this document." since yesterday.

    Till this point in time, nothing seems to help me.

    Has there been any latest updates on this from MS?

    Wednesday, August 2, 2006 4:38 AM
  • Deleting files in the c:\windows\microsoft.net\framework\v2…\Temporary ASP.NET File\ProjectName\...\...


    Worked for me.

    Thursday, August 3, 2006 5:37 PM
  • I've been fighting this issue all day. I have a VB.Net 2005 solution that contains a DLL and an EXE (a test harness for the DLL). Based on other suggestions I've seen, here are the steps I've taken to resolve, none of which have solved my issue:

    -Solution Properties --> Config Manager --> Active Solution Configuration set to Debug
    -Check that the timestamp on pdb and dll file are in sync
    -Delete the entire shadow copy cache at c:\documents and settings\<user name>\local settings\application data\assembly.
    -delete bin and obj folders, restarted, and tried again
    -remove the strong name signing
    -Delete all instances of *.pdb files in project directories
    -Uninstall assembly from GAC
    -If you have project files that are in different directories but share the same name, give them different names.
    -Ensure that DLL's and PDB's are not under source control.

    I can't believe how much time I've wasted on this. ALL I WANT TO DO IS HIT A BREAKPOINT!

    Sunday, August 6, 2006 7:05 PM
  • I've got the same problem using VC2005, either strange. Output message:

    'project.exe': Loaded 'Z:\M', No symbols loaded.

    I do not know why the Path is called "M" (this is only the first character of the full pathname). Ok, I will ignore that, "Z:" is a VMWare network drive (\\.host\Shared Folders\My Projects) and I could not get the program debugged. But storing/compiling the project from the local drive or a "real" network drive, the debugger is working. Reason could be that tha path \\.host\Shared Folders\ is not accessable, but the subfolders are. The debugger may have a problem with this, the executable and all other programs run this way...

    Monday, August 7, 2006 11:15 AM

    Hi Guys

    Is there an update on this subject I have an 8 project solution (of which one is a web service) that used to let me debug any of the applications, just by setting a breakpoint. Now all I can set is breakpoints in the main application and the business logic level, any break points set in the dataaccess layer (which is called via the web service) is not available (ie breakpoints will not be hit), this is so frustrating. I have cleared out all pdb files and rebulit all assemblies (none of which are installed into the gac), refreshed all pdb files in IIS and I'm still not able to get a break point to work. There must be a procedure for setting this and loading the pdb files, just not sure what else I need to do, can someone please help.

    Thanks in advance


    Tuesday, August 8, 2006 3:30 PM
  • I wish. I'm still dealing with this.  All this expensive software and I'm reduced to debugging via message boxes!  



    Tuesday, August 8, 2006 4:09 PM
  • I found a solution for this in VS2005 that worked for me (seems to be the case with most solutions for this) so here goes.

    Bring up the project properties window then go to the 'Compile' tab. Under the Advanced Compilation Options screen select 'Full' in the 'Generate debug info' combo.

    I had exactly the problem that is listed here and this solved it instantly. If it doesn't work then try clearing out the files in your 'debug' directory and you compilation directory and try again.

    This solution obviously doesn't work for ASP.NET pages but I'm working on a solution for that and will post when I come up with one.

    Good luck!!!

    Tuesday, October 31, 2006 1:54 PM
  • Anyone found a full solution for this yet?

    I am in VS2005 using VB.  I have hit this problem out of the blue on code that I used to be able to debug as I wished.   I found the 'FULL' option in the 'Generate Debug Info', but even that no longer helps.

    I have no wish to become a guru on the internals of VS .pdb .gac ., nor do I wish to manually edit or delete 72.435% of my BIN directory after every compilation run.

    Will SOMEONE at MICROSOFT PLEASE improve the CLEAN code to fix this rubbish, or fix it once and for all at source.

    yours dejectedly


    Monday, November 13, 2006 9:00 PM
  • Guys

    Just to update on my issue, the reason I couldn't get the asp web service to debug was that IIS had reverted back to .Net framework 2.0 instead of 1.1 and as soon as I changed it back I was able to debug again, not sure why it changed but not the first place I would have thought to look at.

    I agree with Martin and this should be more user friendly if nothing else, at least give an indication as to why the break point won't be hit and what needs to be done to correct it, afterall if VS knows that the break point can't be hit then there must be a condition it's checking for to come to that decision. 



    Tuesday, November 14, 2006 8:30 AM
  • Actually, we are doing our best to indicate the issue of why the debugger is not breaking.  To set a breakpoint in the running code, the debugger looks at all of the symbolic information it has loaded for every module and tries to find a match for your file and line number in that set.  When it can't find any, that's the best it can do.  So that's the condition.  We are taking a look to see if we can improve the issue of incorrect framework selected, but it is difficult for us to understand user intentions sometimes (i.e. did you actually mean for the framework to be 2.0 rather than 1.1.).  We could prompt a lot, but that may get distracting.

    We feel your pain and are trying to figure out ways to mitigate it,


    Tuesday, November 14, 2006 5:43 PM
  • Hi John

    That would explain why there is no information on why it can't hit the breakpoint, I was not fully aware of how VS worked out how to hit a break point or not.

    I can understand your pain and I'm sure you'll find away to overcome this eventually, but it can be rather frustrating especially when a project did break on a break point and then (what seems to be) for no apparent reason not hit the break point, in my case the project was a 1.1 framework windows app with a webservice not quite sure why IIS changed over to version 2.0, unless another application had changed it, would it not be possible (at least) where IIS is concerned to check the application for the version of the framework, and set the IIS application to default to the correct framework based on the application, I know that that is a very simplistic view of it and I'm sure it wouldn't be that easy.

    Well I hope you guys can find a solution to this age old issue, I for one would not be too put off having a dialog box pop up when then was an issue as long as it explained the fault and gave an indication as to how best correct it or at least a link to a webpage that provided more information.



    Wednesday, November 15, 2006 8:34 AM
  • Thanks John,  It's good to know someone is looking at it but I see from other posts (somewhere) that it has been going on for sometime and several versions.

    If sending you my ropey old code and solution stuff will help, then let me know.

    Only part of my code has this problem, and it emerged out of the blue.  It is on a form that has a (well constructed) third party object on it.  Since the problem happened I have tried reloading and jiggling stuff about, but have only succeeded in persuading the solution to start including VBrun in the bin directory (for no good reason I can fathom).

    As I say, I did get it to work briefly using the option setting I mentioned.




    Wednesday, November 15, 2006 10:34 PM
  • For cracking this issue asp.net, do the following steps

    1) stop www services

    2) delete all the cache from C:\windows\microsoft.net\framework\v2.0.50727\Temporary ASP.NET Files

    3) delete all the PDB and Dll file which in bin & obj directory of asp.net project

    4) start the service and compile the project.

    It will work.



    Suresh M



    Thursday, November 23, 2006 12:27 PM
  • If you get this error doing ASP.NET 2.0 development then this could be one of the reasons:
    When you "publish" your web site it will be pre-compiled with aspnet_compiler but without the -d switch therefore there are no symbol files. Either manually pre-compile or point the web site to your ASP.NET project directory.
    Monday, November 27, 2006 4:43 PM
  • After doing development all day with no problems hitting breakpoints in my webservice, I now cannot.  I have only been changing class information in the webservice.

    VS 2005, Windows XP using SQL 2005 Express.

    I have a webservice and an exe that calls the webservice in my solution.  I have cleared out all the files in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files.  I have my WWW service stopped and the default website stopped.  However the webservice still runs just fine which I find interesting. 

    I made the mistake of "publish"ing the site.  I deleted the directory where it was precompiled.

    I am not sure what is put in the GAC for a webservice so I don't know what to look for.  Nothing for the build of the webservice shows up that tells me of any dlls.  In fact I am not sure how the heck it is even running at this point.


    Yes, I have the configuration set to "debug".  In the web.config, <compilation debug="True">.

    Update:  I set a breakpoint in the exe where the webservice is called, then hit f11 to step into the call, I reached the webservice code and can step through it.  I hit Continue and the breakpoint now gets hit.

    Tuesday, November 28, 2006 11:17 PM

    Funnily enough, all my troubles started about the time I did my first 'publish'.

    Microsoft folk - Any chance the 'clean' code you could have an option to remove the publish related stuff?

    (An issue I previously resolved has also re-appeared - the one where I can no long "debug, edit and continue in vb" - but I will go back to that thread now I have mentioned it.)



    Wednesday, November 29, 2006 8:03 PM
  • I don't know if this helps pinpoint the problem, but when I set my breakpoint in my exe project that calls my webservice project and then F11 from that point, I get "Auto-attach to process '[1872] WebDev.WebServer.EXE" plus all loading of the dll's in the Output window that then allows me to hit the breakpoints in the webservice.

    Thursday, November 30, 2006 12:46 AM
  • Yes it is SO FRUSTRATING! I have spent at least 3 hours of my time just to break the stupid code into the debugger - code that was gold five minutes ago. I am one step away from production and viola! here we go again. Here's what I have done to rectify the situation:

    1. Made sure that the build mode is set to debug.

    2. cleaned up the .pdb files under the Temporaray asp.net files folder under windows.

    3. deleted the bin in the publish directory.

    4. uninstalled and installed aspnet_regiis.

    5. Restarted iis on my machine.

    I don;t know what i am missing here. This should really be a trivial issue. BTW, my app is a asp.net web site (no ajax). Any help is mucho appreciated with mucho gracias.

    Tuesday, January 16, 2007 8:10 PM
  • Nope that does not work. Thats what I have been doing today after the prob occured the first time. Btw all my target files are under the local dir of the application, so no gac issue here unless I am missing something. Thanks for the attempt though.



    Tuesday, January 16, 2007 10:50 PM
  • Well guys - I seem to have "solved" the problem. In the startup options of my project I had a start URL and when I ran the debugger yesterday it choked and could not load the symbols. I understand that when you run a project (debug) from within vs windows creates a seperate process and loads the default instance of IIS at specfic port and when you execute your solution outside the vs environment it runs under the IIS process as a seperate thread.

    However, the same appplication has been working for the last one week with the start url hard coded in the startup options of the project and vs yesterday decided to give me hell completely out of the blue - it completely baffles me how this could happen - unless vs lost the program database associations at runtime and could not resolve loading the correct pdb information.

    I deleted the bin folder, deleted the cache, reset iis, uninstalled aspnet_regiis and re-installed it and nothing worked. In the end, I removed the startup url and viola! the code broke into the debugger.

    Maybe someone @microsoft can shed some light on this. It would be nice to know. In the meantime, I hope this helps anyone who is facing the same prob.





    Wednesday, January 17, 2007 4:37 PM
  • Hi,

    For the folks who have the scenario where you are calling into a webservice (like Actsparky) you need to step into the service in order to hit breakpoints in that service. The debugger doesn't break in processes that it is not attached to. When you do a StepIn at a call into the service, the debugger will attach to the process behind the scenes.

    For folks having issues with breakpoints make sure that you are deploying pdbs along with the DLLs. Check the modules window. It will tell if symbols are loaded or not. Pick the module of interest and using context menu select Symbol Load Information and this will show you the locations it has searched for pdbs and if it found any why it didn't load them. Note that pdbs need to match exactly with the binary. You can specify locations to search for PDBs using Symbol Settings... in context menu or going to Tools->options->Debugging->Symbols.

    When you are building the assemblies make sure that Debug Info is being generated and optimizations have been disabled.

    Hope that helps

    Azeem Khan

    VS Debugger.

    Wednesday, January 17, 2007 9:49 PM
  • The "modules" window lists all the modules that were loaded, and whether symbols were loaded. Right-clicking on a module shows a menu with "Symbol Load Information". Clicking that shows something along the lines:

    <file_path>.pdb: Unknown symbol handler error.

    lots of times. Googling for that suggests that this is a very rare problem. Manually loading the symbols doesn't work; I get "The symbol file X does not match the module." This is after a full clean rebuild, having deleted every single .pdb I could find on my PC.

    Just noticed that "Version" for the dll is displayed as, instead of the "" specified in the version resource. Could that be causing the unknown error?
    Tuesday, January 30, 2007 5:18 PM
  • Thanks for the additional info Azeem.

    Using the modules window I have identified about 17 DLLs that the system can't find PDBs for including:


    The Load information for MSCORLIB.DLL is:

    C:\WINNT\assembly\GAC_32\mscorlib\\mscorlib.pdb: Cannot find or open the PDB file.
    C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\mscorlib.pdb: Cannot find or open the PDB file.
    C:\WINNT\symbols\dll\mscorlib.pdb: Cannot find or open the PDB file.
    C:\WINNT\dll\mscorlib.pdb: Cannot find or open the PDB file.
    C:\WINNT\mscorlib.pdb: Cannot find or open the PDB file.

    The interesting thing is that when I search for mscorlib.pdb on my workstation it isn't anywhere to be found so there is no way to point to it.

    Have I omitted something during the install of VS 2005?  Where can I get the missing PDBs from?

    Thanks for any information

    Monday, February 5, 2007 8:32 PM
  • Hi

    I doubt very much that you would find PDB's for those dll, these are Microsoft DLL's, and would not be released with debug information.



    Tuesday, February 6, 2007 1:17 PM
  • I'm having the same problem with an ASP.NET 2 project.  Everything was going fine until the other day when I got a bit impatient and set a break point while the project was building.  Now my breakpoints no longer work if the aspx.cs is in a directory under the website's root directory.  All the aspx.cs files that are in the root directory of the project's website are still able to debug with breakpoints.  I am also still able to set breakpoints in any code that goes into the DLLs used by the website.

    I have cleared all the Temporary ASP.NET Files folder, and removed all instances of any .dll and .pdb files in all of the projects associated with the website project, and in the website project itself.  Even after doing a Rebuild ALL, I still cannot set a break point in any of the aspx.cs file that are in a subdirectory under the website's root directory.

    Douglas McLaughlin
    Verizon Business

    Friday, February 9, 2007 12:18 AM
  • How do you get to the Modules window?
    Friday, February 9, 2007 12:30 AM
  • John,

    Do you really feel our pain?  Do you really know what it is like to have Morgan Stanley holding funding of a major multi-million dollar project because we can't demostrate a web site (because of this issue) to them to ensure that they're making the right decision if funding the development project??  Do you really know what that is like?  I doubt it!

    Anyway, back to the point -- this same issue in my case had NOTHING to do with setting IIS framework version -- that was one of the first things I validated and in my case .NET 2.0 was set.

    What ultimately resolved this problem for me (and I'll admit this was a blanket solution as we don't have the time to truely debug Microsoft's very flawed VS 2005 environment since that is NOT our job):

    1.  Repair .NET 2.0 framework

    2.  Repair VS 2005

    3.  Re-install the VS 2005 SP1

    4.  Clean solution

    5.  Rebuild solution in both Debug & Release modes

    Once this was done, debugging magically worked again.  Hope this helps others running into this wall, it seems to pretty common issue and I'm sure I'll probably have to repeat this process again somewhere down the line.



    Monday, February 12, 2007 4:21 PM
  • To follow up on Azeem's reply, the debugger was breaking into the web service just fine before.  Everything is getting recompiled on my development machine so I have all the pdbs.

    Everything is running under one solution, the windows app that calls the webservice, the webservice, the dll projects that the webservice needs.

    That publish website option is evil in my opinion.

    Monday, February 12, 2007 5:21 PM
  • Before I spend 6 hours of my time with this sh...  read every this forum and many other. Yes, I lost any years of my life!!!

    I have one DLL writen in C++ (.NET 2003)  and need call in  one aplication in VB6. The debug work fine for 3 hours.

    I resolve my problem moving both project in .net 2003 AND VB6 to my disc C:

    - C:\Desenv



    I work in 11th floor, I think in Jump... Now I can go home!







    Wednesday, February 21, 2007 8:43 PM
  • Don't jump, if you really want to make Microsoft listen start using a non-Microsoft OS and use non-Microsoft development tools.

    This is really THE ONLY WAY to instigate real change and even then their arrogance may still sink the ship.  The Microsoft feedback forum is a complete joke and being a part of the "beta" team is really for people that have just way too much time on their hands.


    Wednesday, February 21, 2007 10:19 PM
  • Hi Rob,

    I'm sorry you feel we've been arrogant in any of our dealings with you - that's certainly not my or any of the folks in our team's intent.  I don't have many excuses for you.  We do our best before we ship.  We take pride in what we do, and when we fail our customers we're not happy. 

    To your final point of the feedback forums, we know we've been struggling to have an impact here, and we are trying to take steps to remedy that.  These forums are intended to be a community forum, not a replacement for product support channels.  We're also trying to encourage some of the language MVPs to participate, but most folks have affinity to languages, not tools like debuggers.  I'd appreciate any input you have in how we can foster a better community here.


    Wednesday, February 21, 2007 10:56 PM
  • John,

    Some ways to foster a better community:

    1.  Avoid terms like "why would you want to do that?"

    2.  If you find yourself repeating "by design" a lot, then you probably have a bad design

    3.  Getting "Feedback" responses 2 or 3 months after the original post is useless to me

    4.  In almost everything Microsoft, you have an "intended" way of using a particular concept/feature which is rarely explained adequately

    5.  Provide quality products so that I don't have to frequent the community and you don't have to either

    6.  Being an active part in the Beta should NOT be the ONLY way to get feedback into the evolution of final release

    7.  Please no MVP's, get the coders, the designers, not the PMs -- developers want to talk to other developers

    8.  Listen - take what you read to someone with actual decision power, someone that can "alter" the scope of the next VS dev platform, someone who is genuinely more interested in a solid product rather than meeting the performance goals so they receive XYZ % bonus.

    But ultimately, the best community is one that is visited rarely.  The existing list of problems in VS 2005 (and some caused by SP1) and missing functionality is amazing, it you compare this to other tools such as Xcode, CodeWarrior you can see just how poor of a dev tool VS 2005 really is.

    Microsoft obsess on functionality that is used by <2% of the developers but do so because the "technology" could generate an entire new revenue stream for Microsoft and the developers is really just a pawn to sell the concept to client's that think they must have it.

    As far as pride, come on, have you worked with a large VS 2005 project?  The IDE is horribly slow, the build process is VERY slow, hidden prompts/windows, a lot of very obvious problems that get in the way daily.  Web app development is scarey at best.  Major interface problems -- often I move off to do other work while VS 2005 builds everything on the planet even things that haven't changed -- I'll be working away on something else and suddenly focus moves to VS 2005, no real reason way, still building -- can't tell you how many times a mysterious focus change in VS 2005 has caused me to accidently change a drop down property or type in the code window when I thought I was working in another application all together.  But the list goes on and on and on -- I've given up on Feedback because I just don't have the time to keep filling out reports that may or may not get answer several months later (answered, not solved).

    Language is irrelevant with the exception of games development.



    Wednesday, February 21, 2007 11:56 PM
  • Please follow these steps and you will rock...

    Open IIS.
    Open properties of your virtual directory by right clicking on your virtual directory.
    Go to ASP.NET tab.
    First Select ASP.NET Version to 2.0.50727
    Then click on button Edit Configuration.
    It will open up ASP.NET configuration Settings.
    Go to Application Tab.
    Then check the Enable debugging check box.
    Click OK.
    Then change the ASP.NET version to 1.1.4322.
    Click OK.
    Exit IIS.
    Go to the mapped virtual directory
    ( e.g - My virtual directory in IIS in mapped to D:\my project\Local Cafe Prepay\CafePrepay )
    There you will see a new Web.config file.
    Open the web.config file.
    There you will see some lines given below

    xml version="1.0" encoding="utf-8"?>
    configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <compilation debug="true" />

    Edit it so that it looks like this

    <?xml version="1.0" encoding="utf-8"?>
    <compilation debug="true" />

    Save web.config file and exit.

    Repeat the last same step for the Web.config file in your bin folder.

    Then Run your application, and here you rock.

    I bet this will work for anybody and eny type of debugging problem.
    Have a nice day....

    Friday, March 2, 2007 7:59 AM
  • I've been struggling with the same problem for days and days.  I have researched and tried to find solutions and they have got me nowhere. 

    One thing I suggest that is very easy would be to right click on the Visual Studio icon and "Run as Admistrator"  this allowed me to debug and solved my headache!

    Hopefully this will work for you too.


    Friday, March 2, 2007 6:26 PM
  • Is there any news on this issue? I initially altered some of my code in my asp project so I could debug a lil easier and all was good for the few days that I was debugging one issue... Then I try to see how everything is working on another page and I see this... I've tried everything stated here plus whatever else seems logical and nothing works...

    It even says symbols loaded for EVERY dll that is loaded so how the heck are no symbols loaded for this document? Is this just one of those things that happen with a microsoft product that everyone knows about but just accepts because thats how it is?

    For now I guess I'll go back to debugging using messages in my code... exciting.
    Wednesday, March 7, 2007 11:37 PM
  • What, you don't think VS 2005 debugger is progress ;)  he he

    Have you tried any of the suggestions?  In my case it was yeah old, install/re-install everything .NET and VS related and then clean my solutions and rebuild.

    Nobody seems to know exactly how VS 2005 gets into this state -- I think it can be duplicated by running a solution (in debug mode) and setting a breakpoint on a line of code during the build process at the same time that specific module/dll that is being built.

    I'm guessing this is happening to many people (in what appears to be random fashion) who are bored waiting for VS 2005 to recompile and build everything again and know they needed to add a breakpoint, so while waiting for the endless compile process, one sets the breakpoint which then corrupts the debugging session from that point onwards.  This is just my hunch as I'm affraid (and don't have the time) to try to duplicate this -- but again, that should be Microsoft's problem not mine.  Who knows in 3-6 months we might get a meaningful response from Microsoft.


    Thursday, March 8, 2007 12:15 AM
  •  Rob Ainscough wrote:

    What, you don't think VS 2005 debugger is progress ;) he he

    Have you tried any of the suggestions? In my case it was yeah old, install/re-install everything .NET and VS related and then clean my solutions and rebuild.

    Nobody seems to know exactly how VS 2005 gets into this state -- I think it can be duplicated by running a solution (in debug mode) and setting a breakpoint on a line of code during the build process at the same time that specific module/dll that is being built.

    I'm guessing this is happening to many people (in what appears to be random fashion) who are bored waiting for VS 2005 to recompile and build everything again and know they needed to add a breakpoint, so while waiting for the endless compile process, one sets the breakpoint which then corrupts the debugging session from that point onwards. This is just my hunch as I'm affraid (and don't have the time) to try to duplicate this -- but again, that should be Microsoft's problem not mine. Who knows in 3-6 months we might get a meaningful response from Microsoft.


    That seems a little ridiculous to me that we as programmers can't set breakpoints while in mid compile...

    But I guess I'll try to reinstall everything. Does Windows 2003 need to have .net framework or can I safely uninstall then reinstall without any problems?
    Thursday, March 8, 2007 12:52 AM
  • Hey this is only a theory and I've been careful to avoid doing this just in case the theory is valid.

    I believe Win2K3 R2 comes with .NET 2.0 as part of the OS install.


    Thursday, March 8, 2007 4:49 PM
  • Out of curiosity I tried a regular windows app and it hit break points just fine... Then I go back to my asp project and the break points blow up... Goody huh?

    For reinstallation of .net framework. Should I simply go into add/remove programs and get rid of everything .net framework related then restart and go to windows updater and install again? I so hate reinstalling some stuff from microsoft... More often than not it does the same thing as before I reinstalled along with stupid bugs from the product not removing itself fully added on...

     SureshM wrote:

    For cracking this issue asp.net, do the following steps

    1) stop www services

    2) delete all the cache from C:\windows\microsoft.net\framework\v2.0.50727\Temporary ASP.NET Files

    3) delete all the PDB and Dll file which in bin & obj directory of asp.net project

    4) start the service and compile the project.

    It will work.


    Suresh M

    I originally did not try these steps fully but figured I would give them another go. They worked with one small difference I didn't stop stop www services (couldn't find em) I did try IIS Admin Service though. I then went and deleted the cache files and every bin and obj folder I could find that was in any folder that was anywhere close to my projects name... Started up the service compiled and ran the project broke into a break point no problems...

    One suggestion to avoid this... Be patient! Don't set break points while vs is building EVER. This is what started this whole mess for me.
    Thursday, March 15, 2007 1:06 AM

    I had the same problem when developing a program for a pda. The dll name had 2 capitals (ex. MyDll.dll) but after deploying to the pda the dll name on the pda only consisted of small capitals (mydll.dll). Because the MyDll.pdb on my local machine still was in capitals, VS2005 debugger could not load the needed symbols.


    I changed the 'Assembly name' (right click on project, tab 'Application ') from 'MyDll.dll' to 'mydll.dll' and the problem was solved.

    Thursday, April 19, 2007 9:32 AM
  • Hello All,  just  a quick suggestion.  I had similar problems in VS 2003 a VB.Net appliation,  but was able to restore normal debugging by changing the Startup Object in the project properties from "Sub Main" to frmLogin.

    I will of course, change it back for the release version,  apperantly debuggin has a problem with debugging a Sub





    Thursday, May 10, 2007 5:58 PM
  • Guys: make sure when you press F5 or click in the VS blue arrow,

    The solution configurations dropdown list says Debug. That worked for me!




    Monday, June 4, 2007 3:36 PM


    This sounds too easy, but if going to the solution properties and the "Startup projects" choose "Multiple Startup Projects" and mark all your projects "start" to be debugged.



    Wednesday, June 13, 2007 3:34 PM
  • Hey all,


    I ran into the same problem myself today, having had no problems for months whilst working on my project (web project), but then equally I'd not tried debugging this page in particular in months either.


    Out of all the suggestions I've read in this thread the one that worked for me was removing the startup URL from the solution properties.


    If I have anything other than "Current Page" selected I have the problems, this is rather annoying obviously as it means I cant test the whole application in one go, rather parts of it.


    I have considered putting a separate page together which can then be the "Current Page" for debugging, and then where I need pages with URL's etc have them listed on that page to click on - it should act in the same way.


    Fingers crossed for a better solution in the near future.


    Tuesday, July 10, 2007 10:18 AM

    I had this problem.  Of course it was a simple as building on the "debug" configuration.  Necessary for including the "symbols".
    Sunday, September 23, 2007 6:09 AM
  • This problem happened to me when I tried to link in a managed DLL into my unmanaged application.  When I compiled the unmanaged application with Common Language Runtime Support (/clr) selected in the application project properties tab (General), I was able to break in the DLL.

    The only reason this was acceptable for me was the application was just a driver app to test my DLL.  If I was using my unmanaged application and expected to be able to debug my DLL, I'm not sure what I would have done (I guess create a managed app to test with Stick out tongue )

    Hope this helps someone!
    Wednesday, October 10, 2007 5:06 PM
  • I've migrated most of my VS 2005 .NET 2.0 code over to VS 2008 .NET 3.5 and have not ran into this problem since.


    But just for reference, when I do run into this problem with VS 2005 it is with a "fully managed" application (nothing unmanaged about it) -- long ago I gave up doing anything that is NOT fully managed.  It's hard, but the benefits in the long run are worth it rather than having to deal with unmanaged.


    With VS 2008 and WPF I'm finding much less need to do anything unmanaged.


    Now don't get me started on Vista's UAC -- I find it hard that intelligent people actually came up with this implementation of security. 

    Wednesday, October 10, 2007 5:45 PM
  • The issue is documented on MSFT site, if you're Web debugging on Vista.




    Wednesday, October 10, 2007 10:26 PM
  • It's not specific to web debugging -- some of my VS 2005 apps are not web apps and still have the problem.




    Wednesday, October 10, 2007 10:42 PM
  • Thanks rchiodo ! You sure saved my day today :-)
    Monday, October 29, 2007 7:19 PM
  • I have been running into this problem. In my case, I directed all the output of the C++ compile/link dll and managed application to "C:\1" directory (can be any directory) and now it will hit the breakpoints. Just make sure all output is directed to the same directory. I am not sure all the things the debugger is looking for but it works.


    Wednesday, November 14, 2007 6:28 PM
  • Weird, I just got this working again.  I have no idea if this will work for others but . . . .

    From VS2005 in  a web project select Website/ASP.NET Configuration menu item


    This magically opened a Web based management too.  I set tracing = true. Things magiacally worked. The net of this was that the tool wrote a line in my web config.


    <trace enabled="true" localOnly="false" pageOutput="true"/>


    I suspect this forced ASP to dump ita assembly cache or something. 


    Thursday, November 15, 2007 5:20 PM

  • I had the exact same problem. The issue started when i added another project to an existing solution  that worked fine.  i added  reference to the new project by referring the projects dll. Here's what i did
    a) delecte all bin files
    b) delete all obj files
    c) clear all files from asp.net temp dir
    d) remove dll referencing of the new project and added reference to the project itself ( add reference >choose project tab)

    Now the symbols are loaded!

    hope this helps.

    Thursday, April 3, 2008 5:50 PM

    Just reboot the machine.It will reset again whatever it has reset wrongly.
    Tuesday, April 15, 2008 5:16 PM
  • Solve:

    I am using vs2003 with an application devolped in VB.


    • I just include in the bin folder the output .dll and .pdb files generated by the self proyect and that's it.


    Tuesday, April 22, 2008 10:59 PM

    if we are using more than one project (i m using 267 projects a time in my one solution) check for the output path in build properties of the particualr project. The output path should be same for all project including the startup project .


    Go to Project Properties >> Build >> Output Path.

    Wednesday, April 23, 2008 8:16 AM
  • This worked for me:

    Go to Tools. Options,Debug, General,

    And uncheck: "Enable Just My Code."

    Worked for me after trying almos everything! Just can't belive i can now debug my dlls!!
    Wednesday, April 30, 2008 7:57 PM
  • the VSIDE settings is the answer
    Tuesday, February 17, 2009 10:05 AM
  • "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files" in this path I do not have any files, still I'm having issues to debug my windows service using Visual Studio 2008.
    Tuesday, February 24, 2009 4:58 AM
  • This solution did not work for me. :-(
    Tuesday, February 24, 2009 5:08 AM
  • This is worked for me..... Thank you so much
    Tuesday, February 24, 2009 5:47 AM
  • My problem was caused by one of my projects holding on to an outdated version of another project. For example: projectA references projectB but when I rebuilt the solution projectA didn't get a new copy of projectB (don't know why). So when I gac'ed, the old version of projectB's dll was installed. I fixed it by changing "Copy Local" to true for projectB in projectA's references.

    It would be nice if the IDE gave a good reason why the PDB's didn't match. In case, the version of projectB in the gac was couple of days old!
    Friday, May 29, 2009 2:14 PM
  • Bless you!
    why isn"t it set by default?
    Tuesday, July 7, 2009 12:59 PM
  • Hi Community,

    I have also been victim of the impious “symbols not loaded” nightmare but luckily one of the hardcore devs showed me a little trick that sorted my problem of "Symbols not being loaded and breakpoint not being hit" problem out.

    Basically all you need to do is add the following to the Page directive:

    AutoEventWireup="true" Debug="true"

    We can also specify the default value of the AutoEventWireup attribute in the following locations:

    ·     The Machine.config file.

    ·     The Web.config file.

    ·     Individual Web Forms (.aspx files).

    ·     Web User Controls (.ascx files)

    You must not set the value of the AutoEventWireup attribute to true if performance is a key consideration. If we set the value of the AutoEventWireup attribute to true, the ASP.NET page framework must make a call to the CreateDelegate method for every Web Form (.aspx page), and instead of relying on the automatic hookup, manually override the events from the page.


    Credit:             Thomas Varghese

    Website:      http://www.codeproject.com/KB/aspnet/AutoEventWireup.aspx

    Hope this helps,

    Friday, February 12, 2010 8:07 AM
  • So I responded to this column stating that I fixed my problem by changing the default start document.  And it did fix it for a minute, but that was all....

    I did change my startup project to another one of the four I have in my project and then I could debug that one.  The other three projects included in the "master" project cannot be debugged.

    This is so frustrating.  I have worked on finding a real solution for days.  Everything I have read here and elsewhere have not permanently or completely fixed the problem.

    This project also loses a lot of its dlls on build. I have close out the program and empty the cache folders and open it again, cross my fingers and recompile.  I am sure that these issues are related because they showed up at the same time.

    I recently installed vs 2008 sp1 and IE8.  THen I uninstalled IE8.  I don't know if this is the cause of the problem or not, but if someone knows can they provide a fix?

    Please advise!  I have already WASTED three days on this!


    Tuesday, March 16, 2010 8:33 PM
  • Unchecking "Enable Just My Code" also worked for me.

    I had an assembly that I was loading through reflection.
    Thursday, March 18, 2010 6:57 PM
  • Ok - I have the same problem with VS2008.   My Web Service breakpoints give me the dreaded "no symbols loaded for this document" message.

    I have tried everything on this prolonged thread - which appears to contain everything from reinstalling everything to chanting and snake-charming.    The only thing that worked for me - so far - is to go to the web tab on the application settings and under Start Action (at the top) change "Don't open a page,  wait for request.... to "current page"

    THIS MAKES NO FRIGGIN SENSE!    This functionality is apparently so fragile it makes me feel like all my code is a house of cards!

    I've been working on this code for 8 weeks now, and yes, I recently made a bunch of changes.   When I attempted to run the code I could no longer debug.    I want to keep this thread alive - because MS really needs to step up and figure this out.   I'm happy to provide my entire project to anyone at MS who could help resolve this!

    Monday, March 22, 2010 2:03 AM
  • OK, this is crazy. 

    .NET 3.5 SP1

    Visual Studio 2008 V9.0.30729.4108


    I had a solution I was testing, it had two projects, a class library and a wpf application as a test bed. I had created a reference to it in another solution and all was well. Then, I deleted that reference and went File - Add Existing Project and selected the project file of the class library. KABOOM. No symbols loaded.

    I have deleted every .pdb, changed Properties / Build / Advanced / Debug Info, I've rebuilt, I've cleaned, I've unchecked the 'Just My Code' option, I've reset the machine, closed and opened solutions and generally mucked around.

    This is crazy, there are posts here on the same issue from 4 years ago! Can we pretty pretty please have a .pdb / GAC cleaner utility???


    EDIT : Ok, well... interestingly, the breakpoint indicated no symbols were loaded... then it hit anyway and I haven't seen it since... 

    • Edited by Matt Searles Tuesday, April 13, 2010 5:35 AM Hmm..
    Tuesday, April 13, 2010 5:21 AM
  • Had the problem where i could not debug a method i called in a different form in a VB.net application VS 2005.

    Cut & pasting the method to end of the class fixed it.


    Hey MS maybe do sth about it?

    Something that does not invole command line, deleting files or in general doing stuff besides clicking on a button inside VS that fixes it.

    Tuesday, April 27, 2010 12:51 PM
  • Hey guys.

    You are most likely compiling you code under the release and not the bebug configuration. To check click on Build->Build Manager... When the new window comes up click on the down arrow Active Solutions Configuration and select Debug.

    Monday, May 17, 2010 5:03 PM
  • According to Grumpy McNasty solution, it works with me fine for VB.net VS 2008.
    Load your project in VS.net Environment  goto Menu item:   
    Project -->  YourProjectName Properties  --> Compile tab --> Advanced Compilation Options --> Generate Debug Info. --> select 'Full'.
    Thanks for you Grumpy McNasty .
    Sunday, May 30, 2010 7:44 AM
  • With vs2008 C# the instructions from Grumpy McNasty would read as follows:

    Project -->  YourProjectName Properties  --> Build--> Advanced...(literaly, "...")--> Debug Info. --> select 'Full'.

    But Unfortunatly for me, it has not fixed my particular problem with "Symbols not being hit"

    How hard can this be?  The DLL is in a folder, the pdb is in the same folder, both were created within a millisecond of each other. 

    Tuesday, June 8, 2010 9:29 PM
  • (Spoiler alert, the answer to this problem is not here either, but this seems to be a good coalescing of the information above.)


    My version of the “No symbols have not been loaded” is a little different from those described above.  I am working on an XP 2003 server with VS 2008, it is a WPF C# solution with 15 projects. 

                The C# code files as code behind for the XAML files are fine.  The C# code file for the code behind in the web projects have the “No symbols have not been loaded” problem.

    <listing of things tried>

                I have:

                            Verified all projects are set to debug.

                            All dll’s are not gac’ed

                            Destroyed and rebuilt all PDB files.

                            Changed the Output path location of the bin debug directory to match the startup project.

                            Removed and rereferenced the problem project.

                            Set Debug info to Full

                            Veified “Enable just my code”was unchecked.

                            Veified Web.config compilation. Debug = true.

                            “Attached to process” at the established port.

                            Set compilation  debug="true" and autoEventWireup="true" on the web.config file for the project.


                            Deleted all files in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files  (note, you must shut down your project in Visual studio to remove the correct files.

                            Under ProjectàASP.NET Configuration, launched the Web based management tool mentioned by  Eric.  (clunky tool, probably built as an exercise, but not as convenient as the Winform check your options tool)  Under tab Application àDebugging and tracing, selected “Capture Tracing information” and “Display tracing information on individual pages” Which wrote

        <trace enabled="true" pageOutput="true" /> into web.config.


                Followed SureshM’s directions explicitedly.  Some steps are repeats of other recommendations, but some times it is the order that matters:

    1) Stop www (I stopped www publishing, and IIS )services

    2) delete all the cache from C:\windows\microsoft.net\framework\v2.0.50727\Temporary ASP.NET Files

    3) delete all the PDB and Dll file which in bin & obj directory of asp.net project

    4) start the service and compile the project.


    </listing of things tried>


                So I have to say, why am I going down this rabbit hole?  It started with a simple problem of just wanting to check a misvalued variable, and is now a half day loss.  Neither my original problem or the “No symbols have not been loaded” problem has been resolved.  This for trying to trouble shoot my tools.  The tools should work.  You have an advertisement for VS2010 that says, “What will you do with Visual Studio 2010?” and my answer is “Absolutely nothing!”  One the main reasons to use VS is the debugger.  This problem has persisted 2003, to VS 2005, Servicepacks, to VS 2008 and it’s service packs.  This is primary functionality people.  IT NEEDS TO WORK.


    Wednesday, June 9, 2010 2:21 PM
  • VS-2008 - F9 breakpoint vs. CTRL-B breakpoint  (F9 doesn't seem to work while the code is running (works if set before debugging starts)

    I've been playing with this for about a day now, just to figure out what works, and what doesn't.

    The code I'm running is nothing special, just a simple TCP connection console program, where I want to break on the parsing of a serialized XML message being passed in.

    When I press F9 or use the mouse to set the breakpoint on the "parse" function before executing code, I have no problem.  However, once the code is executing, using either of those methods to set the breakpoint results in the error described in this chain.

    However, if I use CTRL-B to set breakpoints on any method named "parse", or use the shortcut--search combo box for "parse" and press f9 from the combo box--then the breakpoint is set and executes as it should.

    So, this makes me believe this is a definite issue with VS 2008.  Why does CTRL-B work when F9 doesn't? 

    Also, I converted the project over with VS 2010, and it exhibits the same behavior.

    Thursday, June 10, 2010 5:22 PM
  • I am running VS 2010 Pro with Team Foundation Server and got the same issue out of the blue.  I tried lots of other things mentioned in this thread, but this worked for me.

    I deleted everything there is for my solution on my local drive. 

    Then I restarted VS, opened the Source Control Explorer window, selected "Get specific Version...", and clicked the checkbox marked "Overwrite all files even if the local version matches the specified Version". 

    Once the entire solution downloaded to my local drive, I opened the solution, built, and ran in debug mode.

    Everything worked, all breakpoints can be hit again.

    (I only lost 2 hours.  Based on the other responses here, I feel lucky!)

    I know not everyone will be using Team Foundation Server, but if you're using any kind of source code control, then knowing that you can completely wipe out your local version of the solution and reload it may help. 

    Hope this helps, Good luck.

    Friday, June 11, 2010 5:24 PM
  • I actually have a victory here.


    To load the debugging symbols for the Web Project.

    I deleted the relevant BIN Directories, including the temp folder in c:\inetpub.  (this may have not have contributed to the fix, but is included for completeness)


    Then in the project  that eventually makes calls to the web project, under properties, Debug tab, check “Enable unmanaged code debugging.” 

    Rebuild project.


    Launch.  A dialog box appears.

    “The security debugging option is set but it requires the Visual Studio hosting process which is unavailable in this debugging configuration. The security debugging option will be disabled. This option may be re-enabled in the Security property page. The debugging session will continue without security debugging.

     This message can be ignored as a quick search finds a VS 2005 bug ticket dated 2007.  So this issue has been around for at least 5 years.


    Then voila!  (note small text, if this was 3 days ago I would have been happier)

    Friday, June 11, 2010 9:16 PM
  • Hello there.

    My solution for this problem was the simplest thing ever, at least for me.

    I had this issue several times, the first time I spent 2 days and ended up frustrated with no results, even after doing all the methods posted above.

    Ok here it is:

    - Open your project;

    - Remove all current breakpoints from your project;

    - Close ALL the files open (I mean, just stay with the project opened at Solution Explorer. NO opened pages/files or whatever). Yes, I want tou to have a gray Visual Studio in front of you :)

    - Close Visual Studio, and start again.

    - Now it's time to spread your breakpoints, and it will work.

    It's the first time I post here, but I really felt like to share this experience. For me at least worked like a charm, and took like 2 minutes.

    Good luck,


    Monday, July 19, 2010 10:49 AM
  • This is the most frustrating issue. Ever! I have been troubleshooting this problem for more than 3 days now to no avail and have not been able to advance my development project since. I have even resorted to rebuilding the entire project from scratch by copy/pasting every single line of code into a clean project. I have searched and removed every pdb file, every dll created by my project, ungac'ed all my assemblies, and a number of other 'witch hunt' techniques outlined in all the above posts. I cannot imagine how anyone can be productive like this.

    My project happens to be a C# class library with references to Microsoft CRM web services. Debugging worked for a while until a few days aback when I had to add a new CLR stored proc to my project. I made a few changes to the code, and followed the same steps I have followed to redeploy the assemblies since I began working on this project in April of this year. Nothing, just about nothing seems to work. What is it with these PDB files? Why is it that "Clean Solution" does not perform a true cleaning? Why is it that there isn't a single, standard, centralized location and set of steps to perform, whether on TechNet or MSDN, when these things happen. As you can tell by this thread and seaches for this same subject on the web, this issue is not confined to a bunch of amateur developers trying to play with Visual Studio. This issue has puzzled and frustrated even the most seasoned professionals.

    Please, when can we see a final resolution to this problem?

    Mariano Gomez, MIS, MCP, PMP
    Maximum Global Business, LLC.
    Blog http://dynamicsgpblogster.blogspot.com/
    Friday, July 23, 2010 1:52 AM
  • Hi,


    Any progress on this, have tried various suggestion given above but they have not worked for me! I am having same problem on vs2010 while calling c# code from vbscript. I can attach to the wscript process and debug vbscript, but can't debug c# code because of the error 'Breakpoint will not currently be hit. No symbols loaded for this document.'

    Very frustrated !!

    Tuesday, August 17, 2010 4:00 PM
  • JN1987,


    I was able to clear up the same issue by using "Rebuild Solution" Cntrl Alt F7 instead of simply build solution F7.

    It seems that Rebuild also regenerates and links all supporting files (DLLs). 

    I am using MS Visual C++ 2005...

    Good luck

    Thursday, September 9, 2010 2:55 PM
  • I have tried almost all the settings mentioned in different forums. But couldn't succeeded. Finally I have added my both dll project (Studio 2005) and .exe project (Studio 2005) in to the same solution. I didn't change any other settings. Surprisingly it worked. Hope this message will help others.
    Thursday, September 30, 2010 9:15 PM
  • Thanks suresh your instructions worked for me.
    Thursday, October 14, 2010 8:38 PM
  • Hi ,

    I started getting the same problem, when I changed the  vs.net 2008 project setting while using a dll.


    My program started stopping at break point while debugging.

    I changed project properties->c/c++->Debug information format->/Zi

    and in properties->Linker->Generate Dug Info->Yes and Debuggable assembly->Run time tracking and disable optimisation





    Wednesday, December 1, 2010 9:08 PM
  • I'm using vs 2010, I had the same problem, non of the above worked for me.

    I opened up the property pages and set the use custom server to http://localhost:xxxx

    This might not work of you it did work for me

    The settings I currently have in Debug > Options and Settings >  Debugging > Symbols  

    Microsoft Symbols Servers is checked.

    Saturday, February 12, 2011 12:00 PM
  • I had my web app pool running as a web garden with 8 worker processes and processor affinity set to false.  I changed it to  1, set processor affinity to true and all works now (for me).  Just one other thing to look at. 
    Tuesday, March 22, 2011 4:20 PM
  • i had a similar problem in vs2010 running a webservice, and an exe to get them to hit breakpoints i had to go into the solution properties and set them both as startup projects.

    Hop this helps!

    Monday, March 28, 2011 12:26 PM
  • This could be an array of reasons of why this is happening. I resolved this issue by stepping through the code only to find that an exception is handle internally and code breaks before getting to the my breakpoint. However, your code would just finish without result; so you will never know that your breakpoint was not hit. To find out if my solution will help, put a breakpoint at the main entry of your code and run on debug. If it hits the breakpoint, then you are good. Step into until you find what line of code (could be tedious as you might have to step into other classes) that has an exception that is not thrown.

    If you want to force this exception to be thrown, click Debug > Exceptions . Make sure you 'Thrown' and 'User-unhandled' check boxes  on the same row as 'Common Language Runtime Exceptions' are clicked. This will force the internally handled exceptions to be thrown.


    My Environment: Visual Studio 2010


    Good Luck.

    Thursday, April 21, 2011 2:47 PM
  • Another scenario which can cause the problem - Interop

    if you are trying to debug a .net usercontrol hosted in a VB6 application, the VB6 IDE will not load the assemblies until it deems that they are needed.  Therefore, the dlls will not be attached to the VB6 process and will not be visible in your modules. To solve this, make sure that the form or whatever is hosting the usercontrol is openned before trying to attach the VB6.exe process, and you'll get your breakpoints back.

    Thursday, September 1, 2011 1:50 PM
  • What helped me on this was setting the "Project Properties-->Build Settings --> Output Path" field to "bin\" ; whereas, previously I was setting it to "bin\x64\Debug". Once I did this, the DLLs in question popped up in the "References" list with a yellow exclamation mark, indicating a version issue. I deleted the offending DLL references; and then re-added them using the Add References --> "From Project" which doesn't take a directory path. My mistake was thinking that I needed to tinker with the build output path, rather than just letting Visual Studio figure it out based on my configuration manager settings.
    Wednesday, November 2, 2011 5:57 AM
  • I simply rebuilt my entire project with the solution explorer.  Everything worked fine after that.
    Tuesday, August 14, 2012 3:13 PM