views:

3746

answers:

6

Hi,

I am using a third party dll. For some particular cases the a function in dll is throwing an exception.

I want to know whether it is possible to debug the dll in the visual studio ?

Update

After the answer from Andrew Rollings , I am able to view the code, but I is there any easy way to debug through the code in visual studio.

Thanks, Biswanath.

+6  A: 

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.

Andrew Rollings
It is .Net dll and I have a reflector, let me try doing this. Thanks.
Biswanath
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 S
+2  A: 

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!
BrianLy
+1 for raising the awareness of the possibility of breaking laws or breaching licensing agreements
JeffH
A: 

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

Give it try to reflector debugger, it might help you a lot.

dr. evil
+1  A: 

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 VS then accessing the DLL through a different project in VS (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 VS.
  • You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When running the calling project in VS, 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 you the icon for the break point 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 VS 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 VS debugger into a running process.

  • Open the DLL project in VS.
  • Run an application that uses the DLL (this application can't be run from another instance of VS 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 VS (although the break point will appear disabled the same as in method 1).
Robert Gowland
+1  A: 

Something that has worked for me with debugging a couple of third party libraries as well as .net iteself 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 extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assumbly/il 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.

Steve
A: 

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