WinDbg .cmdtree

Wait wait, before you leave this page because it contains the “WinDbg” word somewhere in its body 🙂

This is a little gem I have just discovered, and that may be useful for those of you who do not remember the exact syntax of each and every WinDbg instruction (and I’m the first on this list).

You can prepare a text file which contains a list of the commands you use more often. This file should of course adhere to a specific syntax, which is extremely easy BTW. Here’s an example:

windbg ANSI Command Tree 1.0
title {"WinDbg made easy?"}
{"Quick Commands"}
  {"Load sos"} {".loadby sos mscorwks"}
  {"clrstack"} {"!clrstack"}
  {"Threads"} {"!threads"}
  {"Stack Objects"} {"!dso"}
  {"Exceptions"} {"!dae"}
  {"Heap"} {"!dumpheap"}

Then you just have to save this file somewhere (if you prefer to avoid too much typing, just save it along with the WinDbg executable, which in my case is here: C:\Program Files\Debugging Tools for Windows (x64), and call it commands.txt).

Then, fire up your favorite debugger (no, it’s not Visual Studio… come on!!) and within a debugging session just try typing:

.cmdtree commands.txt

You’ll see a wonderful window popping up, which contains the list of commands you have defined in your configuration file.


And this is not just for documentation or for reference: you can double click on any of the above commands and have WinDbg run it, just the same as if you had typed it into the command window directly.

Cool, isn’t it?

You can get more information here:

European Best Practices SharePoint Conference 2011

European Best Practices SharePoint Conference 2011 – London – April 11-13, 2011

Best Practices is about doing things the right way: the most efficient, effective ways to achieve goals, distilled into adaptable, repeatable procedures you can use

  • sort through the best solutions to any task
  • reach consistent, confident decisions at every level
  • break the cycle of avoidance, disagreement and subpar results
  • eliminate design, deployment, organizational and administrative confusion
  • enhance communication, collaboration and efficiency while lowering costs
  • avoid technology errors, misconceptions and pitfalls
  • leverage the hard-won experience of industry leaders
  • gain early competitive advantages
  • replace disorder with clarity, direction and confidence

This Conference gathers the leading SharePoint Experts to define, describe and set methods that will become industry standard – insights you can gain now to avoid pitfalls, cut costs and gain a competitive edge. Speakers include:

  • Microsoft MVPs
  • Microsoft Product Team Members
  • Top industry executives and authors
  • Leading trainers, consultants and topic experts
  • Industry colleagues

I’ll be talking about:

Debugging and troubleshooting SharePoint 2010 Applications

SharePoint is definitely a complex application platform. This is due not only to the huge number of features that it provides, but also to its internal architecture, which is based on several base technologies and is, therefore, quite hard to be understood and mastered. This is one of the reasons why the development of SharePoint Applications is traditionally considered tricky and intricate, and… yes, you probably have to spend some time troubleshooting and debugging what seems not to be working as expected! But wait! You have tools you can use and techniques you can learn! And you can try to make your troubleshooting experience a little less painful, leveraging the logging improvements that SharePoint brings to the table and identifying issues much more quickly and consistently. We’ll try to explain some of these techniques and these tools, hopefully providing some good tips that will help you reduce the time spent in front of a debugger or a long, long log file.