Null Pointers

It has been almost a year and a half since I first experienced a STOP 0x0000C1F5 on Vista and discovered a workaround for the problem (see my original post on the topic here).  Since that time, I have received tens of thousands of page hits, hundreds of comments, countless side conversations, and even a few donations as a result.

Several people contacted me to inform me that there is FINALLY a fix available from Microsoft for this problem.  It seems that the Windows 7 beta disc (and, of course, the Windows 7 RTM disc) includes a “silent fix” for this issue.  Apparently, when you boot a Windows 7 disc and it is identifying potential partitions for installation, it silently fixes any problems with $TxfLog that it finds… so if you boot it to the “Install Now” prompt, abort the installation, remove the disc, and simply boot Vista off your hard drive, it should fix itself.  This is described in KB970101.

We are setting up a full-bore implementation of Microsoft Office Communications Server 2007 R2 (OCS 2007 R2) in order to evaluate its capabilities. To date, I have set up a full Enterprise-type deployment and it is working flawlessly (e.g. all functions of Office Communicator 2007 R2 and Communicator Web Access work as expected, both on the intranet LAN and via the public Internet). We will be expanding our evaluation to include the broader Unified Communications platform which uses additional functionality provided by Exchange 2007 (which we also have deployed and operational).

Some of the OCS and UC features require the use of POTS lines to give "regular" (non-IP-phone-or-SIP-client-using) users access to facilities such as audio conferencing, LiveMeeting, voice-driven access to Outlook, etc. In order to do this, you need to provide OCS and Exchange with SIP-based access to POTS lines. I was given this task, and chose the Trixbox soft PBX platform as an element of my solution. In Part 1 of this article, I will describe the setup of Trixbox and the use of a Quintum SIP gateway to connect to our POTS lines.

Last night, I did something stupid on my primary desktop computer (a Vista box) and needed to restore the system to a recent backup. I use Windows Home Server on my home network, so I was confident in my ability to roll back the system to a previous night's backup. I booted my machine using the WHS Client Restore CD, chose the appropriate backup, waited (im)patiently for about two hours while the bits were restored, the system rebooted...

...and that's when I saw the Blue Screen of Death... specifically, a STOP 0x0000C1F5. Crap.

Now, my first instinct was that I had a sketchy backup image in WHS, and perhaps I should try a slightly older one. I repeated the restore process with three older backups and got the same result. On the verge of going off on a major "WHS sucks" tirade, I instead opted for some Googling on a still-working system to see if I could find any clues. It seems as though the frequency of reports of STOP 0x0000C1F5 problems is increasing, with most people attributing the issue to a bad Vista SP1 (or prepare-for-SP1) update or patch. Microsoft acknowledges the problem in KB946084, but there is no public hotfix or workaround save for "clear the MBR and reinstall", which IMHO is unacceptable.