Bug hunting

There’s a bug that the WixUI “Please wait while the installer finishes determining your disk space requirements” dialog is intermittently shown forever, never finishing the costing process to continue installation. I’ve seen that bug before have never been able to reproduce it reliably. The disk costing process is something Windows Installer does in the background while the wizard UI is running; .msi packages have no real control over the process, other than which features are enabled at the start of the UI sequence.

Here’s the problem: I don’t think it’s a bug in WiX or WixUI. MSI owns the costing process and as costing works almost all the time, there isn’t a simple answer like “oh yeah, a rich-edit control on the first dialog breaks costing.” I suspect that there’s a bug in MSI but before I go to the MSI team, bug in hand, I need more data. Here’s where you come in: Help us gather more data to narrow down the bug.

  1. Logs. It’s a reflexive request that verbose MSI logs are a vital part of figuring out any setup bug. In this case, they might not be that helpful, as the logs I’ve seen, including those attached to the bug, just show a lot of time passing between log entries.
  2. OS version. Which version of the OS? Which edition? x86 or x64? Which service pack?
  3. Virtuality. Does the bug occur in virtual machines or on “real” machines? Which virtual machine technology (e.g., Virtual PC, Hyper-V, VMware, VirtualBox)?
  4. MSI version. If it is a bug in MSI, narrowing down which versions are afflicted the worst would be key. (For example, I’ve never seen the bug occur on MSI 5.0 in Windows 7.)
  5. Frequency. How often does the bug occur?
  6. .msi package data. How big? How many files? How many components?
  7. WiX and WixUI data. Which version of WiX are you using? Which WixUI dialog set? How have you customized it?
  8. Packages. If you can provide packages that demonstrate the problem, please do so. Obviously, you might not be able to share your actual package content but does the bug still reproduce if you replace your actual files with zero-byte replacements?

If you’ve seen this problem, please help: Add your comments to the bug on SourceForge and attach your logs and packages.

Help us WiX community, you’re our only hope.

Update, 5 April 2010: Added Virtuality – I got a report that the bug occurs most often on Virtual PC virtual machines and it seems to be a common issue on various blogs.

14 Replies to “Bug hunting”

  1. I’ve seen this a while ago when trying to install Microsoft Project 2003 on an XP SP3 32bit (real pc, not virtual pc)

    Unless MS Project uses WiX, it’s a Microsoft bug 😀

    I do not own that pc, so I can not give you more tracks. One thing I remember is that it did the same thing 2-3 times before I shut down useless programs (outlook etc) to free up memory. Then it calculated free space as expected

  2. I have seen this once when installing on a Win 2008 R2 server. However we saw that when using the bootstrapper setup.exe file the issue showed up, exactly as described, but when invoking the .msi file directly everything worked.
    However we have a customized ui and about 3 MB msi file size

  3. Let us build together and install multiple software on windows always Bob always.Let the candles burn in the heat of our passion.Let us Burn in the Dark together and bring the Light.

  4. I can reproduce this bug 100% of the time with various packages. I just encountered it for the first time today. I’ll submit detailed info at the link you provided above.

  5. I have encountered this, but not recently, so unfortunately I can’t provide any samples.

    I can say that they were VERY small MSI’s, not a lot more than “hello world” magnitude. I discovered that deleting the MSI and rebuilding it sufficed as a workaround.

  6. I have encountered this problem with AnkhSvn-2.1.8280.494.msi.
    It happened once then I canceled the installation, closed all applications and ran it again and it was successfull.
    Windows XP x86, real machine

  7. in a vmware vm. I have some network drives mapped in the vm and these were ‘down’ at the time (up and down like a yo-yo here) and I then saw this problem.

  8. for what it’s worth, i’ve seen this problem intermittently using wise 5.21 – which anecdotally supports your hunch that it’s not a wix problem at all, but an msi problem.

Comments are closed.