[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.
- 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.WriteLinestatements 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
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
More Related questions