I have third-party dll with lib files.
A.dll, A.lib, Ad.lib.
One dll, but two lib files - one for debug other for release. And headers. Is there a way to debug into this dll? I don't have source code and don't have pdb files.
PS: I'm using MS Visual Studio.
That is obvious. You cannot do that. If you want to debug into the dll, you must have the PDB file of it. And there is no other way unless you have the source code in recompile to get PDB file.
Or you could use decompilation tools to parse the dll and get the source code to realize it. But it might have some risks.
Related
I am trying to debug some issues occurring within an external library (ClosedXML). If I can work out exactly what's going wrong, I should be able to apply workarounds to the code that calls it.
I have added ClosedXML and manage it via NuGet.
Unfortunately, the debugger states that ClosedXML.PDB cannot be loaded. The checkboxes for 'Microsoft Symbol Servers' and 'NuGet.org Symbol Server' are both checked.
A suggestion was to generate my own pdb file. So, I cloned the ClosedXML repo, checked out the 0.95.4 commit (the version of the NuGet package I'm using) and built the project in Debug mode. I then directly referenced the pdbs produced in the ClosedXML binaries folder in the 'No Symbols Loaded' page in Visual Studio. Unfortunately, none of them work. They each have the same error message:
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net46\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net40\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\netstandard2.0\ClosedXML.pdb: PDB does not match image.
This isn't surprising as the DLL and the PDB weren't built on the same machine, but it is unfortunate.
So, my current workaround is to dereference the NuGet package and instead reference the DLL I've built locally. This works, but it is far from ideal.
To confirm, 'Just My Code' is disabled.
Is there any way I can debug the external code without resorting to changing references each time?
You can use my Runtime Flow tool to investigate called methods and parameters in ClosedXML without .pdb.
Are there cases when a Windows executable (written in C++ with Visual Studio) can contain its full debug symbols? Or are the full set of debugging symbols contained only in its .pdb file?
Is there a way to configure building a windows application so that we can debug it without having the .pdb file?
From the documentation for your toolchain:
The compiler's C7 Compatible (/Z7) option causes the compiler to leave the debugging information in the .obj files. You can also use the Program Database (/Zi) compiler option to store the debugging information in a PDB for the .obj file. The linker looks for the object's PDB first in the absolute path written in the .obj file, and then in the directory that contains the .obj file. You cannot specify an object's PDB file name or location to the linker.
It is not possible to create an .exe or .dll that contains debug information. Debug information is always placed in a .obj or .pdb file.
This doesn't rule out debug information placed into a section of an EXE file by other tools... but Microsoft Visual Studio's C++ tools never do.
For information on placing debug information into OBJ files (possibly contained inside LIB static libraries) instead of a PDB, read the documentation on the compiler option for Debug Information Format
I've included a NuGet package (Edge.js) that I would like to debug by stepping into the source code. When I "step in" it "steps over". I'm guessing this is because there are no symbol file to step in to. Possibly the EdgeJS package was published without sources and this could be the reason. However I don't know how to verify if a NuGet package contains the pdb symbols.
It might also be that I failed configuration of Visual Studio but because I don't know if the NuGet package contains symbols I don't know which way to look.
Thanks for any help
Nuget supports creating packages that contain PDB and source files with the nuget pack -Symbols command. Usually, these packages are uploaded to symbolsource.org for open source projects. Visual Studio can be configured to use symbolsource.org during debugging, see this guide.
However, not every open source project uploads symbol packages to symbolsource.org, so you have to check whether Edge.js does (I don't know that library).
If Edge.js does not provide symbol packages, your options are as follows:
Download the edge.js sources and build locally with debug symbols. Copy the DLL and the PDB to the output folder of your application and start debugging.
Use a decompiler. You don't get as much information as with the debug symbols and source files, but it may suffice for your case. The decompiler that ships with Resharper (commercial tool) is pretty useful for debugging DLLs in this manner.
You can't "step-into" anything if you don't have the source code. Debug symbols won't help in this case.
You can step-into the decompiled code only by using third-party tools like RedGate's Reflector or Telerik's JustCode that decompile the IL on the fly and generate C# code for viewing purposes. These tools don't need the debug symbols to work, although they can use them to make the decompiled code more presentable.
The solution consists of 3 projects:
C# application which depends on...
CLR C++ library which in turn depends on...
C++ library
I can debug first two, but not the last one ("No symbols have been loaded for this document"). I am in debug mode (all 3), pdb files were created.
The pdb files for both C++ libraries are created in solution\debug directory. .pdb file for CLR library is also copied to bin\debug directory of the C# project, but not .pdb for the last one. So I copied it there manually, but it didn't help.
So how to debug library which is dependency of the dependency?
I restarted VS, as well as computer, I rebuilt solution too.
I'm having problems with a dll that I downloaded from somewhere. How can I look inside the dll to debug it?
You don't say, but if it's a .NET assembly dll you could use the disassembly tool in Reflector to view reversed source code.
If it doesn't have debug information then it's no use (usually DLLs are shipped in the "Release" version - which usually means that Debug information is not available). In order to actually debug you must also have the sources.
You can use a program like DLL Export Viewer to view DLL files.
But as lulian pointed out you can not debug it, unless you have sources or pdb file...
If it is a managed dll you can debug it with .NET Reflector Even without the symbols and without the source code. There you can
Decompile third-party assemblies from within VS
Step through decompiled assemblies and use all the debugging techniques
you would use on your own code