Skip to content

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.

Comments 13

  1. Christopher Painter wrote:

    I have seen this behavior but it’s been awhile. I’ll see if I can do some digging for you.

    Posted 04 Apr 2010 at 16:05
  2. ScRePt wrote:

    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 :D

    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

    Posted 05 Apr 2010 at 10:14
  3. Neil Sleightholm wrote:

    I have seen this on VMs (VMware) and a physical machine.

    Posted 05 Apr 2010 at 12:05
  4. Jesper wrote:

    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

    Posted 05 Apr 2010 at 16:44
  5. Melinda Sawnson wrote:

    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.

    Posted 06 Apr 2010 at 02:45
  6. Ashok Kumar wrote:

    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.

    Posted 21 Apr 2010 at 21:47
  7. Justin wrote:

    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.

    Posted 30 Apr 2010 at 13:56
  8. Paulo Santos wrote:

    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

    Posted 05 May 2010 at 08:23
  9. Neil Sleightholm wrote:

    For info the AnknSvn installer is written using WiX 3.0.

    Posted 11 May 2010 at 03:05
  10. moc wrote:

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

    Posted 11 May 2010 at 05:19
  11. rev wrote:

    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.

    Posted 02 Jun 2010 at 09:38
  12. andrew wrote:

    Where is the log? I am seeing this right now on http://launchpad.net/nunitv2/2.5/2.5.5/+download/NUnit-2.5.5.10112.msi

    Posted 03 Jun 2010 at 13:37
  13. andrew wrote:

    After I rebooted, the “please wait” is gone now. Maybe it had to do with the fact I had a pending installation of Windows Automation API 3.0 http://support.microsoft.com/kb/981741/en-us . BTW, my system is Windows XP SP3 32-bit

    Posted 03 Jun 2010 at 14:03

Trackbacks & Pingbacks 1

  1. From Joy of Setup - It’s time to experiment on 20 May 2010 at 23:20

    [...] month, I posted a plea for help to try to figure out why sometimes (or rarely) (or frequently), Windows Installer fails to set an [...]