Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Return codes for .NET Framework 3.0 setup

Return codes for .NET Framework 3.0 setup

  • Comments 2

A while back, I posted a list of possible return codes for the .NET Framework 2.0.  I recently found out that the setup wrapper for the .NET Framework 3.0 can return a couple of other error codes in certain scenarios, so I wanted to list those here as well for completeness:

0x0013EC (5100) - Generic setup block

This error code will be returned in several different scenarios:

  • The user running setup does not have administrative privileges
  • A previous beta version is installed (the algorithm is similar to the one for the .NET Framework 2.0 described here, but the product codes are stored in the file named setup.sdb instead of install.ini)
  • A later version of the .NET Framework 3.0 is already installed
  • The OS that setup is being run on is not supported
  • The OS that setup is being run on does not have the minimum service pack installed

0x002332 (9010) - A pending reboot must be completed before setup can run

This error code is returned if some previous action on the system caused pending file rename operations to be scheduled by adding entries to the following registry value:

  • Registry root: HKEY_LOCAL_MACHINE
  • Registry key name: Software\Microsoft\Updates\UpdateExeVolatile
  • Registry value name: Flags -or- Flags_<reboot time>

This error can typically be resolved by rebooting the system.  If the error continues to occur even after a reboot, you can manually delete this Flags value from the registry on your system to work around it.

The reason that .NET Framework 3.0 setup contains a check for this registry value is that a couple of the prerequisite packages that it installs are Windows OS hotfixes.  These hotfixes include specific checks for this registry value and they will fail if it exists and is non-blank.  The .NET Framework setup team decided it would be best to catch this type of error at the beginning of the setup process instead of letting setup start running and then fail later on for a cause that could easily be validated up-front.

<update date="11/29/2006"> Updated the registry value that .NET Framework 3.0 setup checks to determine whether a pending reboot must be completed.  The original value I posted (HKLM\System\CurrentControlSet\Control\SessionManager@PendingFileRenameOperations) is used by many Windows applications, but .NET Framework 3.0 setup does not check for that value because it will not result in any of its prerequisite packages failing. </update>

 

  • Argh,

    The check for PendingFileRenames, although I understand the rational, can be dangerous. Let me share a practical true story.

    An older version of my installer (couple years ago, before we went to MSI) checked for this regkey too. It was my attempt to fix a cornercase bug that was marked as must fix whereby an uninstall operation was completed (with locked files encountered), yet the user did not restart and then chose to reinstall the application again.

    Of course after the user reboots - bingo, files from the previous uninstall would be deleted and that left a mess. (it was a non-MSI install, so no auto repair trigger)

    So I added this check. Worked nicely... until our QA nixed the fix because some of their systems always got my reboot error - it wasn't "tester friendly". Turns out at the time, a clean XP system that got pushed a Windows Update (MSI 3.0 I believe) which added to PendingFileRenamesOperations. Our QA guys almost convinced marketing that this is a normal scenario and marketing didn't want the begining reboot. I successfully fought this off.

    However, a wily QA tester found the dealbreaker that forced me to remove this check. Some printer driver apparently always gets added here (perpetually! Bad Printer Driver...). And these users would never be able to install our software, unless they impliment your workaround! So my fix was removed. :-(

    I was thinking that a smarter way would be to check PendingFileRenamesOperations against a manifest of known files that are installed... which sounds ideal for small apps that don't have too many files - but I can't see this being practical for large apps with many many files to check.

    I think Windows Installer's auto-repair can help for the orginal problem (it did for me!) but it would sure be nice if Windows Installer ultimately did some smart checking of PendingFileRenameOperations too as part of the Costing process and the whole "FilesInUse" behavior. I donno, maybe it does? I haven't seen the original problem in a long time...

    Anyways, just my 2 cents.

  • Hi Gripper - Thank you for sharing your experiences here.  Visual Studio setup used to have a pending reboot check in 2002/2003 and it caused the same type of problems that you describe.

    The packages that are a part of the .NET Framework 3.0 that block if this pending file rename table isn't empty are update.exe OS hotfixes and not MSIs.  I just took a more detailed look at the setup code that handles this, and I found that in the .NET 3.0 setup case, it is not checking the PendingFileRenameOperations registry value, but instead is checking a value that is specific to update.exe-based setup packages.  I will update this blog post with that information.

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 5 and 2 and type the answer here:
  • Post