Debugging a third-party DLL in Visual Studio?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

.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

Answer 5

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).

Answer 6

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