Tonight I was attempting to test the MSI installer for the Deployment Framework for BizTalk when I encountered an infinite dialog box stating "Please wait while the installer finishes determining your disk space requirements.” This is by no means the first time that I’ve seen this occur, but usually it goes away after restarting the install once or twice. Unfortunately, this time every single attempt at a GUI install was blocked by this issue. (As documented elsewhere, using msiexec.exe to start an unattended install worked, but I needed to test the GUI.)

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.

Share this:

Like this:

Starting a couple of days ago I was suddenly unable to sign into Windows Live Messenger. The signin graphic would just spin endlessly, or I’d get a “service not available” message.

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.

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.

Share this:

Like this:

As a follow-up to my earlier post about crashing the SQL Server 2005 Database Tuning Advisor, I later discovered that the .NET exception stack trace was logged to the Application event log.

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

Start the Database Engine Tuning Advisor

Drop down the “Server name” listbox and choose “Browse for more…”

Click the Network Servers tab

Click the Cancel button

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.

Share this:

Like this:

SQL Server 2005 is arguably the most important release of SQL Server in Microsoft’s history. It has been through numerous public test releases in addition to extensive internal testing.

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:

Start the Database Engine Tuning Advisor

Drop down the “Server name” listbox and choose “Browse for more…”

Click the Network Servers tab

Immediately click back to the Local Servers tab, double-click Database Engine, click your server name and the OK button

Drop down the Authentication listbox

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.