What’s in IIS 7.0 for me?

While having a seemingly-innocuous chat with a colleague, I was asked to "throw together a few points" on what IIS 7.0 would do for a web application I’ve worked with in the past. Serves me right for talking to people, really.

In this application’s case, authoring, publishing and content creation weren’t as important as eventual scale-out and actual application performance (otherwise the just-released FTP7 would have been top of the list).

Here’s what I came up with, off the cuff:

  • Reduced attack surface/patching requirements: IIS7 is now modular, and only the parts of the server actually needed by the application are required to be installed. This can also enable performance increases due to reduced memory footprint.
  • Vastly (imho) improved compression capabilities and compression performance (with automatic compression back-off when CPU use is high! How cool is that!?)
  • Simplified web farm management – if the application is able to work reliably in a web farm scenario, the IIS configuration store can be centralized and shared across all machines in the farm. (also see MSDeploy)
  • XCOPYable configuration – easily ensure settings are consistent between dev, qa and prod environments.
  • Failed Request Tracing (aka FREB) – if failures occur, request traces can be captured that include detailed diagnostic information.
  • Windows Server 2008 security, performance and scalability improvements – the most secure Windows yet (I expect); support for the latest hardware and 64-bit computing; and optimized TCP/IP performance.
  • SSL performance greatly increased – Kernel-mode SSL (not the best link for admin types) reduces context switching and ring transitions, and improves performance
  • Better UI! After a short time working out how the new model worked, I’m sold.

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
                machine.

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.