Archive for February, 2006

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 🙂

Yesterday I got a question to my Email from David Douglass, a reader of this blog.
David asked me how can he see the threads waiting on a certain managed lock and that he was trying to accomplish that using WinDbg and the SOS that shipped with .NET Framework 2.0.

I told David that he should use the !SyncBlk command and that I talked about it in a previous post but never actually used it in .NET Framework 2.0. I also suggested that if he is still having problems I’ll look into it a bit more using the sample I provided in the previous post.

Before I had a chance to do anything, David replied saying that he checked this issue with Tess Ferrandez (Tess is an Escalation Engineer in the PSS (Product Support Services) at Microsoft) and that the answer he got was that the version of SOS shipped with .NET Framework 2.0 does not have the ability to show on each managed lock which threads are waiting on it like the SOS that shipped in newer version of WinDbg.

When typing !help SyncBlk in WinDbg (after load the SOS extension of .NET 2.0 of course) the help states that there is a way to verify that, but it requires a bit of disassembling.

I think I found a better way of doing that and I’ll present it here. The code is based on the sample from the post about identifying dead lock in managed code and you can download the source code from here.

The sample I use here basically deadlocks two thread which are both waiting on resources held by the other thread.

Runing !SyncBlk shows me this:

Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
12 0017a6a4 3 1 0018a1b0 efc 5 01371c38 System.Object
13 0017a6d4 3 1 00189df0 19f4 4 01371c2c System.Object
—————————–
Total 13
CCW 0
RCW 0
ComClassFactory 0
Free 1

We see here that thread “efc” is the owner of the lock on SyncBlock 01371c38 and thread “19f4” is the owner of the lock on 01371c2c.
If we want to check which lock thread “efc” is trying to acquire all we need to do is run “~~[efc]kv” (do mind that I use kv to see the arguments being passed to the methods) and we should look for the method “mscorwks!JIT_MonEnterWorker_Portable“. If I’m not mistaken (and I do hope I’m not 😉 ), the first argument (the number showing on the “Args” column) should be the SyncBlock we are trying to acquire.

So in our case, on thread “efc” we should see that the first args of is “mscorwks!JIT_MonEnterWorker_Portable” 01371c2c.

I have not contacted anyone from Microsoft to validate my claims here (yet) but I will update the post if necessary.

Just a reminder: Do mind that when you will run the sample the addresses and thread number will probably be different.

If you are stuck in a problem or have a question, feel free to Email me to eran AT sandler . co . il and I’ll do my best to supply you with an answer.

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.

Jochen was kind enough (again) to post a comment in the previous post that there are at least 3 major issues with the new version of WinDbg.

You can find some of the issues here, here and here.

It seems that all problems stem from the fact that this version was not marked as beta.

I personally didn’t have time to test the new version with some custom extensions, but the responses I’ve been seeing in the newsgroups are a bit too aggressive.

I would like to send a bit kudos to all of the WinDbg team and congratulate them on their work.
If you know (or not), WinDbg is the most used debugger within Microsoft and with such a small team they are doing a heck of a job.

There is no need to panic too much and be too blunt about it. I’m sure each and every one of the team members of WinDbg will be more than happy to address any issues that may be caused in the new beta version.

This is a product like any other product and perhaps by moving to a releases model that is similar to the CTPs of the new parts in Vista would be a bit better.

Release more and release often to a small community that will help the team test and achieve a better test matrix coverage. No need to bitch about it if each and every one of us can lend a hand/computer/head/OS or two.

I just hope some of the WinDbg team members see this post… 🙂

Jochen Kalmbach was kind enough (thanks Jochen!) to point in a comment to my previous post that release 6.6.3.5 is a BETA version of WinDbg.
He also pointed out this post in the WinDbg newsgroup that confirms this information.

Sorry for not finding this out just now, but it seems the only place that the word “beta” was written was in the “redist.txt” file in the installation folder.

It seems that some code Jochen wrote doesn’t work with the new version of DbgHelp.dll so there are a few things you should watch out in betas…
I personally like to live on the bleeding edge when it comes to WinDbg so I usually do care if a version is a beta or not. On the other hand, I can sympathize with Jochen’s frustration about using a new beta version and finding out something is broken…

Oh well… I’m sure this will get fixed very soon.

I just wish WinDbg releases were a bit more often than every 6 to 9 months.