Windows Cumulative Updates KB5129195 fail leading to 0x139 KERNEL_SECURITY_CHECK_FAILURE

Question

Windows Cumulative Updates KB5129195 fail leading to 0x139 KERNEL_SECURITY_CHECK_FAILURE

LostInKadath 0

Every attempt to install the August/September 2026 cumulative updates on Windows 11 25H2 ends the same way. The machine restarts into the servicing phase, hits a KERNEL_SECURITY_CHECK_FAILURE (0x139, parameter 1 = 2, FAST_FAIL_STACK_COOKIE_CHECK_FAILURE) and cannot start Windows. The only recovery is booting WinRE and running DISM /RevertPendingUpdates. Windows Update then reports 0x800F0845.

It has reproduced on three different cumulative updates over three weeks, and it survived every mitigation I could apply without a kernel debugger. I can't obtain a dump (details below), so I'm reporting the reproducible pattern and the exclusions in case it matches other reports or helps triage.

Environment

Acer Nitro AN515-55; Intel Core i7-10750H (Comet Lake); 32 GB RAM
BIOS: Insyde V2.06, 19.08.2021 (OEM no longer ships firmware or Secure Boot database updates for this model)
Windows 11 25H2, installed build 26200.9168 (unchanged for the whole period)
GPUs: Intel UHD (drives the display) + NVIDIA GTX 1650 (driver 32.0.16.1692)
Secure Boot enabled.
Disclosure: the Platform Key is my own, because the OEM stopped providing updates. Microsoft's KEK and db certificates (2011 and 2023 CAs, including Windows UEFI CA 2023) are enrolled alongside it. The DBX update applied by this same servicing run succeeded (ApplySecureBootUpdateEx succeeded for DBX, hr 0), so I don't believe the trust chain is the cause. I'm disclosing it so you can rule it out yourselves.
Memory integrity (HVCI) / VBS: on by default; tested off (see below)

Steps to reproduce

Settings → Windows Update → install KB5124008 (or KB5120998, or KB5129195).
Restart when prompted.
Machine bugchecks during the servicing boot. Windows does not come up.
Boot WinRE → Command Prompt → DISM /Image:E:\ /Cleanup-Image /RevertPendingActions, then boot normally.
Windows Update shows the update as failed with 0x800F0845; UBR is still 9168.

Bugcheck

0x139 (KERNEL_SECURITY_CHECK_FAILURE), read from the screen on one attempt (KB5120998):

0x0000000000000002, 0xffffcd8340c06a50, 0xffffcd8340c069a8, 0x0000000000000000.

Parameter1 = 2 is FAST_FAIL_STACK_COOKIE_CHECK_FAILURE (a kernel stack buffer overrun caught by the /GS cookie).

What the logs show (identical on every attempt)

CBS.log: shutdown phase completes (Doqe: [Forward] Staging driver updates, Count 109, Installing driver updates, Count 109, poqexec status 0x0), then ExecuteState becomes CbsExecuteStateUnstageDrivers.
After the crash and WinRE revert, the next normal boot logs: Retrieved original failure status: 0x00000000, last forward execute state: CbsExecuteStateStageDrivers → Startup: current ExecuteState is CbsExecuteStateDeviceInstalls | CbsExecuteStateFlagRollback → Setting ExecuteState key to: CbsExecuteStateFailed → Setting original failure status: 0x80004005.
setupapi.dev.log has no boot-session entry for the servicing boot at all, so the crash occurs before device-install logging opens. setupapi.offline.log contains only my WinRE dismhost.exe (X:) sections.
No MEMORY.DMP or minidump is produced, and no Kernel-Power 41 / 1001 event is logged, even though CrashControl is set to kernel dump, AutoReboot off, with a 16 GB C:\dedicateddump.sys present. The crash appears to happen before the dump stack is armed.

Failed attempts (WU history)

0x800F0845: KB5120998 (three attempts, 28 Aug – 3 Sep); KB5124008 (five attempts on 9 Sep); KB5129195 (two attempts on 18 Sep).
KB5126052 (.NET Framework) failed once with the same code on 9 Sep in the same servicing session, then installed successfully later that day.
Other packages install normally (Defender platform/definitions, .NET 8/9, Store apps).

What I excluded (each tested, crash unchanged)

SuspectTestThird-party kernel drivers: VirtualBox (VBoxSup, VBoxNetLwf, VBoxNetAdp, VBoxUSBMon), OpenVPN (ovpn-dco, tap0901, tap_ovpnconnect), npcapDisabled and confirmed stopped (npcap fully uninstalled)Intel HAXMRemovedNVIDIA GPU/audio driversGPU and both audio functions disabled at the PnP level; confirmed still disabled after the attemptDriver store bloatPruned superseded packages, 217 → 109Component store corruptionDISM /RestoreHealth (repaired 155/155), sfc /scannowMemory integrity / VBSCore isolation off and VT-x/VT-d disabled in firmware (SecurityServicesRunning = 0)Secure Boot trust chainInspected PK/KEK/db; DBX update applied successfully## Caveats on my own testing

During the VBS-off test one of the OpenVPN TAP services (tap0901) had reverted to running. During an earlier test, sc config … start= disabled on npcap did not persist until I uninstalled it. My combined "all third-party drivers out" test was clean only for the npcap-uninstalled run.
I only captured the bugcheck screen parameters once. I did not record them for the later attempts.

What would help

A way to capture a dump from the servicing boot (or a supported debug procedure for it).
Whether this matches a known issue in the 109-package driver-staging batch (Doqe: Staging driver updates, Count 109), or in the servicing stack included with these cumulatives.

Relevant entry on Feedback Hub (logs attached, but are accessible only for Microsoft): https://aka.ms/AA13j7u6

0 comments

2 answers

Your answer

Answer 1

@Alex-L and @LostInKadath

I'm working on a machine that is getting this same error after a recent Windows Update. Unfortunately, running "DISM /Image:E:\ /Cleanup-Image /RevertPendingActions" results in Error: 0x8000ffff

Trying to boot to the Recovery Environment from the installation itself gave a vpci.sys 0xc0000098 error. The only way to get into WinRE was by booting a Windows installation USB. I tried replacing vpci.sys by extracting it from the install.wim on the bootable USB, but it didn't help.

I needed to get this user up and running, so I gave up and wiped the computer with a fresh Windows 11 installation.

Answer 2

Alex-L 13,080 Microsoft External Staff Moderator

Hi LostInKadath

Thank you for the detailed troubleshooting information. Based on what you've documented, this does not look like a typical component store corruption or Windows Update cache issue. The consistent 0x139 (FAST_FAIL_STACK_COOKIE_CHECK_FAILURE) occurring during the servicing boot phase, combined with CBS stopping around driver staging/device installation and the absence of a dump file, suggests the failure is occurring very early in the update process.

Unfortunately, as a public community forum, we do not have access to internal Microsoft debugging data, Feedback Hub submissions, or escalation channels that would allow us to determine whether this matches an existing servicing-stack or update regression.

Since you have already tested the common mitigations (DISM, SFC, VBS/HVCI disabled, third-party driver removal, driver store cleanup, and update rollback), I recommend continuing through Feedback Hub and opening a Microsoft Support case if available, as analysis of the servicing boot failure would likely require internal diagnostics or kernel debugging that cannot be performed from the forum.

If you obtain additional data such as a servicing-boot dump, setupmem.dmp, or a kernel-debugger trace, feel free to post the findings here, as that may help identify the offending driver or component.

LostInKadath 0 Reputation points

2026-09-21T09:41:57.47+00:00

Thanks @Alex-L , I've already opened a case on Feedback Hub (find the link provided at the end of the post). And, as I've written before, there is no servicing-boot dump or setupmem.dmp. I don't have an opportunity to attach with kd for now, but will definitely keep the community on touch with this issue -- it might be useful for others.
Alex-L 13,080 Reputation points Microsoft External Staff Moderator

2026-09-22T14:40:00.7533333+00:00

Hi LostInKadath

Thanks for the follow-up. Given that you've already submitted a Feedback Hub report and confirmed that no servicing-boot dump or SetupMem.dmp is generated, there isn't much further troubleshooting the community can realistically perform at this stage. The issue appears well documented, reproducible, and isolated to the servicing boot process. If you later identify the root cause or receive information from Microsoft, please consider posting an update, as it may help others encountering the same 0x139 / 0x800F0845 update failure pattern.