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
Related
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.
I have a .net dll. For some reasons I have registered it for COM. I tried a lot of options to debug the code of this dll but nothing has worked. Someone please suggest a way to debug the code of COM registered .net assembly.
You'll need to debug the client, either by starting it from the debugger or by attaching to the running process. You'll need to have managed debugging enabled. You'll need to have the .pdb file accessible to the debugger (in all cases where I've done this, the .pdb file is in the same folder as the COM component).
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.
I have a DLL file. How can I view the functions in that DLL?
For native code it's probably best to use Dependency Walker. It also possible to use dumpbin command line utility that comes with Visual Studio.
Use the free DLL Export Viewer, it is very easy to use.
You may try the Object Browser in Visual Studio.
Select Edit Custom Component Set. From there, you can choose from a variety of .NET, COM or project libraries or just import external DLLs via Browse.
Use dumpbin command-line.
dumpbin /IMPORTS <path-to-file> should provide the function imported into that DLL.
dumpbin /EXPORTS <path-to-file> should provide the functions it exports.
For .NET DLLs you can use ildasm
Use dotPeek by JetBrains.
https://www.jetbrains.com/decompiler/
dotPeek is a free tool based on ReSharper. It can reliably decompile
any .NET assembly into C# or IL code.
Without telling us what language this DLL/assembly is from, we can only guess.
So how about .NET Reflector.
If a DLL is written in one of the .NET languages and if you only want to view what functions, there is a reference to this DLL in the project.
Then doubleclick the DLL in the references folder and then you will see what functions it has in the OBJECT EXPLORER window.
If you would like to view the source code of that DLL file you can use a decompiler application such as .NET reflector.
For non .NET dlls, installing binutils on a Linux system presents the objdump command that can be used to display information of a dll.
objdump --private-headers <file.dll>
Look for the Export Address Table section in the output.
.NET ildasm
ildasm helped and even dumped methods body, but to edit .DLL you also need any hex editor.
ildasm example to fix Help Viewer v2.x issue:
error: "An error occurred while updating content: File '???.cab' was not signed by Microsoft"
here could be image
more example files
Within a Visual Studio (2005/2008) Project I'd like to use an open source library. I'd like to link to the binaries so that I'm not responsible for a proper build and can check those binaries into the source control server (SVN).
So far so good, but if I'd like to debug into the open source library or want to take a look at a class implementation I would be forced to add the the source of the project into my solution and than link my project to the source instead of the binaries.
Is it possible to tell Visual Studio a location of the source of a linked binary library so that things like "go to definition" and debug is working?
Absolutely, if you have the pdb symbols its all done for you - look at MFC for example, you get the binaries yet can debug through the source.
If you don't have the symbols, then its a lot more complicated, when you debug through the code it may ask you to show it the source lines, and you'll just have to find them for it (usually the path is the same so its easy).
There are multiple ways you can achieve this.
Like gbjbaanb suggested you can use pdb symbols. It's going to work for both managed an unmanaged code.
If you're using .NET you can debug with Reflector. Oran Dennison wrote how to debug with Reflector and Visual Studio. One of my favorite tools is TestDriven.NET. Author of this tool, Jamie Cansale, also blogged about how to debug with Reflector when you have TestDriven.NET. In his article, Jamie has a link to screencast where he demonstrates how to do it step by step.
Last, if you use for your SVN client like TortoiseSVN, you can add files/directories from check in. More details how to Ignore Files and Directories with TortoiseSVN.