I know I haven’t been posting much lately, but I’m a bit caught up in a startup I’m involved in called Yedda. It has taken most of my time, but I do find, once in a while, something to post like the “Ambiguous match found” problem, so bear with me 🙂

Today, I’ll give a small tip for !clrstack.

If you use !clrstack to show a managed call stack and you want to see the addresses of parameters that were passed to the functions without doing a lot of fancy shmancy WinDbg tricks simply run:

!clrstack -p

That’s all you need to do. This will list each function in the call stack and below it the name of the parameter and its address. From there on, you can use !do ( !do == !dumpobject – which shows a managed object) and see the content of the object.

Quite simple and very effective.

As a general rule of thumb, most SOS command have a very descriptive help. To use it, simply run:

!help <command>

i.e.

!help !clrstack

I’ve found this interesting post on Mike Stall’s blog.

Felice Pollano is working on merging MDbg (I’ve talked about it before here) with Reflector (the .NET disassembler) so one can debug application without having debug symbols and still be able to get a bit more information than just IL code (you’ll be able to choose the language that will be displayed while debugging)

This is definitely something that I will keep on tracking since it can provide a bridge between hard core WinDbg debugging, soft core MDbg debugging and Visual Studio debugging.

Disclaimer: I usually like to keep this blog clean of link posts (posts that only have links to other posts in other blogs), but this time the information was too valuable so I had to make an exception.
Although this information is not exactly pure .NET debugging, it does have some information that can actually save you debugging time 🙂

Tess has some interesting tips that she expanded from a post her colleague Doug wrote about:

Read, learn and implement where needed.

I usualy try to stay away from posts that have only links to other blog posts but, Tess has a great post about various issues causing .NET memory leaks.
I’ve talked about these issues before here and here and here.

It’s nice to see that others from Microsoft are sharing their knowledge and expertise on the subject of debugging with the rest of the world (specifically, when it comes to production debugging, hard .NET debugging problems and WinDbg 🙂 ).

Enjoy!

There is a new broadcast episode on MSDN TV titled “Introduction to the CLR Managed Debugger“.
It features Jan Stranik, the guy who wrote MDbg and he shows examples, as well as talk about the API and have a few insights as two the problems and solutions he encountered while writing MDbg.

I talked about MDbg briefly here and even used it to create an small tool to capture and log all exceptions being thrown in the process (even swallowed one) which I titled ExceptionDbg.
Its available in both binary and source code and is a nice tool to see all of the exceptions being thrown and caught. It’s also a good reference to implement your own cutomized debuggers and applications based on MDbg.

If you want some more information about MDbg go here, to Mike Stall’s blog.

I wanted to notify the Israeli audience of this blog that I’ll be giving a lecture titled “Production and Post Mortem Debugging in .NET using WinDbg” on the Israeli Visual Basic User Group (IVBUG) led by Jackie Goldstein.

This is mainly an overview lecture that will include an introduction to production and post mortem debugging using .NET, some talk about .NET internals, so we will know what we are looking at in WinDbg and some proven methodologies for common issues in production environment that can be easily found, traced, identified and debugging using only WinDbg.

The lecture will take place on March 1st, 2006 at 18:00 at

Microsoft Israel
2 Hapnina St.
Ra’anana
Floor 0, Dekel Room

You’ll need to confirm your attendance by Emailing to IVBUG AT renaissance.co.il (replace AT with @ sign).

Hope to see you there!

Francisco Martinez has some interesting tools that he developed to make it a bit easier to develop to .NET application to Mono using Visual Studio .NET.

These tools allow you to create a makefile from a Visual Studio project file enabling you to build the project in a complete Mono environment as well as import and export MonoDevelop project files from and into Visual Studio Project files.
It will also enable you to run your compiled code under Mono instead of the Microsoft .NET Runtime directly from the Visual Studio IDE.

I’ve been following the Mono project since its inception and it has come a long way since.

I know there are (and are going to be) a lot of legal issues that can do a lot of problems in regards to the project, but I still think its a necessary and welcome addition to the development platforms available on the different Linux flavors and UN*X operating systems.

I wonder if someone is planning to write a WinDbg extension to handle Mono 😉
Though I’m not sure there will be a lot of market for it. People will probably use the Microsoft .NET Runtime for Windows development and/or deployment and Mono for a Non Windows development / Deployment.

I guess only time will tell 🙂

Everyone else probably wrote about it, so I thought I should write about it too 🙂

Dimitri from Microsoft released an RSS Toolkit for .NET that can be used to consume as well as generate RSS feeds.
You can read more about it in this post on his blog.

Dimitri is the development manager for ASP.NET and a great guy in general.

He actually made this hotfix for a company I used to work for (it was later integrated to one of the service packs of .NET framework v1.1, and I think its also included in .NET 2.0).

The whole ASP.NET threading model and how it works with Single Threaded Apartment (STA) COM objects is a good material for another post, so stay tuned 😉

According to this post in Jochen Kalmach’s blog, the new (beta) version of WinDbg – 6.6.3.5 that I’ve mentioned earlier in a couple of posts support mini real dumps.

This means that instead of taking a full memory dump (its not actually full because you don’t take the kernel space) which can be up to the size of the current process (and in server applications it can reach to a few hundreds of MB), you can take a small, light weight mini dump that contains only minimal information such as call stacks.

This previously worked in unmanaged environments but from this version it also works on managed and mixed environments.

I’m still trying to find the original source of this information (Jochen, can you help on this? 🙂 ), but after tracking Jochen’s blog for a while he does know what he is doing.

A new version of WinDbg (version 6.6.3.5) was released a couple of days ago.
Download it from here.

You can read some of the highlights of the new version here.

For some reason, the only SOS.dll that comes with this release (as in previous releases) is for .NET Framework 1.1 only, so there is no new SOS.dll for .NET Framework 2.0 yet.