An issue with an update

After waking my Windows 10 PC up and running updates, I was told that the latest update (2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112)) could not be installed. Looking over the update history, it appeared that this was the second update that couldn’t be installed, the first being 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).

Restarting the PC, either manually or through the button in Windows Update, wasn’t causing the update to be installed; in my experience the update would be queued up immediately prior to restart, or immediately after restart.

Some information could be gleaned in Event Viewer, under Windows Logs > System, filtering by:

  • Event sources restricted to WindowsUpdateClient
  • Event level restricted to Error

or using the following XML filter:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*[System[Provider[@Name='Microsoft-Windows-WindowsUpdateClient'] and (Level=2)]]</Select>
  </Query>
</QueryList>

From this I had the following distinct events:

Installation Failure: Windows failed to install the following update with error 0x80010108: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80070BC2: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80070020: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80246007: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80070BC2: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112).
Installation Failure: Windows failed to install the following update with error 0x8007045B: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112).

resolving down to the following error codes:

0x80010108
0x80070020
0x8007045B
0x80070BC2
0x80246007

A solution is found

Looking for these error codes online, I luckily found a very helpful comment on Reddit here which indicated that ensuring particular services were configured to run automatically would solve the issue.

The services in question were:

  • BITS (Background Intelligent Transfer Service)
  • CryptSvc (Cryptographic Services)
  • TrustedInstaller (Windows Modules Installer)
  • wuauserv (Windows Update)

As opposed to simply configuring the services to run automatically, I thought I’d take a look at the current configuration of each.

Before attempting the fix, the service configuration for each (obtained via sc qc <service-name>) was:

SERVICE_NAME: BITS
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START  (DELAYED)
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\System32\svchost.exe -k netsvcs -p
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Background Intelligent Transfer Service
        DEPENDENCIES       : RpcSs
        SERVICE_START_NAME : LocalSystem

SERVICE_NAME: CryptSvc
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\system32\svchost.exe -k NetworkService -p
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Cryptographic Services
        DEPENDENCIES       : RpcSs
        SERVICE_START_NAME : NT Authority\NetworkService

SERVICE_NAME: TrustedInstaller
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\servicing\TrustedInstaller.exe
        LOAD_ORDER_GROUP   : ProfSvc_Group
        TAG                : 0
        DISPLAY_NAME       : Windows Modules Installer
        DEPENDENCIES       :
        SERVICE_START_NAME : localSystem

SERVICE_NAME: wuauserv
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\system32\svchost.exe -k netsvcs
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Windows Update
        DEPENDENCIES       : rpcss
        SERVICE_START_NAME : LocalSystem

The odd one out in this listing is TrustedInstaller, with a START_TYPE of DEMAND_START, all others have some variant of AUTO_START. More importantly, the current status of TrustedInstaller (obtained via sc query TrustedInstaller) was:

SERVICE_NAME: TrustedInstaller
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

so the service was not running.

My understanding of DEMAND_START is that it should be, well, started on demand, so Windows Update should have been able to start it as part of the update installation process. However, this seemed a very likely issue, so I reconfigured the start type via the command mentioned in the Reddit comment, sc config TrustedInstaller start= auto and restarted my PC.

After this, initialising a restart via Windows Update proceeded smoothly, and the update has been installed.

Further investigation

Now I felt it was worth looking into how the TrustedInstaller service had been configured for on-demand start, so I took a look at Event Viewer once again. This time, filtering by:

  • Event sources restricted to Service Control Manager and WindowsUpdateClient

or using the following XML filter:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*[System[Provider[@Name='Service Control Manager' or @Name='Microsoft-Windows-WindowsUpdateClient']]]</Select>
  </Query>
</QueryList>

Around the time of a failed update installation were the following events:

The start type of the Windows Update service was changed from demand start to auto start.
Windows Update started downloading an update.
The start type of the Windows Modules Installer service was changed from demand start to auto start.
Installation Started: Windows has started installing the following update: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112)
The start type of the Windows Modules Installer service was changed from auto start to demand start.
The start type of the Update Orchestrator Service service was changed from demand start to auto start.
The start type of the Background Intelligent Transfer Service service was changed from auto start to demand start.
The Update Orchestrator Service service terminated with the following error:
    This operation returned because the timeout period expired.
The start type of the Update Orchestrator Service service was changed from auto start to demand start.
Installation Failure: Windows failed to install the following update with error 0x80070BC2: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112).

From this listing, it appears that:

  • wuauserv initiates an update download and starts TrustedInstaller
  • TrustedInstaller starts an install, but stops due to the installation requiring a restart
  • UsoSvc (Update Orchestrator Service) is started but is terminated due to an error
  • Installation of the update fails

So how does changing the start type of TrustedInstaller do to fix this issue? My guess is that UsoSvc is tasked with re-enabling TrustedInstaller (among other things), and so if it fails it also doesn’t re-enable TrustedInstaller to finalise the installation during the restart process.

Conclusion

That’s about as far as I can go now, without attempting to rollback the update and reinstall to trigger the issue. Going forward, I’m going to return the TrustedInstaller service to start on demand, and see whether this issue rears its head again for the next update.