IL level code debugger

Question

Hi,

Is there any IL level debugger in form of a VS plugin or standalone application?

Visual studio’s debugger is great, but it allows you to debug on either HLL code level or asselbly language, you can’t debug IL. It seems that in some situations it would be useful to have an opportunity to debug at IL level.

In particular it might be helpful when debugging a problem in the code that you don't have the source of.

It is arguable if it is actually useful to debug IL when you don't have the source, but anyway.

Answer 1

Does this help?

http://debug-companion.com/DebugCompanion.aspx

http://postsharp.blogspot.com/index.html

Answer 2

The best way to do this is to use ILDASM to disassemble the managed binary, which will generate the IL instructions. Then recompile that IL source code using ILASM, when you fire up the Visual Studio debugger you will be able to step through the raw IL.

1. ildasm foo.exe /OUT=foo.exe.il /SOURCE
2. ilasm foo.exe.il /DEBUG

I've written a blog post about this topic at: How to debug Compiler Generated code.

Answer 3

ISTR there's a debugger plug-in for Reflector.

Not used it myself, though I have used TestDriven.net to debug a 3rd-party assembly with the aid of Reflector:

http://weblogs.asp.net/nunitaddin/archive/2006/11/05/Debug-With-Reflector.aspx

Answer 4

Here is an article about IL debugging. It says you can't do it and then talks about ways to do it. There is also some info in the comments about doing it also.

Answer 5

Debug Companion VS plugin seem to be exactly what I was looking for, except that it won't see library project in my solution. Only when I added a console win application to the solution did something appear in that list of projects.

The problem with the decompile/compile approach for me was that the code I was debugging wasn't my code. I could have decompiled it anyway but I think there's no way to sign that recompiled assembly so that it gets loaded instead of the original one.

With the particular problem I had it turned out that it was enough to just debug it on the assembly language level and get the call stack of the method which was throwing the exception and the parameters with which the method was called.