The environment was a virtual machine running Windows Server 2008 on Windows Virtual PC (Windows 7).  As others have reported, this problem appears to happen much more often, if not exclusively, on virtual machines.

I figured that since disk space calculation was behind the issue, the best approach was to eliminate as many disks as possible from my virtual machine until the problem (hopefully) disappeared.  I had one (virtual) floppy drive, one hard drive and one DVD drive.

Using Device Manager, I disabled the floppy controller.  The floppy drive disappeared, but the problem didn’t.  Next, I disabled ATA Channel 1 of the IDE ATA/ATAPI controllers, which controls the DVD drive.  The DVD drive disappeared – and so did the dialog box!  I did some experimentation with a few combinations of drive configurations, and the problem definitely followed the DVD drive.  It seemed that leaving the IDE controller enabled in the virtual machine, but setting Virtual PC to None for the DVD drive option also worked fine.  The common default setting that maps the virtual DVD drive to a physical DVD drive or to an ISO file caused the problem to appear.

So, bottom line, if you’re seeing this happen in either a VMWare or Virtual PC VM, try disabling the IDE controller attached to the virtual DVD drive.

In case you have also run into this (many have), Microsoft did a bad thing (supposedly now fixed), and the effect is that bad data may have been cached on your PC, which prevents you from being able to log in.

Here’s some info on the problem.

The solution if you are using Windows Live Messenger 8.0.x is to delete the registry key HKCU\Software\Microsoft\MSNMessenger\Policies.  As always, don’t attempt this if you are not comfortable editing the Windows registry.

Another related issue they describe is specific to ZoneAlarm firewall users, and that one is pending a fix as of this writing.  They suggest dropping back to an older version of Messenger until that fix is available, so hopefully the registry key will fix it for you.

My suspicions were correct: it is a threading bug, and it turns out that the steps are even simpler:

1. Start the Database Engine Tuning Advisor
2. Drop down the “Server name” listbox and choose “Browse for more…”
3. Click the Network Servers tab
4. Click the Cancel button
5. Wait a few seconds … until the application crashes…

The background discovery thread tries to access the TreeView control in the browse dialog, which no longer exists since you closed it. Oops. I’m not sure how this one got past QA. I passed the info on to friends in the SQL Server group, and probably ruined their days.

Yesterday I had a chance to install the RTM version and start poking around through the final client apps. Unfortunately, I found a repeatable way to crash one of them, the Database Engine Tuning Advisor, within the first hour!

Here are the steps, which assume you’re executing them locally on a SQL 2005 machine:

1. Start the Database Engine Tuning Advisor
2. Drop down the “Server name” listbox and choose “Browse for more…”
3. Click the Network Servers tab
4. Immediately click back to the Local Servers tab, double-click Database Engine, click your server name and the OK button
5. Drop down the Authentication listbox
6. Wait a few seconds … until the application crashes!

This was discovered and repeated on Windows Server 2003 SP1 and SQL 2005 RTM.

Just a guess, but I’m thinking they start a server discovery thread when you go into Network Servers, and if you don’t wait for it to finish and go back to another place in the UI, the discovery thread does something bad when it finishes. The joys of multithreading.