As of late, with all of the .NET programming that I have been doing I have found myself trying to find ways to debug within this new environment using non .net tools (common debuggers and the such).

Why use non .NET debugging tools you ask, well one reason is that there is no way to debug PerlNet utilization within a .NET environment and another reason is because I am of the type that likes to know exactly how everything works and then how to perform the sames tasks by hand (which is why I developed a linux version of SoftIce for Transmeta processors while I worked there along with the means to create a DUMP file of a Windows System while windows is running and without disturbing that state of the system -- both programs I plan on porting to an OS x86 version sometine within the near future).

With that said, I was wondering if anyone else is as crazy as I am and thusly have already started to look into such things and if so perhaps you would like to not only share notes but work on some projects together (one goal of my is to map out the entire process of loading, executing and ending of a .NET application).  To reach such a goal I have already started digging through the book Expert .NET 2.0 IL Assembler and plan on picking up the book Compiling for the .NET Common Language Runtime(CLR) by John Gough.

What good will come of all of this?  For one, the ability to better understand and debug a system issue that involves a .NET application either with or without the use of .NET tools; along with expanding ones knowledge of exactly how this .NET stuff fits into the overall OS picture.

Posted on 2007-11-03 13:56:23 by madprgmr
Humm, I think debugging JITted code approaches lunacy :), and you should work at the "source" level - ie, MSIL representation. Should be easier to follow the code sequences that way.

But it could be a decent idea to write a debugger that actually deals with MSIL, instead of the current high-level debuggers.
Posted on 2007-11-04 14:53:38 by f0dder