90

I want to use debug symbols, but I am receiving the following error:

a matching symbol file was not found in this folder

What is this problem, and how to solve it?

sɐunıɔןɐqɐp
  • 3,332
  • 15
  • 36
  • 40

16 Answers16

40

One of the things I've ran into with was because debug was off on the project referenced where the code lives. In my case, I made a new configuration called "Developer" and by default debug was turned off.

  1. Right click the project in question
  2. Properties
  3. Build
  4. Advanced (right bottom corner)
  5. Set Debug Info to full
  6. Recompile
Kevin Aung
  • 803
  • 6
  • 12
  • 6
    For a dotnet core 2.0 console app, after I changed its' target framework from `netcoreapp2.0` to `net4.7`, debugging no longer worked. However, changing _...-> Advanced -> Output --> Debug Information:_ from `portable` to `full` fix it. Thanks! – Ray Sep 27 '17 at 19:25
  • 1
    Thanks, you also need to do this if you are using a NetStandard reference in a NetFX project. – Jonathan Dickinson Mar 15 '18 at 20:40
  • That did not work for me. When I select the `pdb` file I get that infamous error. – Shimmy Weitzhandler Sep 29 '19 at 08:55
  • This was not a solution for me. But I found a solution in Resharper plugin. In modules window, on right click, Resharper has an option to generate code from reference dlls. – Ganesh Jadhav Jul 07 '20 at 10:42
13

I had the same problem as @DmainEvent. Apparently the dll that I was using was not the same version as the pdb that I had just compiled, so I got the error message.

If you have this problem, try using the dll and pdb from the same compilation run.

Jeff Piersol
  • 410
  • 3
  • 11
  • Had exactly the same problem. I was manually copying a pdb, but it didn't match the precompiled C++ dll being executed. I suppose I should have known better, but this did the trick. – Sean Skelly Jun 22 '17 at 18:09
  • This solved my problem, I too was manually copying a pdb file into another project. I overwrote the dll with the dll generated by the other project and the debugger than automatically picked up the pdb, I didn't have to specify the path. Thanks! – to6y Oct 06 '21 at 09:31
  • I had such a version mismatch when debugging a Minidump. When doing this, have a look into the _Modules_ section at the _Module Version_ to find the needed pdb version. – MattTT Feb 08 '23 at 09:53
11

The error I got was "a matching symbol file was not found in this folder" in the Debug => Modules window even after both the DLL and PDB were available and built together, so I was unable to debug into the target DLL referenced by my main project.

Posting this here in case it helps someone browsing with "Mixed Platform" build for target DLL. I did two things to get past this:

  1. In the solution using the target DLL, Uncheck "Just My Code" in Tools => Options => Debugging => General => Enable Just My Code (JMC).

  2. Check "Enable native code debugging" in target DLL solution in relevant Project Properties => Debug.

  • 1
    Please format your answer to make it more readable (Bold, italic, list , code indentation etc) – Morse Apr 25 '18 at 14:43
  • This fixed me. I have a web service embedded in a web app I'm trying to debug on the test server, and I have a test client I'm starting via local debugger. Well, it must have rebuilt the web app, cuz it was not loading symbols, so I published (despite no code changes to the web project), attached to the server _w3wp_ process, then started an instance of my client and now it's working. I tried it again with `Enable native code debugging` **unchecked and it still works**; tried a third time with `Just My Code` enabled and **still works**; the kicker was PDB + DLL being built together, methinks. – Tim Dec 01 '21 at 23:05
8

I tried all the possible solutions, finally it worked when I disabled the option Enable native code debugging under the Debugger engines of Properties > Debug.

Dineshkumar
  • 1,468
  • 4
  • 22
  • 49
  • Checking this flag also did the trick for me. Symptoms were just like the poster described. – Timmos Oct 20 '17 at 13:04
6

I ran into this problem and the answer was simple.

Visual studio has two project level settings that can create .pdb files.

  1. Linker: Configuration Properties -> Linker -> Debugging -> Generate Program Database File = "xxxx.pdb"
  2. Compiler: Configuration Properties -> C/C++ -> Output Files -> Program Database File Name = "yyyy.pdb"

You want #1 for debugging. Forget about #2. Give file #2 a different name than file #1 to solve this error.

I don't know why microsoft specifies #2 as a .pdb file. That is just confusing.

C.J.
  • 15,637
  • 9
  • 61
  • 77
  • 23
    The question is tagged with the tag [tag:c#], so these settings don't apply – flipchart Sep 08 '14 at 15:23
  • 4
    In my case the settings are relevant only when the main app is a managed code and I try to debug native code executed by the wrapper. When I debug the native c++ directly via native c++ tester app it somehows magically gets debug info despite pdb file being overwritten. So these settings do apply and helped me solve my problem. – Peuczynski Feb 14 '16 at 14:50
  • This advice about setting the two confusing .pdb file paths worked for my native code project. Only, I just set the two pathnames, #1 and #2, to be the same. – rtischer8277 Mar 20 '20 at 13:36
3

I have fixed my debug symbols, forcing them to match using this tool:

chkmatch tool

edit: the website is down now. the wayback machine helps: https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html

So, my problem was I was trying to debug my project and the debugger couldn't step-in to the in-house nugets sources. I had the source files of the nuget project. Still the visual studio didn't accept the pdb files I was trying to show it to. Showing exact same error:

a matching symbol file was not found in this folder

So, what I did was I added this to the .proj file of the nugets project:

<DebugType>full</DebugType>

And created the dll and pdb file again using the rebuild option. In the command line I ran:

.\ChkMatch.exe -m name_of_your.dll name_of_your.pdb    

It said this:

Writing to the debug information file... Result: Success.

Great success! So, next, I referenced this dll instead to the proj I was trying to debug. I worked when I tried to load the symbol again.

Hope it helps.

Koray Elbek
  • 794
  • 5
  • 13
0

For BizTalk (and other) projects, it could be because there's a version of the assembly you're trying to debug already in the GAC. When you run a unit test or hit F5 to debug, a new version is compiled locally. However, the version in the GAC is being used, and the newly created PDB doesn't match the DLL in the GAC.

One way around this is to deselect a build for everything except your unit test project using the Configuration Manager, as shown below:

Config Manager

Rob Bowman
  • 7,632
  • 22
  • 93
  • 200
0

Well, the solution depends on your specific problem. I tried everything that could be possibly found on Stackoverflow and other sites. One of the thread that I followed is this. That did not help too. The problem was at once resolved when I noticed that my executable project did not contain a reference to the library that I wanted to debug. So I just added the reference to that project.

**PS: ** This problem might also arise because the assembly referenced by the executable assembly might not match that in the references. So in that case, you just remove the already existing reference and add the new one.

Hope this helps!

0

Without more details as to what you're doing, it's difficult to go beyond "the debugger is looking for a symbol file which matches the compiled code, and couldn't find one in the folder where the compiled code lives."

Some things to think about:

  1. Are you creating symbols as part of your compilation? (check the project properties)
  2. Are you using a symbol server (if so, does it point to the right place)
  3. Is this compiled code from a third party? In which case, as you apparently have the source, compile it yourself.

Consider clarifying your question if you want a better answer. Especially what do you mean by "I want use of Symbols".

Massif
  • 4,327
  • 23
  • 25
  • i want use using a symbol server –  Mar 15 '11 at 10:09
  • 64
    I keep getting an error telling me that the symbol file was not found in this folder... When I can see with my own two eyes that a symbol file (pdb) file was found in the folder with the same name. That tells me that the files are not the same. But how can that be when I just compiled the thing and got a brand new pdb file? This was in the bin folder btw. – SoftwareSavant Aug 01 '11 at 17:38
  • @SoftwareSavant did you find an answer? – RJP Mar 02 '18 at 23:10
0

The same happen to me because the .pdb file of the project have not been copied to the debug\Bin folder, so the symbols could not be loaded from the .pdb file.

You must rebuild your project and manually copy the symbols (.pdb file) to the debug\Bin folder of executable project.

sɐunıɔןɐqɐp
  • 3,332
  • 15
  • 36
  • 40
0

I was trying to load symbols for a installed nuget package published on our local dev server. I had to uninstall and add a normal reference built from the code instead. This worked for me. Just remember install the original nuget package again once finished debugging.

0

If it works for you, try to embed debug symbols in the dll itself, so the symbols are loaded automatically. This worked for me in netcoreapp3.1 and net5.0:

<DebugType>Embedded</DebugType>
<EmbedAllSources>True</EmbedAllSources>

Beware that you may find this in documentation:

<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>

but it does not work.

0

I ran into this with Visual Studio 2022, tried the most of answers here. Fixed by switching back to Visual Studio 2019, seems like a bug in 2022.

0

My issue was a bit simpler to resolve, but still the issue the question asked. At first, I was not publishing the pdb file with the nuget package another project was using. Once I confirmed that, I removed the nuget package from my project and readded it from our network nuget source. That still didn't let Visual Studio pick identify the PDB location.

Then I noticed that if you select one of your nuget packages, ( Project --> Dependencies --> Packages --> Choose nuget package), there is a Path property. I checked that location and it pointed to %USERPROFILE%.nuget\packages. The pdb was not at this location and the Date Modified was older than the latest package I published. Once I deleted the folder for the given package version, removed it from my project, and re-added it, the latest .dll and .pdb file were added to this location.

After that, I was able to step into the code of my nuget package and had no further issues.

To get the nuget project to produce the pdb file in the first place, I added <IncludeSymbols>true</IncludeSymbols> inside of a PropertyGroup within the csproj file as other answers had directed.

Once I rebuilt that nuget project, it generated 2 *.nupkg files:

  • Namespace.x.x.x.x.nupkg
  • Namespace.x.x.x.x.symbols.nupkg
jason
  • 2,219
  • 5
  • 33
  • 66
-2

I found this was because the Properties => Debug => Start Action was set to Start external program instead of the Project. So the newly generated pdb file didn't match, because the actual exe was the wrong one.

majjam
  • 1,286
  • 2
  • 15
  • 32
-4

I have had this problem recently as well. Was able to fix it by selecting MyProject->Properties->Linker->Debugging->Generate Debug Info->"Optimize for debugging (/DEBUG)".

Alex B.
  • 348
  • 2
  • 12