Blog du Tristank

So terrific that 3 of 4 readers rated it "soporific"

Windows Server 2008 Desktop Edition

WS08 Workstation, Anyone? 

Apart from those pesky Live applications that won’t install (why would anyone ever blog from a Server OS, as I’m doing now? Beats me…), I’ve had a relatively good run with Windows Server 2008 (x64, naturally) as my desktop OS.

Key drawbacks:

As mentioned, no official support of the Live suite (thanks!)

My Catalina handset is the only audio device I currently have a driver for, and Muse sounds odd through the speakerphone.

No Hyper-V, cos I’m only on a P4-class machine without VT/Pacifica/hardware support.

Now, onto less desktop-py things – managed debugging on the shiny new platform, with WinDBG:

Managed Debugging of dumps from, oh, say, a Sharepoint 2007 server on 32-bit

As a you’ll-notice-this-when-it-hits-you mention, the version of MSCORDACWKS that ships with WS2008 looks like it’s 2.0.50727.1434 (unless that came from somewhere else) instead of 1433 (2.0SP1, if I recall correctly (and I often do)) – meaning that debugging a managed dump won’t work straight out:

PDB symbol for mscorwks.dll not loaded
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is
                in the version directory
            3) or, if you are debugging a dump file, verify that the file
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64

You can also run the debugger command .cordll to control the debugger’s
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.

After a little fiddling with .cordll, I worked out the easiest method (read: the first method I hit upon that worked) to get past it.

In less debugger-y speak:

  • grab a copy of the 2.0 SP1 version of MSCORDACWKS.DLL from the Windows\Microsoft.Net\Framework\2.0.50727 folder on a machine with the right version (I fished one out of my Vista installation on the same machine),
  • paste and rename it into the same folder as WinDBG, as mscordacwks_x86_x86_2.0.50727.1433.dll (rinse and repeat with amd64 for the 64 bit version, from Framework64).

Then .cordll -ve -u -l should work, and so should your SOS commands.