在此文件夹中未找到匹配的符号文件

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".

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

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.

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.

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)".

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.

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.

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:

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.

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!

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.

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.

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.

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.

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.