Amazing helper .cmdtree

In Roberto Farah's most recent post he mentions the command .cmdtree which is available since version 6.6.7.5.
The result looks amazing and makes debugging with windbg a lot more productive and it makes it much more useful for especially for newbies:

I've put the text file proposed by Roberto on my public share for your (and my) convenience and added some stuff, that I found to be useful...
Currently I don't know how to put comments into this file format.
If anyone can tell me I would like to add a tribute notice into the text.

PS: Unfortunately I was not able to set the command .cmdtree CMDTREE.TXT as initial command via -c switch in  [HKEY_CLASSES_ROOT\WinDbg.DumpFile.1\shell\Open\command]. For some reasons windbg doesn't find the file via startup command. Any advice on how to achieve this is welcome.

Interview with Mario Hewardt and Daniel Pravat on Channel9

The authors of the excellent book Advanced Windows Debugging Mario Hewardt and Daniel Pravat are talking about debugging windows and the drivers to write the book on Channel9.

The book is great and should be in the book shelf of every windows developer, because it describes a structured way of doing common windows debugging tasks. As the authors state, an important reason for writing this book was the fact, that there was no such resource available.

There's a lot talking about debugging threading issues which is sometimes really hard stuff. Looking at the fact that modern computers have more and more cores, writing, understanding and debugging multithreaded code will become more and more important.

One might argue that in times of managed code unmanaged debugging is out of date. Mario and Daniel explain in this interview that understanding the details behind the scenes is essential for doing efficient debugging. You have to understand the basics on how the CLR works and the CLR is written in unmanaged code.

(If you interesting in more debugging of managed code I strongly recommend Debugging Microsoft .NET 2.0 Applications by John Robbins)

At the end of the interview they do a little live debugging on a program producing resource leaks... nice.
(I've been looking into code analysis tools in the last couple of weeks and I bet the resource leak would have been found by some of those tools without running the program a single time. But it's just for demo and the best code analysis tools will leave enough bugs in your code that will push you in front of the debugger)