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?"}
body
{"Quick Commands"}
{"SOS"}
  {"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.

WinDbgCmdTree

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: http://blogs.msdn.com/b/debuggingtoolbox/archive/2008/09/17/special-command-execute-commands-from-a-customized-user-interface-with-cmdtree.aspx

XSLT and verbatim content with CDATA sections

Here’s a quick tip you may find useful while writing some – maybe complex – XSLT transformations.

I adopted this solution recently for some library code that emits RSS complaint XML documents.

My need was to create XML fragments that contain unescaped HTML content, so that I could easily create HTML formatted elements values without worrying too much about HTML encoding.

Of course, CDATA sections were a suitable (and easy) option.

But you cannot include CDATA sections as such in the processing transformation, since it would have caused an automatic escaping of the inner content…. unless… you specify that one or more of the output elements will indeed contain CDATA sections.

You can achieve this goal just by specifying a cdata-section-elements as an attribute of the XSL element output (see this excerpt from the XSL reference documentation):

<output>
method = xml | html | text | qname-but-not-ncname
version = nmtoken
encoding = string
omit-xml-declaration = yes | no
standalone = yes | no
doctype-public = string
doctype-system = string
cdata-section-elements = qnames
indent = yes | no
media-type = string
Model: EMPTY
</output>

Credits go to Bernie Zimmermann, whose detailed post you can find here: http://www.bernzilla.com/2008/02/12/utilizing-cdata-section-elements-in-xsl/

IIS Smooth Streaming Whitepaper

If you are confused about the difference between Media Streaming, HTTP progressive download, IIS Smooth Streaming and IIS Live Smooth Streaming, here’s a wonderful whitepaper by Alex Zambelli that I strongly suggest you to read.

You know, talking about Digital Assets Management you often hear about streaming, but IMHO sometimes this word is abused. This whitepaper explains you what streaming really is, and talks about other techinques that can reach the same goal, while not streaming anything!