19

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?

Community
  • 1
  • 1
Biswanath
  • 9,075
  • 12
  • 44
  • 58
  • 1
    Yeah, extract the code into files, add them to a dll project and recompile the dll. Add this project to your solution and change the references to point to that project. Then you should be able to debug it. – Andrew Rollings Dec 08 '08 at 17:28
  • I have a similar problem. All the sources belong to me, but I can't just go adding them to the referencing project. There are more than 20 projects involved... And none of the solutions below really help – TimothyP Dec 14 '09 at 05:54

8 Answers8

17

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Andrew Rollings
  • 14,340
  • 7
  • 51
  • 50
  • It is .Net dll and I have a reflector, let me try doing this. Thanks. – Biswanath Dec 08 '08 at 15:55
  • 2
    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. – Jeeva Subburaj Oct 29 '09 at 18:22
6

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!
Brian Lyttle
  • 14,558
  • 15
  • 68
  • 104
  • 3
    +1 for raising the awareness of the possibility of breaking laws or breaching licensing agreements – JeffH Apr 21 '09 at 16:05
4

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).
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Robert Gowland
  • 7,677
  • 6
  • 40
  • 58
3

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

Shkredov S.
  • 2,097
  • 16
  • 8
3

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.

Community
  • 1
  • 1
Steve Severance
  • 6,611
  • 1
  • 33
  • 44
  • I think this solution might be overkill for the OP's question BUT that's really beneficial for hardcore errors like memory leaks, random crashes in IIS etc.. nice answer anyways, only a few of us use this in these days lol – yakya Oct 16 '16 at 20:13
1

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

Community
  • 1
  • 1
alan
  • 76
  • 1
  • 4
0

.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

Jeeva Subburaj
  • 1,881
  • 2
  • 18
  • 26
0

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
dr. evil
  • 26,944
  • 33
  • 131
  • 201