For a bit nicer interface than MDbg or cordbg 12 take a look at DbgCLR - a cut-down version 11 of the Visual Studio debugger (at least 10 it looks like one) that handles only managed 9 code. It comes with the .NET Framework 8 (I'm not sure if it's in the runtime or 7 if you need the Framework SDK):

• http://msdn.microsoft.com/en-us/library/7zxbks7z(VS.85).aspx

Note that 6 cordbg is deprecated in favor of MDbg (even 5 though MDbg doesn't have all of cordbg's 4 features):

• http://blogs.msdn.com/jmstall/archive/2005/11/07/views_on_cordbg_and_mdbg.aspx

And in looking back at MDbg whle 3 writing this post, I found that there's 2 a GUI wrapper available for MDbg (which 1 I haven't tried):

• http://blogs.msdn.com/jmstall/archive/2005/02/04/367506.aspx

Use dnSpy.

dnSpy is a debugger and .NET assembly 7 editor. You can use it to edit and debug 6 assemblies even if you don't have any source 5 code available.

It's so wonderful. Very small 4 and lightweight. No installation or configuration 3 needed. Its interface is exactly like Visual 2 Studio. Even its shortcuts are the same 1 as VS.

Features:

Debugger

• Debug .NET Framework, .NET Core and Unity game assemblies, no source code required
• Set breakpoints and step into any assembly
• Locals, watch, autos windows
• Variables windows supports saving variables (eg. decrypted byte arrays) to disk or view them in the hex editor (memory window)
• Object IDs
• Multiple processes can be debugged at the same time
• Break on module load
• Tracepoints and conditional breakpoints
• Export/import breakpoints and tracepoints
• Call stack, threads, modules, processes windows
• Break on thrown exceptions (1st chance)
• Variables windows support evaluating C# / Visual Basic expressions
• Dynamic modules can be debugged (but not dynamic methods due to CLR limitations)
• Output window logs various debugging events, and it shows timestamps by default :)
• Assemblies that decrypt themselves at runtime can be debugged, dnSpy will use the in-memory image. You can also force dnSpy to always use in-memory images instead of disk files.
• Public API, you can write an extension or use the C# Interactive window to control the debugger

Assembly Editor

• All metadata can be edited
• Edit methods and classes in C# or Visual Basic with IntelliSense, no source code required
• Add new methods, classes or members in C# or Visual Basic
• IL editor for low level IL method body editing
• Low level metadata tables can be edited. This uses the hex editor internally.

Hex Editor

• Click on an address in the decompiled code to go to its IL code in the hex editor
• Reverse of above, press F12 in an IL body in the hex editor to go to the decompiled code or other high level representation of the bits. It's great to find out which statement a patch modified.
• Highlights .NET metadata structures and PE structures
• Tooltips shows more info about the selected .NET metadata / PE field
• Go to position, file, RVA
• Go to .NET metadata token, method body, #Blob / #Strings / #US heap offset or #GUID heap index
• Follow references (Ctrl+F12)

Other

• BAML decompiler
• Blue, light and dark themes (and a dark high contrast theme)
• Bookmarks
• C# Interactive window can be used to script dnSpy
• Search assemblies for classes, methods, strings etc
• Analyze class and method usage, find callers etc
• Multiple tabs and tab groups
• References are highlighted, use Tab / Shift+Tab to move to next reference
• Go to entry point and module initializer commands
• Go to metadata token or metadata row commands
• Code tooltips (C# and Visual Basic)
• Export to project

I've finally found extensions for Windbg 6 that do just what I wanted: Sosex.dll, lets me use 5 windbg to debug managed applications with 4 very minimal installation required. I've 3 used it for more than a year now, and It's 2 worked, without fault, for every debugging 1 scenario I've encountered.

There is always mdbg and cordbg, but I would suggest 6 digging more into why remote debugging doesn't 5 work consistently.

VS2005/8 seem a lot more 4 reliable than earlier versions here (though 3 I primarily do unmanaged) and it saves you 2 from having to have the symbols accessible 1 on the target machine.

Version 2 of ILSpy contains a debugger. And it 3 works awesome!

It is still in very early 2 stages, but have helped me several times.

Just 1 watch out for bugs! :)

You could check out MDbg: http://blogs.msdn.com/jmstall/archive/2006/11/22/mdbg-sample-2-1.aspx. It looks like 5 it comes with the .NET 3.5 SDK at least 4 (and it's probably included with 2.0+).

Windbg 3 has managed extensions (called SOS I believe), though 2 I don't know if they allow source-level 1 debugging.

Have your tried using Cracked.NET ?

It's a runtime debugging 3 and scripting tool that gives you access 2 to the internals of any .NET desktop application 1 running on your computer.

Maybe you can try using Live Tuning combined with an 10 Ocf Server?

It's not a debugger per-se, but it's pretty 9 easy to get a connection between an app 8 and Live Tuning. Like, literally 3 lines 7 of code. Then you have access to all the 6 variables you choose to publish.

I found 5 it useful when trying to debug my programs 4 without having access to the decompiled 3 code or a real debugger. You can't really 2 have breakpoints but it turns out there's 1 sometimes better ways to debug.