4

TL;DR What is the sane way to automate invokation of VS 2017 vc_redist when called in a chain of several installers?

The Visual C++ Redistributable Installer that MS provides for VS 15.x (VS 2017), namely both (14.15.26706 - VS 15.8.4)):

  • vc_redist.x86.exe
  • vc_redist.x64.exe

As part of our full product installation, I have to run several vcredist installers (also older versions) silently.

The problem now is that these installers will refuse to install if a reboot is pending (e.g. "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" - PendingFileRenameOperations).

When calling these installers with vc_redist /q, they will even trigger an immediate system reboot. This can be fixed by calling them with /q /norestart, however:

When calling vc_redist /q /norestart, and if a reboot is pending prior to this installer, it will return MSI exit code 3010 which indicates that a reboot is required.

However, AFAIK, this exit code also indicates, that this very setup requires a reboot to complete.

Actual question

So, I cannot distinguish whether this installer was succesful and just requires a reboot at the very end of my installation sequence (I do install otehr stuff before and after) - or whether the installer actually refused to do anything and I would need to restart the system and start this installer again!

How can I call this vc_redist in a chain of different third party installers and

  • ideally require just one reboot at the very end
  • at the very least, determine whether it installed successfully.

Some additional infos, fwiw:

Not sure these helkp with the question, but for completeness sake.

  • The installer GUI clearly indicates what is going on: (sorry, german Windows)

Popup Box

"No action was taken because a reboot of the system is required."

Summary / Close / Restart

  • This is an InnoSetup built installer for our "product suite", that will be used by customers, the installation order goes as follows:

    1. Run MSVC 2005 (VC8) 32 bit vcredist
    2. Run MSVC 2010 (VC10) 32 bit vcredist
    3. Run MSVC 2017 (VC141) 64 bit vcredist
    4. Run MSVC 2017 (VC141) 32 bit vcredist
    5. Run a few other third party dependecy / library installers
    6. Install the actual application files (via InnoSetup)
    7. Reboot (ask) if any installer indicated a required reboot.

As you can see from this sequence, rebooting after each vcredist woud be insane, and luckily it seems only the 2017 redist exhibits this unfortunate behaviour so far.

Of note: My trial runs on my dev machine all started with a reboot already pending at "step 0", and both the VC2005 and VC2010 installer run just fine (as verified through their GUI progress) even if a reboot is pending before hand. It's the VC2017 installers that refuse to do anything if a reboot is pending.

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • you could at least check if a reboot is pending before each step in your installer (i.e. like this https://github.com/bcwilhite/PendingReboot/blob/master/Public/Test-PendingReboot.ps1) – mwallner Oct 11 '18 at 07:57
  • I am not sure where that message comes from to be honest. Is it from the WiX standard bootstrapper? Maybe. But it could also be from the MSU packages? I couldn't see that particular message in the standard bootstrapper, but I didn't look closely. Is it coming from the MSU and just relayed by the standard bootstrapper application perhaps? That was essentially my thinking when suggesting to check whether the MSU packages are already installed. I would probably put the runtime installers in a separate package to run as a separate thing. – Stein Åsmul Oct 11 '18 at 19:27
  • I'd love to know if you've ever conquered this. Its still going on with vcredist 2019 and its becoming a real thorn in my side. – Dave Ludwig Nov 20 '20 at 14:37
  • 1
    @DaveLudwig - what we do now is we already install the MSU packages separately, therefore we get some meaningful return codes from those. // then, when I get a 3010 I will assume nothing happened, trigger a reboot and on the next start just call it again. It's a workaround that mostly is OK, since if the first 3010 installed it, the second call is a noop anyway. And I don't know if we even had to reboot twice. It seems to do the job that way. – Martin Ba Nov 20 '20 at 18:55

2 Answers2

2

MSU Packages: After decompiling the vc_redist.x64.exe - which is a WiX bundle - using this command:

dark.exe -x Extract vc_redist.x64.exe

I found that the bundle installs: Update for Universal C Runtime in Windows - KB2999226. This component consists of Windows Update files (*.msu - used by Windows Update) and not just MSI files. I would suspect that they could be designed to require a reboot before allowing installation, but I don't have proof.

Suggestion: Run a check to make sure KB2999226 is installed. How to do this? I don't know a Win32 call, but the WiX guys will probably know. Here are some other suggestions.

The actual Windows Update Files are (over time these file names could change as new versions of this installer with the versionless file name - vc_redist.x64.exe - are released):

  • Windows6.0-KB2999226-x64.msu
  • Windows6.1-KB2999226-x64.msu
  • Windows8.1-KB2999226-x64.msu
  • Windows8-RT-KB2999226-x64.msu

In other words for Vista, Windows 7, Windows 8 et al. Various Server OS's as well. Windows 10 has this component built-in.

Corporate Deployment: In a corporate environment I would deploy these *.msu files via the distribution mechanism available - whatever it might be - for example SCCM - before installing the vc_redist.x64.exe package.

This should yield better control of the distribution process as you get error messages straight from the MSUs themselves.

Frankly these are core-SOE components in my opinion. I don't know why Microsoft keep these runtimes out of the main OS installation. They are crucial for most software.

A description of the decompilation approach using the WiX toolkit's dark.exe binary can be found here: How can I compare the content of two (or more) MSI files?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thanks. Technically very helpful, but to make sure: I *know* why it currently wants a reboot. The question is how do I make it tell me in a general way if it refused it's work. The GUI tells me just fine, but the /Q version is too limited. – Martin Ba Oct 11 '18 at 10:55
  • What error does the redist GUI show? Could be possible to find in the WiX Burn source code. Also, can you not check whether the actual product you are trying to install made it by checking for its entry in the registry for Add / Remove Programs? I suppose that is: `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall` or `HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall`. – Stein Åsmul Oct 11 '18 at 11:19
  • There is a per-user one as well: `HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall`. Is this a corporate release, or for general distribution? I would presume the latter, but just wondering. – Stein Åsmul Oct 11 '18 at 11:28
  • I am asking about that corporate stuff because then I would just make a separate installer for all the runtimes. – Stein Åsmul Oct 11 '18 at 11:37
  • I'va added a few details to the question. It is a customer/user side installer. – Martin Ba Oct 11 '18 at 11:49
  • The info here is very useful for another issue. Do you know if I can tell from the "dark extract" files I get *how* WiX decides wether to call the MSU files, and how it calls the MSU files? Because I have evidence that WiX somehow determines it doesn't need to call the MSU file (even the one for the specific OS) and I'm curious if that can be found in the "dark extract". Cheers :-) – Martin Ba Mar 15 '19 at 13:08
  • Not sure if it helps, but did you see [**this answer on VCRedist Detection**](https://stackoverflow.com/a/53639128/129130)? – Stein Åsmul Mar 15 '19 at 14:45
  • OK, I had a look and the installation seems to depend on the `InstallCondition` and `DetectCondition` attributes of the [**`MsuPackage Element`**](http://wixtoolset.org/documentation/manual/v3/xsd/wix/msupackage.html). Those conditions use properties that can be set via `FileSearch`, `RegistrySearch`, `ComponentSearch`, `ProductSearch` and `DirectorySearch` elements. See Burn Documentation (WiX tool used to make the setup.exe file): [**Define Searches Using Variables**](http://wixtoolset.org/documentation/manual/v3/bundle/bundle_define_searches.html). – Stein Åsmul Mar 15 '19 at 17:39
  • Look in the **`manifest.xml`** file and also the **`BootstrapperApplicationData.xml`** file after decoding a **`Burn bundle`** (**`setup.exe`**). My two cents: get this installed with the setup.exe and then run Windows Update for simple use cases. – Stein Åsmul Mar 15 '19 at 17:57
  • [The newest VCRedist installers need to run as setup.exe files to install all components](https://stackoverflow.com/a/34597936/129130). – Stein Åsmul Mar 15 '19 at 18:06
1

Strictly speaking, error 3010 is a success result. It means that the install has completed but requires a reboot. I'm not aware of anything to indicate that it means the install didn't start at all. The typical "won't install if reboot pending" is a result of using a launch condition based on the MsiSystemRebootPending property. Failures due to this launch condition do not return return a 3010 result - they usually return a 1602 error as a kind of "user cancel" error.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Thanks for this info: In this case the VCRedist Installer is *clearly* buggy, because it does as a fact return 3010 even when it does nothing. (I'm not surprised at the least. The VS2017 installer story overall is ... so sad.) – Martin Ba Oct 17 '18 at 09:36