[ACCEPTED]-Debugging a third-party DLL in Visual Studio?-dll

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

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

Building on Andrew's answer, you just treat 5 the decompiled source code as a new library 4 within your project and set breakpoints 3 in the source. Remove all references to 2 the 3rd party DLL so that it is the decompiled 1 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!

There are two methods I've come across:

1) Accessing the DLL project from the using project. This 7 involves building the DLL in a separate 6 instance of Visual Studio and then accessing 5 the DLL through a different project in Visual 4 Studio (this assumes you have the source 3 code). There a number of ways to accomplish 2 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 1 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).

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

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

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

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

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

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

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

Have 6 a look at this blog post:

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

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

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