I am trying to open a dump file using Visual Studio 2012 but there are some PDB files missing.
Is there a way to make the debugger use another PDB file, built on my machine?
Unfortunately, I can't access the original DLLs and PDBs.
I'm trying to open my PDBs using the "Browse and find ***.dll..." button but I'm getting an error message saying "a matching symbol file was not found in this folder"
Visual Studio does not have an option to ignore mismatched symbols. Other debuggers (like WinDbg) have that.
ChkMatch is able to modify a PDB file so that Visual Studio does not recognize the difference any more. However, the result is what it is: even a slight modification might cause the compiler to emit totally different code. What you see in Visual Studio may be totally misleading. See this answer for details.
Be warned: delete the modified file immediately after your investigation or you will hunt ghost bugs sooner or later.
Related
I recompile my solution, and when it starts in debug mode I get this warnings around my breakpoint saying that it won't be hit.
There is a copy of the source code file that is different.
Why would there be multiple versions of my source code loaded when trying to debug?
I even do a clean compile and still get this error.
Visual Studio is usually pretty good at detecting when your source code doesn't match the code signature of your attached exe or dll process. So I suspect that it is one of two possible issues:
Your debug session's Platform/Configuration (e.g. Debug/x64) doesn't match the .exe or .dll compiled architecture. OR
What you think is a "clean compile" isn't really clean.
The only source code that Visual Studio knows about is the one in front of you. But when Visual Studio is debugging an .exe or .dll, it is attaching itself to the .exe or .dll process, using reflection, and analyzing the code of that .exe/.dll. It determined that your .exe/.dll doesn't match the Platform/Configuration you wish to debug, or its reflected source code doesn't match the written code that is in front of you in Visual Studio's IDE.
When you say that you do a clean compile, make sure that it is really really clean (don't rely on the Visual Studio "Clean" feature. It's not reliable in all cases. For example, if you have created Build Events that copy contents pre- or post-compile. Instead, delete your project's /bin and /obj folders, then recompile. That will ensure your binaries always match your latest code for debugging. Do this a few times, and see if you still get the issue.
I had same error in VS 2019 .I solved that way;
Tools->Options->Debbuging->General and "Require source files to exactly match the orginal version" deselect that option
How can one debug the .NET framework source code using Visual Studio 2017?
There are some questions here on stackoverflow about this topic, but even after reading all of them, I still wasn't able to make it work.
I thought it would be useful to present an up-to-date, working solution about how to debug .NET framework source code.
I would like to solve it without using any external tools (e.g. dotPeek as source server).
First of all, I tested it using Microsoft Visual Studio Enterprise 2017, Version 15.9.7 and via .NET Framework 4.7.2. Though, I think it should work on Community edition the same way.
Steps to take:
Go to Tools / Options / Debugging / General, and perform these settings:
check Enable .NET Framework source stepping (this will automatically disable "Enable Just My Code"; if not, do it manually)
uncheck Require source files to exactly match the original version
check Enable source server support
Go to Tools / Options / Debugging / Symbols, and:
in the upper listbox check Microsoft Symbol Servers
click Empty Symbol Cache button (to make sure you will get the correct symbols)
select Load all modules, unless excluded radio button at the bottom
Download the source of the .NET framework version your project is targeting, from the https://referencesource.microsoft.com/download.html site.
Unpack the downloaded archive (zip) file to a convenient path on your PC.
Debug your application; set a breakpoint to the line of .NET code you wish to debug, and step to the desired code line with the debugger.
Note: your application may start slower since it will download PDBs from the internet.
Press Step Into (F11 by default). If your settings are correct, this will cause some delay (if your VS crashes (like mine did), Empty Symbol Cache again). Eventually it will ask for the sources of the given file, e.g. dictionary.cs.
Two things can happen here:
A) It asks for the source file (.cs) in a file dialog. Go to step 7.
B) It says whatever.cs not found, and there is a link that says "Browse and find whatever.cs...". Click that link.
Select the corresponding .cs file on your disk (you can search for the file on the OS).
Note: I had to restart VS several times until it "did not crash" while looking for sources, this is most likely a bug in VS.
If you did everything correctly, you will find yourself debugging the .NET source code.
Note: Since VS saves the path you entered for the source files, you can stop debugging or restart VS; it will work next time, too.
Besides, you do not have to manually select any more source files within the framework, because the VS will use the source folder you entered and will search in source files there.
Many people wondering why they can't step into source although they does set the checkboxes as described above. I'm, too.
Because you can extract dotnet sources to any location, Visual Studio isn't able to know about them and the reason can't be the source files itself (why Visual Studio doesn't find the files).
But some dll's are browseable, some not (through double clicking in Visual Studios stack view or context menu > goto source). This brought me to the assumption, that the .pdb itself must be the reason. If you look into a file which works (e.g. notepad), you see at beginning a list of strings with file pathes (source files). In files, which doesn't work, the files starting immediatelly with binary data.
For some reason microsoft doesn't create her .pdb's with full debug information in every build process. But why not - good question! g
In short: you have to search a dll version of your file (which you like to debug) which contains FULL DEBUG INFORMATION. This is also the reason why context menu disables "goto source".
I'm replacing this file temporary in global assembly cache for time of debug. This works for me.
Here an example of PresentationFramework.dll
- 4.0.30319.298 => pdb size: 1219 KB
- 4.0.30319.18408 => pdb size: 15.562 KB
Perhabs somebody can create a public database (wiki), which everyone can add files and versions for which full debug information are available?
(If you are like me and after following all steps you still can't step into code...your PDBs downloaded from Microsoft are wrong, try this)
Using JetBrains dotPeek as the symbol server worked for me. (4.6.2 framework) (I did everything mentioned in this thread and many more threads, and nothing worked)
https://hmemcpy.com/2014/07/how-to-debug-anything-with-visual-studio-and-jetbrains-dotpeek-v1-2/
JetBrains dotPeek decompiles your actual .NET DLLs, then hosts a symbol server that you download symbols from in Visual Studio. After a pretty slow download, then a restart of VS, I was able to breakpoint and step into the code.
You can find the path to your .NET DLLs in the "Modules" window when debugging in VS. Enter this into dotPeek. Then Host Symbol server in dotPeek. Then add http://localhost:33417 as your symbol server in VS symbol settings. then load those symbols. it takes a minute and a VS restart, but works.
I have the project solution bin in below location for dll, pdb . my build is getting failed due to below error.
C:\Users\myusername\Documents\Visual Studio 2010\Projects\mysolution\bin\debug\CommonServices.pdb
C:\Users\myusername\Documents\Visual Studio 2010\Projects\mysolution\bin\debug\CommonServices.dll
Error
The command "C:\Users\myusername\Documents\Visual Studio 2010\Projects\mysolution\bin\debug\CommonServices.dll" exited with code 3.
I tried by cleaning the solution and build / Rebuild. Either way, it is not given result.
Please help.
maybe you have some errors on PropertyGroup.
Read this:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/589ffae3-59ca-4d0a-a7b1-9f1120db3792/msb3073-the-command-exited-with-code-3
A couple of things to consider and try - in the title, it says VS 2008 error, but the path points to 2010, are you sure it is pointing to the right reference for 2008?
If it is, try closing Visual Studio, deleting the pdb file. This will eliminate any pdb issues with building, as the pdb file will be recreated.
Then also delete the .suo file, this will also be recreated. This is to eliminate any build issues that may be caused by Visual studio version conflict.
Another thing to check is if there is any build events in your project that may be triggering this error, go into project properties and remove/edit any build commands.
I'm attempting to debug into a method in a library (which was installed via NuGet, if that matters), and Visual Studio is skipping over it with the message:
Step into: Stepping over method without symbols
'Cpi.Net.SecureMail.CryptoHelper.FindCertificate'
I have a symbol server source added in the debug settings, and when I first debugged the program, it told me it was downloading the symbols for this library. I have verified that the symbols were indeed downloaded, as they show up in my symbol cache directory.
Thanks to SLaks, I know now that the PDB that has been downloaded from the symbol server is apparently in an obsolete format. If I retrieve the PDB directly from TeamCity's build artifacts, the debugging works.
So, it appears, that somehow, or for some reason, the PDB file is being altered either through the NuGet packaging process, or through the Symbol Server download process (ProGet).
The scope of the question has now, apparently, widened significantly.
It turns out that ProGet is indeed mangling the PDB file, in order to have it point to the source server instead of the local build folder for the source files. For some reason, ProGet is creating a PDB that Visual Studio doesn't like. Inedo and I haven't been able yet to nail down why.
In the process of debugging my WPF project, I regularly encounter thrown exceptions. When these exceptions fire, if the exception is thrown by my application's code, I am able to browse the source code. All is well.
HOWEVER, if an exception is thrown by code hosted in another assembly (that we built), I am unable to browse for the source code. I was at some point in the past prompted to browse for the original source code file, but "canceled" the dialog. Now, I want a do-over.
Is there a way to grant me a do-over on locating these source files? I'm no longer prompted for them. I assume Visual Studio stores my source code browsing preferences somewhere, but I don't know where. I get the idea this do-over is possible, but I don't even know the words to search for on Google to get what I want.
What should I do?
In the Solution Explorer right click on the solution and go to Properties → Common Properties → Debug Source Files.
Then on the right hand side there is a list for "Do not look for these source files:". Deleting the entry from that list should prompt you for the source location again.
Delete the hidden .suo file in your solution directory.
You may have to reset the visual settings. You can do this by clicking "Tools", Import Export settings.
For the default source path, make sure your PDB files are replaced correctly where Visual Studio is adding your reference DLL from. The PDB file contains the path of the source code, it's not Visual Studio.
You must rebuild your project (referenced assemblies one) and manually delete PDB files in your debugging project before adding references. It may be a bug in Visual Studio in case the files are locked or if for some reason the PDB files may not be updated.