visual studio 2017 - How to prevent vc_redist.x##.exe (VS2017) from ambiguously failing due to pending reboot?

Question

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:SYSTEMCurrentControlSetControlSession 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)

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

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

Answer 1

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.

• Windows: How to List All of the Windows and Software Updates Applied to a Computer
• Why are “get-hotfix” and “wmic qfe list” in Powershell missing installed updates?
• Identifying installed updates on Microsoft products

---

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?