I have a web project that posts from client-side code to a method in external dll, which I have source code file and pdb file of this external dll. What I would like to do is to debug external dll using source code file and pdb. Visual studio does not stop to say no symbols are loaded for the module since.
To debug a a symbol file with the same version is always needed. When you are debugging your own applications you usually don't have to care about this.
But there are things happening in the background. Visual Studio always puts the symbol files in the debug folder when you build your application and also loads them as described under Loading the symbols automatic.
(When you distribute your application you usually do not want to distribute those symbols and therefore they won't be copied to the release directory you change your build configuration to release.)
Loading the symbols manually
If you want to load the symbols manually you can load them with the Modules dialog.
"Debug" -> "Windows" -> "Modules".
You can right click a row and there is the option "Load Symbols" which lets you specify a PDB file to load.
Loading the symbols automatically
Visual studio also loads the symbols automatically when they can be found in one of the the places listed in the Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger documentation:
The location that is specified inside the DLL or the executable file.
(By default, if you have built a DLL or an executable file on your computer, the linker places the full path and file name of the associated .pdb file inside the DLL or the executable file. The debugger first checks to see if the symbol file exists in the location that is specified inside the DLL or the executable file. This is helpful, because you always have symbols available for code that you have compiled on your computer.)
.pdb files that could be present in the same folder as the DLL or executable file.
Any local symbol cache folders.
Any network, internet, or local symbol servers and locations that are specified on, such as the Microsoft symbol server if enabled.
If you want to read more about how the symbols are used with visual studio you can read this article about Understanding symbol files and Visual Studio’s symbol settings.
Related
Consider the following code:
private static void Main(string[] args)
{
var exe = new MemoryStream(File.ReadAllBytes(args[0]));
var assembly = AssemblyLoadContext.Default.LoadFromStream(exe);
assembly.EntryPoint.Invoke(null, new object[] { new string[0] });
}
This program was compiled in a .net core 1.1 application, and args contains the path to the dll of a generic hello world in .net core in it's debug output directory.
When I run this program, it loads the assembly from an in-memory copy of the dll and then calls the entry point. Visual Studio seems to successfully recognise that this dll is the same as the hello world project I have open in the solution and I can step through and debug this invoked program.
How does the VS Debugger know where to find the source when I loaded from an in-memory copy of the assembly?
First it locates the .pdb and then from there it can locate the source files.
How does it locate the .pdb? From Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger:
When you debug a project in the Visual Studio IDE, the debugger knows the default location for the .pdb and source files for your code.
...
(By default, if you have built a DLL or an executable file on your computer, the linker places the full path and file name of the associated .pdb file inside the DLL or the executable file. The debugger first checks to see if the symbol file exists in the location that is specified inside the DLL or the executable file. This is helpful, because you always have symbols available for code that you have compiled on your computer.)
There are other locations where it will also search for .pdbs but this one seems like the most likely source when you've tried to dissociate the assembly from its file on disk.
The answer is in this MSD page:
To use the full features of the Visual Studio debugger (like hitting
breakpoints) when attaching to a process, the executable must exactly
match your local source and symbols (that is, the debugger must be
able to load the correct symbol (.pbd) files). By default, this
requires a debug build.
Also,
A program database (.pdb) file, also called a symbol file, maps the
identifiers that you create in source files for classes, methods, and
other code to the identifiers that are used in the compiled
executables of your project. The .pdb file also maps the statements in
the source code to the execution instructions in the executables. The
debugger uses this information to determine two key pieces of
information: the source file and line number that are displayed in the
Visual Studio IDE and the location in the executable to stop at when
you set a breakpoint. A symbol file also contains the original
location of the source files, and optionally, the location of a source
server where the source files can be retrieved from.
Where the debugger searches for .pdb files
The location that is specified inside the DLL or the executable
file.
.pdb files that could be present in the same folder as the DLL
or executable file.
Any local symbol cache folders.
Any network,internet, or local symbol servers and locations that are specified on, such as the Microsoft symbol server if enabled.
What is the best/correct way of attaching an external project source code so I can debug it?
I´ve already downloaded the source code of it from CodePlex, so I have all the .cs classes.
I´ve managed to import from a pdb file, but unfortunately, there´s no such file in this project codeplex (SimpleInjector).
After importing the SimpleInjector solution on VS, I could build it and generate the .pdb files, but I wonder whether it is the right way.
If your goal is to step-through debug the binary, then you will need the PDB files. In general, the compiled assembly just doesn't contain the information needed to associate source-code lines with individual IL commands.
The PDB file is a "program database file" which contains lots of useful debugging information; one of those things is the mappings between each compiled IL instruction and the source-code line that generate it. It also keeps a symbol table that lists the names of things that otherwise get compiled out (like local variable names, etc.) The PDB embeds the full path name of each source file, so if your source code is in the same place when you debug as it was when you compiled, the debugger will automatically find it.
If the .pdb file is present but the source code has moved, VS will give you the option to browse to the .cs file. But, if the .pdb file isn't present at all, your options will be rather limited.
The only risk you have is that you are debugging a program that doesn't match your PDB files. Therefore, if you are doing to try to debug the project, you should rebuild, from scratch, in Visual Studio and run that version of the binary.
(Debugging without symbols and source loaded into Studio is, of course, possible, but it's a much harder skill to master.)
When doing a "Debug" Build in Visual Studio it outputs a pdb file so that you get detailed information when an exception occurs.
Is the information in the pdb files actually loaded when the executable is run or later at the moment when the exception occurs?
Decompilers such as IDA load symbol files when it analyses your executable, or when you tell it to load specific symbols with your executable, as long as it matches the executable currently being debugged.
Debuggers such as the Visual Studio debugger load PDB files and symbols as soon as it starts debugging, not when an exception occurs.
The MSDN page on PDB files further underlines this:
The Visual Studio debugger uses the project.PDB file created by the
linker directly and embeds the absolute path to the PDB in the EXE or
DLL file. If the debugger cannot find the PDB file at that location or
if the path is invalid (for example, if the project was moved to
another computer), the debugger searches the path containing the EXE,
the Symbol Path specified in the solution's Property Pages (Common
Properties folder, Debug Symbol Files page). The debugger will not
load a PDB that does not match the binary being debugged.
Of course, is a program is compiled without /debug, the path to the PDB file won't be included in the resulting exe or DLL.
Yes, they are loaded outside of VS. If your code crashes while loaded with the PDB's you'll see source code location and line numbers.
I have compiled a Debug-Version of my application in one folder. There are now all dll's, pdb's and the exe with the pdb.
I have now created a MiniDump of my running application started out of this path with Taskmanager. Now, I can open this dmp-File in Visual Studio 2010. But when I try to debug, there will be a message, that the symbols could not be found. I have added the path to my symbols (pdb) to the symbol-paths in visual studio - but with no success. I have also try to load the symbols over the ContextMenu of the modules. It is searching there for MyApp.pdb and I have selected the correct pdb. But I get the message A matching symbol file was not found in this folder.
What can I do to make post mortem debug of my MiniDump with Visual Studio 2010 (so it will find my symbols)?
Do your pdb's and dll's have the same timestamp? Are they both recreated when you rebuild?
Try using chkmatch to ensure your dll and pdb match.
Use chkmatch this way:
chkmatch -c MyApp.exe MyApp.dll
The output should look something like this
Debug information file:
Format: PDB 7.00
Signature: {ef4bc52f-0161-4e0a-8654-cc1368d7a8a6} Age: 1
Result: Matched
You shouldnt need to set the symbol path if your pdb's are in the same location as the exe you are dumping.
Are you on .NET 4?
What is a PDB file and how can I exclude it from the release folder when I rebuild my solution?
A PDB file contains information for the debugger to work with. There's less information in a Release build than in a Debug build anyway. But if you want it to not be generated at all, go to your project's Build properties, select the Release configuration, click on "Advanced..." and under "Debug Info" pick "None".
I had originally asked myself the question "Do I need a PDB file deployed to my customer's machine?", and after reading this post, decided to exclude the file.
Everything worked fine, until today, when I was trying to figure out why a message box containing an Exception.StackTrace was missing the file and line number information - necessary for troubleshooting the exception. I re-read this post and found the key nugget of information: that although the PDB is not necessary for the app to run, it is necessary for the file and line numbers to be present in the StackTrace string. I included the PDB file in the executable folder and now all is fine.
PDB is an abbreviation for Program-Debug Data Base. As the name suggests, it is a repository (persistent storage such as databases) to maintain information required to run your program in debug mode. It contains several vital information required for code debugging e.g. at what points you have put break points where you expect the debugger to break in Visual Studio (VS).
This is the reason why Visual Studio fails to hit the break points if you remove PDB files from the debug directory. Visual Studio debugger is capable of telling you the exact line number of code file at which any exception occurred along with its stacktrace. It is able to do so with the help of PDB files only. Thus PDB files are very helpful for debugging purposes.
In general, it is not recommended to exclude the generation of PDB files during build process. From production release stand-point, what you should be doing is create the PDB files but don't ship them to customer site in product installer. Preserve all the generated PDB files on a symbol server from where it can be used/referenced in future if required.
It is specially important in scenario where you debug process crash issues. While analysing the crash dump files, Visual Studio will not be able to make out the exact line of code where program is crashing if the original PDB files created during the build process were not preserved.
If you still want to disable generation of PDB files then follow below steps:
Go to properties window of the project. To open properties window, select the project file in solution explorer and press Alt + Enter.
Go to Build tab
Click Advanced
Choose none from Debug Info drop-down box
Press OK as shown in the snapshot below:
Note: This setting will have to be done separately for Debug and Release build configurations.
A PDB file contains information used by the debugger. It is not required to run your application and it does not need to be included in your released version.
You can disable pdb files from being created in Visual Studio. If you are building from the command line or a script then omit the /Debug switch.
Program Debug Database file (pdb) is a file format by Microsoft for storing debugging information.
When you build a project using Visual Studio or command prompt the compiler creates these symbol files.
Check Microsoft Docs