Windows Boot Failures Reported After Installing October KB4041676/KB4041691 Updates

Table of Contents

This document addresses a specific issue encountered in October 2017 where certain Windows devices experienced boot failures following the installation of the KB4041676 and KB4041691 updates. These updates were part of the monthly security rollup released on October 10^th. The problem primarily affected systems managed through Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM). Understanding the context of this issue, its specific manifestations, and the provided resolutions is crucial for administrators who managed affected environments at the time.

The updates in question were KB4041676, designated for Windows 10 version 1703, and KB4041691, applicable to Windows 10 version 1607 and Windows Server 2016. Microsoft acknowledged a publishing issue with the initial release of these updates via WSUS and SCCM channels. This specific issue did not impact devices that received updates directly from the public Windows Update service or via Windows Update for Business. The distinction in impact highlighted the different delivery mechanisms and how a problem in the publishing process could affect enterprise environments relying on centralized management tools.

Microsoft swiftly addressed the identified publishing issue on the afternoon of October 10, 2017. Corrected versions of the cumulative security updates were subsequently validated and made available. It is highly recommended that all systems receive and install the corrected versions of these updates to ensure security and stability. The issues described below pertain specifically to the faulty versions of the updates that were temporarily available through WSUS/SCCM channels before the correction was implemented.

Three primary scenarios describing the impact on WSUS/SCCM managed environments were reported. These scenarios represent different stages of the update deployment process where the publishing issue could manifest. Each scenario required a distinct mitigation strategy depending on whether the update had been synced, downloaded, or fully installed on the target devices. Administrators needed to identify which scenario applied to their environment or specific devices to apply the correct workaround.

Overview of the Issue and Impacted Systems¶

The root cause of the boot failures was identified as a publishing anomaly affecting the delta packages of KB4041676 and KB4041691 distributed via WSUS and SCCM. Delta packages contain only the changes made since the previous monthly rollup, making them smaller but dependent on the correct baseline. A problem in how these delta packages were published or processed led to potential conflicts during installation or the subsequent boot sequence. Full cumulative updates, which contain all changes up to the current month, were not subject to the same publishing issue.

Enterprise environments heavily rely on WSUS and SCCM for managing the update process, allowing administrators to approve, test, and control the deployment schedule. This control, while beneficial for stability and compliance, also meant that environments using these tools were exposed to the publishing error before it was corrected. Home users and businesses using the standard Windows Update service pulled directly from Microsoft’s corrected feed and thus bypassed the affected distribution channel. The incident underscored the importance of understanding the update delivery mechanisms and the potential points of failure within the enterprise update infrastructure.

Microsoft’s rapid response involved correcting the faulty packages in the distribution channels. Once the corrected packages were available, the primary action for administrators was to ensure their WSUS or SCCM servers synced the updated metadata and binaries. This would prevent further deployment of the problematic versions. However, for systems that had already received or attempted to install the faulty updates, specific remediation steps were necessary to restore functionality and allow for the installation of the corrected updates. The reported symptoms varied based on the state of the update installation process on the client device.

The three main scenarios encountered by WSUS/SCCM customers reflected different levels of exposure to the faulty updates. Scenario 1 involved the update being cached on the server, but not yet deployed. Scenario 2 involved the update being downloaded and staged on the client device, awaiting a reboot for installation. Scenario 3 represented the most severe impact, where the update had been installed, and the device was subsequently unable to boot into Windows. Each scenario demanded a specific technical approach to rectify the situation without causing further disruption or data loss.

Issue Details and Workarounds¶

Understanding the progression of the issue across different stages of update deployment is key to applying the correct resolution. Below are the specific scenarios reported and the corresponding workarounds provided to mitigate the boot failures and related problems caused by the faulty October 10, 2017 updates (KB4041676/KB4041691).

Scenario 1: Faulty Updates Cached on Server¶

Issue: WSUS or SCCM administrators who synchronized updates before the publishing issue was corrected (approximately 4 PM PDT, October 10, 2017) may still have cached the problematic delta package versions of KB4041676 or KB4041691. These cached updates could potentially be deployed to clients unless action is taken. This scenario impacts the update distribution server itself rather than the client devices directly.

Workaround: The resolution for this scenario is straightforward and involves updating the server’s view of available patches. WSUS and SCCM administrators should initiate a rescan or synchronization of updates from Microsoft Update. This action ensures that the corrected versions of KB4041676 and KB4041691 are pulled down, overwriting or correctly flagging the previously cached faulty versions. In a hierarchical WSUS structure, it is essential to ensure that both upstream and downstream servers complete their synchronization processes successfully to propagate the corrected updates throughout the environment.

Scenario 2: Updates Downloaded and Staged on Client (Pending Reboot)¶

Issue: WSUS or SCCM managed devices that successfully downloaded and staged the problematic delta package versions of KB4041676 or KB4041691 before the server was corrected. These devices have the update files present on the system but have not yet completed the installation process by rebooting. If these devices were allowed to reboot, they would likely encounter boot failure issues as described in Scenario 3. The updates are in a pending state, waiting for the next restart to finalize installation.

Workaround: To prevent the boot failure, the pending installation needs to be safely aborted and the staged update files removed. This requires administrative privileges on the client device and is performed via the command prompt. The workaround involves stopping relevant Windows Update services, clearing the pending installation state, and using the Deployment Image Servicing and Management (DISM) tool to remove the staged package files. This process effectively rolls back the update preparation phase before the system attempts the problematic installation during boot.

The following commands, executed from an administrative command prompt, will perform the necessary cleanup:

@echo off

REM Stop all update related services
net stop usosvc
net stop wuauserv
net stop trustedinstaller

REM Delete pending.xml if it exists
takeown /f %windir%\winsxs\pending.xml >NUL 2>&1
icacls %windir%\winsxs\pending.xml /grant Everyone:F >NUL 2>&1
del %windir%\winsxs\pending.xml >NUL 2>&1

REM Modify the components hive
reg unload HKLM\Components >NUL 2>&1
reg load HKLM\ComponentsHive %windir%\system32\config\COMPONENTS
reg delete /f HKLM\ComponentsHive /v PendingXmlIdentifier >NUL 2>&1
reg delete /f HKLM\ComponentsHive /v PoqexecFailure >NUL 2>&1
reg delete /f HKLM\ComponentsHive /v ExecutionState >NUL 2>&1
reg delete /f HKLM\ComponentsHive /v RepairTransactionPended >NUL 2>&1
reg delete /f HKLM\ComponentsHive /v AIFailureInformation >NUL 2>&1
reg delete /f HKLM\ComponentsHive\Installers\RegKeySDTable /v Install >NUL 2>&1
reg delete /f HKLM\ComponentsHive\Installers\RegKeySDTable /v Uninstall >NUL 2>&1
reg delete /f HKLM\ComponentsHive\Installers\RegKeySDTable /v Uninstall >NUL 2>&1
reg unload HKLM\ComponentsHive

REM Stop Poqexec from running
reg delete /f HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Configuration /v DontRunPoqexecInSmss >NUL 2>&1
reg delete /f HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Configuration /v PoqexecCmdline >NUL 2>&1
reg delete /f "HKLM\System\CurrentControlSet\Control\Session Manager" /v SETUPEXECUTE >NUL 2>&1
REG ADD "HKLM\System\CurrentControlSet\Control\Session Manager" /v SETUPEXECUTE /t REG_MULTI_SZ /d \0 /f

dism /online /remove-package /PackageName:Package_for_RollupFix_Wrapper~31bf3856ad364e35~amd64~~15063.674.1.8 /norestart >NUL 2>&1
dism /online /remove-package /PackageName:Package_for_RollupFix_Wrapper~31bf3856ad364e35~x86~~15063.674.1.8 /norestart >NUL 2>&1
dism /online /remove-package /PackageName:Package_for_RollupFix_Wrapper~31bf3856ad364e35~amd64~~14393.1770.1.6 /norestart >NUL 2>&1
dism /online /remove-package /PackageName:Package_for_RollupFix_Wrapper~31bf3856ad364e35~x86~~14393.1770.1.6 /norestart >NUL 2>&1

Let’s break down the script’s actions. It first stops key Windows Update related services (usosvc, wuauserv, trustedinstaller) to prevent interference while system files are being modified. It then attempts to delete the pending.xml file, which often tracks pending operations for Windows Servicing (TrustedInstaller). This requires taking ownership and granting permissions first. The script then interacts with the COMPONENTS registry hive, which stores information about Windows components and pending installations, unloading and reloading it to modify specific values (PendingXmlIdentifier, PoqexecFailure, ExecutionState, etc.) that indicate the state of pending update transactions. Finally, it modifies entries related to Poqexec, a process that executes operations pending after a reboot, effectively disabling it from running the problematic update installation. The DISM commands target the specific package names associated with KB4041676 and KB4041691 for both x86 and x64 architectures on relevant Windows versions (indicated by the build numbers 15063 for v1703 and 14393 for v1607/Server 2016), removing them from the staged state on the system.

Explanation of Commands:
* net stop: Stops the specified service. Essential to prevent services from holding locks on files or registry keys being modified.
* takeown, icacls: Used to take ownership and grant full permissions to the pending.xml file, allowing it to be deleted even if system processes are holding it.
* del: Deletes the specified file.
* reg unload, reg load: Used to temporarily load a system registry hive (like COMPONENTS) under a temporary key (HKLM\ComponentsHive) so its contents can be modified while Windows is running.
* reg delete: Removes specified registry values or keys. These specific deletions target flags that signal pending installation operations.
* REG ADD: Used here to add a specific registry value (SETUPEXECUTE) under Session Manager. Setting it to \0 effectively clears any commands scheduled to run during the boot process before other parts of Windows load.
* dism /online /remove-package /PackageName:...: The Deployment Image Servicing and Management tool is used to remove a specific Windows package from the currently running online operating system image. The /norestart flag is used to prevent the system from attempting to reboot after package removal, as a reboot might trigger other pending issues.

Scenario 3: Updates Installed and Device Unable to Boot¶

Issue: This is the most critical scenario, where the faulty delta package version of KB4041676 or KB4041691 was fully installed, and upon reboot, the Windows device fails to start correctly. This often results in the system entering the Windows Recovery Environment (WinRE) or displaying a boot failure error message. The system files or configuration modified by the faulty update prevent Windows from loading the operating system.

Workaround: Resolution requires accessing the Windows Recovery Environment (WinRE) to perform system repair actions. The goal is to revert the system state to before the problematic update was installed or to manually remove the problematic update files and configuration changes from the offline operating system image. This process is more involved as the main operating system is not accessible.

Follow these steps only on a device that is failing to boot:

1. Ensure the device is connected to AC power before starting. Power on the device.
2. If the device fails to boot multiple times, Windows should automatically enter the Windows 10 Recovery Environment. On the Automatic Repair screen, select Advanced options. If it doesn’t enter WinRE automatically, you may need to manually force it by interrupting the boot process (e.g., powering off the device 2-3 times when the Windows logo appears).
3. Navigate through the options: Select Troubleshoot, then Advanced options.
4. First, attempt System Restore. If a system restore point created before the installation of KB4041676 or KB4041691 is available, use the wizard to restore the system to that earlier point. This is often the simplest and most effective solution if a suitable restore point exists. Follow the on-screen prompts to complete the restoration. If no relevant restore point is found, close System Restore and return to the Advanced options screen.
5. If System Restore is not an option, select Command Prompt from the Advanced options. You may be prompted to select a user account and enter its password. You must use a local administrator account. If you do not have a local administrator account or its credentials, you may need to create and use a Windows Recovery Drive or installation media to access the command prompt.

6. Once the Command Prompt window appears, the drive letter assigned to your Windows installation might not be C:. You can identify the correct drive letter by using commands like diskpart or simply by trying common letters (like C:, D:, E:) and listing directory contents (dir <drive letter>:\). Assuming the Windows directory is on drive D: for this example, you will need to load the software registry hive from the offline Windows installation. Run the following command, replacing <drive letter for windows directory> with the correct drive letter:
   

   reg load hklm\temp <drive letter for windows directory>\windows\system32\config\software
   

   
   Example (if Windows is on drive D:):
   

   reg load hklm\temp d:\windows\system32\config\software
   

   
   This command mounts the SOFTWARE hive from your offline Windows installation under a temporary key (hklm\temp) in the WinRE registry, allowing you to modify it.

7. With the software hive loaded, attempt to delete a specific registry value that might be causing the boot failure related to pending update sessions. Run the following command. If the registry value does not exist, the command will report an error, which is expected and can be ignored; proceed to the next step.
   

   reg delete "HKLM\temp\Microsoft\Windows\CurrentVersion\Component Based Servicing\SessionsPending" /v Exclusive
   

8. Unload the temporarily loaded software registry hive to avoid conflicts.
   

   reg unload HKLM\temp
   

9. Next, use the DISM tool to list all packages installed or pending installation in the offline Windows image. Replace <drive letter for windows directory> with the correct drive letter.
   

   dism.exe /image:<drive letter for windows directory> /Get-Packages
   

   
   Example (if Windows is on drive D:):
   

   dism.exe /image:d:\ /Get-Packages
   

   
   Examine the output. Look for packages where the State is listed as Install Pending. Identify the Package Name for any pending packages, particularly those related to KB4041676 or KB4041691 (their names will typically contain RollupFix and a build number like 15063 or 14393).

10. For each package identified in the previous step with State = Install Pending, run the following command to remove it from the offline image. Replace <drive letter for windows directory> with the correct drive letter and <package name> with the exact name listed by /Get-Packages.
    

    dism.exe /image:<drive letter for windows directory> /remove-package /packagename:<package name>
    

    
    Examples (replace ‘c:\’ with your actual Windows drive letter and package names with those found):
    

    dism.exe /image:c:\ /remove-package /packagename:Package_for_RollupFix_Wrapper~31bf3856ad365e35~amd64~~15063.674.1.8
    dism.exe /image:c:\ /remove-package /packagename:Package_for_RollupFix~31bf3856ad365e35~amd64~~15063.674.1.8
    dism.exe /image:c:\ /remove-package /packagename:Package_for_RollupFix_Wrapper~31bf3856ad365e35~amd64~~14393.1770.1.6
    dism.exe /image:c:\ /remove-package /packagename:Package_for_RollupFix~31bf3856ad365e35~amd64~~14393.1770.1.6
    

    
    You need to carefully identify the correct package names from the output of /Get-Packages for the specific architecture (amd64/x86) and build number (15063/14393) matching your system and the installed problematic update.

11. After removing all pending packages, close the Command Prompt window.

12. From the Choose an option or Troubleshoot screen in WinRE, select Continue (or Exit and continue to Windows 10) to attempt booting into the operating system. With the problematic pending updates removed, the system should now be able to boot correctly.

Once the system successfully boots after applying the workaround for Scenario 2 or 3, it is critical to ensure that the WSUS or SCCM server has been updated (Scenario 1 workaround completed) and that the client device subsequently downloads and installs the corrected versions of KB4041676 or KB4041691 to address the security vulnerabilities intended to be fixed by these updates. Administrators should verify the successful installation of the valid updates through their management tools or Windows Update history on the client.

Scenario	Description	Workaround Summary
1: Faulty updates cached on server	WSUS/SCCM synced faulty delta packages before correction.	Resync WSUS/SCCM with Microsoft Update.
2: Updates downloaded/staged on client	Client downloaded faulty updates but not yet rebooted.	Run script/commands from admin CMD to clear pending updates/state.
3: Updates installed, device fails to boot	Client installed faulty updates and cannot boot into Windows.	Use Windows Recovery Environment (WinRE) for System Restore or manual package removal via DISM/Command Prompt.

This incident served as a significant reminder of the complexities in distributing software updates at scale and the importance of robust testing and validation processes, both by the vendor and by enterprise IT departments before wide-scale deployment. While the issue was specific to a particular update and distribution method in 2017, the principles of identifying the problem, understanding its manifestation across different system states (cached, staged, installed), and providing targeted workarounds remain fundamental to patch management and system recovery.

What are your experiences dealing with complex Windows update issues like this one in enterprise environments? Have you encountered similar situations where manual intervention via recovery tools was necessary? Share your thoughts and insights in the comments below.