By Instance Hunter

2010-01-28 16:09:10 8 Comments

A C# desktop application on the express edition worked, but then it didn't work 5 seconds later.

I tried the following:

  • Ensure debug configuration, debug flag, and full debug information are set on all assemblies.
  • Delete all bin and obj folders and all DLL files related to the project from my entire machine.
  • Recreate projects causing the problem from scratch.
  • Reboot.

I have two Windows Forms projects in the solution. One of them loads the debug information, one doesn't. They both refer to the assembly I'm trying to get debug information on in exactly the same way in the project file. Any ideas?

I want to add here, mostly for myself when I come back to review this question, that symbols are not loaded until the assembly is loaded, and the assembly is not loaded until it is needed. If the breakpoint is in a library that is only used in one function in your main assembly, the symbols will not be loaded (and it will show the breakpoint as not being hit) until that function is called.


@Ali 2011-08-26 05:56:26

I was going mad trying to figure out why my JavaScript file would not debug and it took looking in the "Script Documents" (the loaded scripts) to realise my script was not there.

The designer had edited the page headers and replaced my individual developer JavaScript files with a combined minified version. I didn't realise until an half an hour's worth of googling and debugging attempts.

So basically I recommend looking in that list when debugging. If it's not in there, it can't be debugged. Doh.

The designer was doing the right thing. It just should have happened at the release stage, not the beta. A list of which script includes were minified would also be good, so it can be rebuilt for development.

BTW I tried the Modules stuff from previous answers, and obviously it was not that. The script was actually not being loaded in the project. Sigh.

@DharmaTurtle 2020-05-28 19:26:03

For me, the test class was annotated with [Ignore]. I don't know why it was still showing up in the test explorer, but whatever. This is with the Visual Studio Unit Testing Framework.

enter image description here

@developernader 2020-04-21 08:16:56

Because there's file in another project have same name, May be you have two controllers have same name

@DDT 2020-04-09 21:47:26

I had the same problem. I tried EVERYTHING in this post.

My solution?

Change the Visual Studio version (I was trying to open it on VS2013, ended up opening it on VS2015)

@IVSoftware 2020-04-04 21:00:42

Maybe I can add something new. Unless I missed something (possible!) in these many posts, there doesn't appear to be an accepted solution or any mention of System.Reflection.Assembly.LoadFrom(filename) which is the method .NET provides when you need explicit control. If the Modules tab shows assemblies loading from unexpected locations, this is how you can fix that and get your debug breaks back.

Sometimes there are very good reasons for doing this. For me, it was when I was supporting a platform that allowed users to create somewhat arbitrary plug-ins, and I had to be careful about having a race with those plugins about where the common assemblies get loaded from. The goal was to make sure the "golden" versions living in the same directory as my Platform.exe would ALWAYS be the ones to load without exception. (Putting them in the GAC is sometimes the right answer but not always).

I has been rightly mentioned in other posts that default build settings cause referenced assemblies to get copied locally in the \bin of the plug in when it builds. Plug-ins are one example of a use case where that's the total opposite of what you want to happen. There might be 100 users with 100 plugins and 100 copies of a given assembly. Which one of the 100 will load? And will it be the latest, correct version?

Here's how I was able to do this reliably for a real-world platform that I supported for more than a decade, loading assemblies up-front.

using System;
using System.ComponentModel;
using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Windows.Forms;

static void Main()
    Form appInstance = new InstanceManager();

private static void PreLoadAssemblies()
    // Obtain an explicit folder path relative to where
    // the main executable ("Platform.exe") is running.
    string dir =
        Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) +

    PreLoadAssembly(dir, "Google.Apis.Auth.dll");
    PreLoadAssembly(dir, "Google.Apis.Drive.v3.dll");
    PreLoadAssembly(dir, "Google.Apis.Auth.PlatformServices.dll");
    PreLoadAssembly(dir, "Google.Apis.dll");
    PreLoadAssembly(dir, "Google.Apis.Core.dll");
    PreLoadAssembly(dir, "Google.Apis.PlatformServices.dll");
    PreLoadAssembly(dir, "Newtonsoft.Json.v10.dll");

private static void PreLoadAssembly(string dir, string name)
        Assembly resolved = Assembly.LoadFrom(dir + @"\" + name);
        Debug.Assert(resolved != null);
    catch (Exception ex)
        Debug.Assert(false, ex.Message);

@Mike 2019-07-30 11:21:16

Check are the following two setting the same in Visual Studio:

Right click test project, go to Properties, Build tab, and look at Platform target

Mine are all set to "Any CPU" so x64

enter image description here

On the Main Menu bar, go to Test, Test Settings, Default Processor Architecture

Mine was set to X86

enter image description here

Changing this to X64 to match above setting made the built in Visual Studio menu “Debug Test(s)” work and hit breakpoints that were previously ignored with the message “The breakpoint will not currently be hit. No symbols have been loaded for this document”.


For Visual Studio 2019 the menus have been moved around a bit: enter image description here

@Mark Pazon 2020-02-03 14:15:29

As stupid as it may sound, be 101% sure that you are referencing the right class.

In my case I have a GameObject in which I added the wrong script to the components. Hence, there is no way for Visual Studio to actually reach the code.

I simply had to delete the wrong C# script and component and add right one.

@dkokkinos 2020-01-20 19:34:31

Check if in the csproj file there is a line/entry with the <DebugType>Full</DebugType> If it exists then try remove it and try again to debug

@DDT 2020-01-17 11:53:03

Had this problem yesterday with a Web Project, tried many of the solutions proposed here and didnt work.

How did I solve?

Right click on the project -> Properties -> Web tab

In Servers section I changed IIExpress for Local IIS, created the virtual dir, and voilá!

@Bimal 2019-11-20 05:28:26

  1. Clean solution and Rebuild
  2. Check the configuration is set to Debug
  3. Make sure that the PDB file is in the Debug folder it self
  4. From Debug menu click Enable All Break points

@Izaias Dantas 2019-12-04 19:57:32

I resolved this way: Run the project. Go to, Debug -> Windows -> Modules Choose the library you want debug and right click in it. Choose -> "Load Symbols" and then will change "Skipped loading suymbols" for "Symbols loaded".

@Zoltan 2019-11-28 10:06:06

Make sure your files are open from the relevant project, not from another (old) one.


  • You working on a project, close the VS, but you left files (tabs) open in VS.

  • Copy your project to a new folder and open solution. The files (tabs) will load from the old directory and if you want to debug then you cannot debug until you close them and reload them from the current folder.

I was very close to reinstall my VS because nothing helped for me from another answers, but fortunately I realised this in my project and I can debug now.

@Farshid 2019-11-24 11:13:07

I test all answers for this question not work for me, I use this below method:

I exclude that file(s) has breakpoints from project where that visual studio can't hits them and then I includes them into my project and worked breakpoints.

@aseman arabsorkhi 2019-10-20 08:40:41

it was so easyyyy. it also happend for me because .pdb file of the project have not copy in debug\Bin folder then it could not load symboles (.pdb file) in debug mode . in this way : you must rebuild your target project and manually copy the symboles (.pdb file) in debug\Bin folder of execute project

@LuisEduardoSP 2019-08-20 18:23:25

I had this problem.

My issue was that the aspx, aspx.vb and aspx.designer.vb files were imported wrong (Perhaps they were imported one by one to the project).

The breakpoint were in the aspx.vb, but was unreachable and had the warning of this question.

The solution was to delete the three files and import them again. Now I can reach the breakpoint.

@brykneval 2019-06-18 10:29:29

I had same problem, checked all the previous solutions but didn't work for me. Simple but added answer just to make sure people don't get stuck on this not to exist problem as I did.

What worked for me was, I was running VS 2013 on admin mode and running on normal mode did the trick. Tried multiple times switching to normal and admin mode and its consistently working fine.

IDE: VS 2013 Professional
Version: 12.0.40629.00 Update 5

@zs2020 2019-05-29 20:57:35

Check your Solution Configuration drop down list. Make sure you select Debug, not Release.

@peter bence 2019-05-20 13:11:43

If you are using a C++ project or dll from a C# or any .Net project, and you want to debug into the native code. Then go to the .Net Project Properties -> Debug -> Enable native code debugging (set it to true).

@juFo 2012-09-04 11:47:45

First try rebuilding your project by right mouse click the project > Rebuild If that doesn't work, try a clean of the project (right mouse click on the project > clean)

If that didn't work check this:

  1. Right mouse click your project
  2. Select [Properties]
  3. Select the [Build] tab
  4. Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
  5. Make sure [Optimize Code] is unchecked
  6. Click the [Advanced] button at the bottom of the Build tabpage
  7. Make sure that [Debug Info:] is set to [full]
  8. Click [OK] and rebuild the project ;-)

(step 6 generates the .pdb files, these are the debugging symbols)

@Chiefy 2014-02-13 09:35:51

Make sure that [Debug Info:] is set to [full] - fixed it for me! I have multiple configurations set up on my project, the new ones I added didn't have this set.

@Aaron Shaver 2015-07-29 20:30:44

This worked for me! But instead of [full] I was able to do pdb-only

@PNDA 2015-08-29 12:49:47

Turns out I was in the release build. tsk.

@James 2015-12-15 22:14:21

If you don't have a build tab, you can also go compile > Advanced compile options > steps 4 - 7. That did it for me.

@CSS 2016-01-09 00:12:32

That's great if you're only working with a single project, but I've got 20 and the active process iterates through all of them, depending on the specific process it's running.

@Bill Hoag 2016-03-09 15:40:58

If you have a mixed C++/C# project with a native startup, make sure it's project's Debugging > Debugger Type is Mixed.

@jeffaudio 2016-12-09 16:32:08

I also had to make sure that Properties > Build > Optimize code was unchecked.

@Zakk Diaz 2017-02-13 20:42:35

Another developer created additional build configurations and we didn't know the above was required for loading the debugging symbols. After following the above steps it works as expected

@curiousBoy 2017-09-04 18:23:39

This works thanks a lot. But what is the trade off for this? If nothing, why it is not default?

@Andy Sinclair 2017-11-11 12:56:11

Setting Debug to full worked for my core project, thanks!

@Jon 2018-03-23 17:36:32

[Debug Info:] is set to [full]... Thank you. Not sure why this project was set to "none".

@Michael Earls 2018-05-02 15:13:34

Using the "full" setting causes issues with netstandard projects that use .NET 4.x libraries. Our WebApi project would fail to build after an exception when the debug info was set to "full". We had to restart Visual Studio to unlock some .dlls. However, setting it to "pdb only" still enables debugging for us, but doesn't cause the odd side-effects.

@karthik kasubha 2018-12-01 15:04:49

Hi , I had a web project and wcf project , break point was fine in web but for WCF faced the error “The breakpoint will not currently be hit. No symbols have been loaded for this document." on WCF project went to tools-->"Attach to process " able to hit the break point and issue got resolved .

@John 2019-05-13 10:57:12

DEBUG constant has nothing to do with this.

@abdallah mahmoud 2019-05-07 10:35:19

Debug ->Options -> General -> Uncheck mark for "Enable Just My Code"

This worked for me.

@Agamemnon 2019-05-17 08:47:26

This seems like it might be a default setting that is worth checking if upgrading VS to newer version (as had happened to me).

@melicent 2019-04-09 19:45:24

After trying a bunch of these, the thing that ultimately worked for me was this:

In Debug > Options > General, uncheck Enable Edit and Continue.

@melicent 2019-04-12 17:28:32

I ran into the same problem a few days later and the above solution didn't knock it out for me this time. I'm running my solution using docker-compose and it turns out the problem was with the dockerfile of my project. Whatever VS originally dumped into that file wasn't building the image correctly or putting it in the right place.

@FrenkyB 2019-09-13 11:33:40

I can not change this setting, it's grayed out. I am running VS as administrator.

@Karthik 2019-04-04 07:04:25

The Following steps forked for me:

  1. Go to the "bin" folder of your project.
  2. Delete the "Debug" folder.
  3. Build your project again.
  4. The Debug folder will get re-created.

Now you can start debugging again.

@I Want Answers 2019-03-03 03:14:32

I think the source if this error is, the debug symbols have a hard time surfacing to the solution after building for release.

I tried all the other answers -- generally, regenerating .pdb symbols or checking their location, cleaning and rebuilding project, ensuring active configuration is not Release etc.

What eventually worked for me is right-clicking on the project in solution explorer > Debug > Start new instance.

@Yojana Ambavkar 2019-02-21 10:31:46

Try to do this. It worked for me.

Debug=>Options=>General => Remove the check mark for "Enable Just My Code"

@nPcomp 2018-12-27 21:04:22

In my case, none of these solutions worked. I had to go to

Tools -> Import and Export Settings -> Reset all settings.

and then debugging started working without any issues.

@user781700 2012-10-02 15:10:25

I also had the same issue what I rebuild the whole solution (including refereced projects) in x86( or x64)

Even though I set all of my projects to x86 from Configuration Manager (Build->ConfigManager) some of my projects were not set to x86.

So Just to make sure right click on the project and follow

project -> properties -> Debug Tab, verify Configuration and Platform.

@tfa 2017-06-15 23:59:59

This took me a while tried other options above and for some strange reason debugging stopped working.

Tool -> Options -> Debugging -> General -> (untick) "Require source files to exactly match the original version" option

@UuDdLrLrSs 2018-11-15 13:12:20

When debugging an assembly by starting an external application there are some extra considerations:

  • The external app may load its own copies of assemblies (DLLs) from a manifest file. (e.g., file appname.exe.manifest) If so, you need to disable this possibly by manually altering the manifest.

  • The external app may just try to load from DLLs in its own folder, even without a manifest. You will have to remove / rename these.

With these steps taken care of, the version of the assembly running in the debugger should be correctly loaded and can be debugged normally.

@Kamran Hyder 2014-02-22 09:21:10

When trying to debug an Excel AddIn in VS 2013, after I had tried all Debug settings by disabling DotNet Framework Source Stepping and disabling Symbol Loading, what finally worked for me was changing the Configuration Setting to Release rather than Debug, since the compiler seemed to step over the code and the breakpoints were eventually hit.

@M.Paunov 2018-11-12 08:58:40

If you have both C# and native code(C/C++), make sure that native debugging is enabled for the project:
1. Right-click your Startup Project in Solution Explorer
2. Select Properties
3. Select "Debug" tab
4. Make sure Native Code debugging is enabled "Enable native code debugging" must be checked in order to be able to debug your native code

Related Questions

Sponsored Content

52 Answered Questions

[SOLVED] Visual Studio debugging/loading very slow

44 Answered Questions

[SOLVED] MetadataException: Unable to load the specified metadata resource

2 Answered Questions

[SOLVED] Breakpoints not hit, no symbols loaded

49 Answered Questions

13 Answered Questions

Sponsored Content