Debugging a third-party DLL in Visual Studio?

问题:

I am using a third-party DLL. For some particular cases, a function in the DLL is throwing an exception. Is it possible to debug the DLL in the Visual Studio?

After the answer from Andrew Rollings, I am able to view the code, but is there any easy way to debug through the code in Visual Studio?

回答1:

If the DLL is in a .NET language, you can decompile it using a tool like .NET Reflector and then debug against the source code.

Or you could ask the vendor if source code is available. That's probably the easiest way.

回答2:

Building on Andrew's answer, you just treat the decompiled source code as a new library within your project and set breakpoints in the source. Remove all references to the 3rd party DLL so that it is the decompiled code that is executing.

Other things:

• You may be breaking the law by decompiling the code, or breaching a licensing agreement with the 3rd party vendor. Make sure to review this with someone.
• You will want to make sure that you remove references to your decompiled version if you are shipping to other developers, or checking into a larger source tree. Easy to forget this!

回答3:

There are two methods I've come across:

1) Accessing the DLL project from the using project. This involves building the DLL in a separate instance of Visual Studio and then accessing the DLL through a different project in Visual Studio (this assumes you have the source code). There a number of ways to accomplish this:

• You can add Trace.WriteLine statements in the DLL that will show up in the 'Output' window in Visual Studio.
• You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When running the calling project in Visual Studio, program execution will stop there. From here you can add access the call stack (including all function calls in DLL itself) and set break points (although the icon for the breakpoint will appear disabled and the hover text for the break point will read "The breakpoint will not currently be hit. No symbols have been loaded for this document").
• If the DLL is throwing an exception (which you can see from the 'Output' window if the exception is caught and handled by the DLL) you can tell Visual Studio to always break when that type of exception is thrown. Hit Ctrl + Alt + E, find the type of exception being thrown, and click the 'Throw' column for that exception. From here it is exactly as if you had used System.Diagnostics.Debugger.Break() (see above).

2) Attaching a using process to the DLL project. This involved hooking the Visual Studio debugger into a running process.

• Open the DLL project in Visual Studio.
• Run an application that uses the DLL (this application can't be run from another instance of Visual Studio since the process will already have a debugger attached to it).
• From here you can add break points and step through the DLL code loaded in Visual Studio (although the break point will appear disabled the same as in method 1).

回答4:

Something that has worked for me with debugging a couple of third-party libraries as well as .NET itself is WinDbg. It is an awesome debugger from Microsoft that I have used to troubleshoot some sticky problems that were occuring deep inside the framework.

You need to use the Son of Strike (SOS) extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assembly/CIL instructions to be good at using it. You should be able to determine the exception and what is causing it. We have used WinDbg/SOS to find for instance that in HttpWebResponse, if you are using Gzip compression to download a page and the server returns a bad Gzip header, .NET runs the decompression in the threadpool and a crash will take out your process. Happy debugging.

回答5:

As Cesar Reyes mentioned in Stack Overflow question Visual Studio - Attach source code to reference, ReSharper 5 (and later) has this capability.

回答6:

.NET Reflector 6 comes with a Visual Studio Addin that lets you use Visual Studio's step-through-debugging on assemblies that you don't have the source code for.

Have a look at this blog post:

http://www.simple-talk.com/community/blogs/alex/archive/2009/09/22/74919.aspx for more details.

This is still a very early build. So no guarantee that it'll work, and it might break your visual studio configuration or project configuration. Make sure you have backups (or source control) for any projects you use this on.

Download here: http://www.red-gate.com/MessageBoard/viewforum.php?f=109

回答7:

I thought .NET Reflector got some debugging plugins. That'd be a so much better idea because decompiling and recompiling code generally fails, and you need to do so many changes in the code to fix it.

Give .NET Reflector debugger a try. It might help you a lot.

回答8:

One more option we should mention here is dotPeek 1.2 (a free decompiler from creators of ReSharper). Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program