Windows 11: Component Store (CBS/WinSxS) Corruption Occurs Within Days After Clean Installation

Question

Windows Version: Windows 11 Home Build: 26200.8973 License: Retail Hardware:

ASUS PRIME B550M‑K ARGB

Ryzen 5 5600X

32GB DDR4

RTX 4060

Samsung 990 Pro (latest firmware)

BIOS:

• M.2 Gen4
• DOCP enabled
• Secure Boot enabled
• No other custom settingsWindows Version: Windows 11 Home Build: 26200.8973 License: Retail Hardware:
  • ASUS PRIME B550M‑K ARGB
  • Ryzen 5 5600X
  • 32GB DDR4
  • RTX 4060
  • Samsung 990 Pro (latest firmware)
  BIOS:
  • M.2 Gen4
  • DOCP enabled
  • Secure Boot enabled
  • No other custom settings

Summary of the issue

After every clean installation, Windows 11 becomes unstable within 7–14 days. The instability always follows the same pattern:

CBS.log loop

WinSxS PendingDeletes / PendingRenames filling

DISM /startcomponentcleanup corrupts the component store

DISM /restorehealth requires /source

Shutdown / restart timing becomes inconsistent

Windows Defender engine sometimes fails to load

Boot time becomes non‑deterministic

WSL2 uninstall causes permanent boot delay

User Profile Service 1512 appears on some installations

Linux (Ubuntu) on the same hardware is fully stable and deterministic.

---

Symptoms

• CBS.log loop starts suddenly
• CPU spikes during CBS activity
• WinSxS temp folders fill
• DISM cleanup corrupts the store
• DISM restorehealth cannot repair without /source
• Cleanmgr cannot clear pending operations
• Shutdown sometimes takes 1 second, sometimes longer
• Boot time changes after WSL2 uninstall
• Windows Defender engine loads repeatedly
• User Profile Service error 1512 on some installs

---

Logs

ExecuteState = 0xffffffff LastProgress = FFFFFFFF0000000000000000000000000100000000000000 PendingDeletes and PendingRenames filling Corrupt = 0 (but CBS loop still occurs)

---

What I tested

• Secure erase before installation
• Fresh MCT USB
• No OEM drivers
• No third‑party software
• Fast startup disabled
• hiberfil.sys disabled
• DOCP stable (RAM test passed)
• NVMe SMART: no media errors, no CRC errors
• ACPI behavior tested on Linux (stable)

---

Component Based Servicing (CBS) Registry Evidence

Below is the CBS registry state captured after the corruption begins. The values indicate that the Servicing Stack is not in an active transaction (ExecuteState = 0xffffffff), yet CBS activity continues in the background (CBS.log loop, PendingDeletes/PendingRenames filling). This suggests an inconsistent or incomplete servicing state.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing

ProcessorArchitecture REG_DWORD 0x9

EnableLog REG_DWORD 0x1

NextExecutionSequence REG_DWORD 0x27

LastMappingPackageCache REG_DWORD 0x0

LastModified_UTC REG_SZ 2026/08/03/20:01:42

BuildBranch REG_SZ BuildBranchMacro

DisableRemovePayload REG_DWORD 0x1

EnableDpxLog REG_DWORD 0x1

FeatureCategory REG_SZ e104dd76-2895-41c4-9eb5-c483a61e9427

RepairCategory REG_SZ 631f8288-2457-41f4-bb81-63df924ba94c

ExecuteState REG_DWORD 0xffffffff

DeviceInfoGatherSuccessful REG_DWORD 0x1

FodInventoryHash REG_DWORD 0x1d87ccd9

FodInventoryTimestamp REG_DWORD 0x4278

LCUReoffer REG_DWORD 0x0

LastResetBase_UTC REG_SZ 2026/07/10/21:53:04

HangDetect REG_DWORD 0x0

LastProgress REG_BINARY FFFFFFFF0000000000000000000000000100000000000000

CanceledCurrentFailedTransaction REG_DWORD 0x0

SessionIdHigh REG_DWORD 0x1dd23f8

SessionIdLow REG_DWORD 0xc19bb371

DoqTime REG_DWORD 0x0

DoqCount REG_DWORD 0x1

PoqTime REG_DWORD 0x0

PoqCount REG_DWORD 0x1

RptTime REG_DWORD 0x0

RptCount REG_DWORD 0x1

CountryCode REG_SZ TR

LCUUIUninstallVersion REG_SZ 26100.8894.1.8

LCUUIUninstallTime REG_DWORD 0x6a69b67d

AutoRepairNeeded REG_DWORD 0x0

Corrupt REG_DWORD 0x0

Subkeys:

ApplicabilityEvaluationCache

CapabilityIndex

ComponentDetect

DriverOperations

Features on Demand

Interface

Notifications

PackageDetect

PackageIndex

Packages

RemovedEditionBasedSelectableUpdates

SessionsPending

UpdateDetect

Version

---

Similar reports

https://learn.microsoft.com/en-us/answers/questions/3854477/bsod-occurs-when-shutting-down-computer

https://learn.microsoft.com/en-us/answers/questions/5818552/user-profile-service-error-1512-access-denied-duri

https://learn.microsoft.com/en-us/answers/questions/5805497/windows-11-25h2-home-fails-to-start-vsm-during-boo

---

Question

Is this a known issue with Windows 11 Servicing Stack or Component Store initialization? Is there any diagnostic method to verify whether the Servicing Stack starts in an incomplete state after installation?

Answer 1

Hi NPLGlitcherPatcher,

Based on your description, it appears that the servicing stack and component store are entering an inconsistent state after the system has been running for several days. Since the behavior persists across clean installations and the hardware appears stable under Linux, reviewing the servicing logs may help identify which component or update operation is repeatedly triggering the CBS activity.

As a few targeted checks, please try:

1, Run these commands separately in Command Prompt (Admin):

DISM /Online /Cleanup-Image /ScanHealth
sfc /scannow

• and note any reported corruption.

2, Collect the following logs after the CBS loop starts:

• %windir%\Logs\CBS\CBS.log
• %windir%\Logs\DISM\dism.log

3, Check whether the behavior begins shortly after a Windows update, Defender platform update, optional feature installation, or WSL-related change.

4, Avoid running /StartComponentCleanup repeatedly while the issue is active, as it may make troubleshooting more difficult.

If you can share the relevant CBS.log or DISM.log entries from the time the issue begins, the repeating package or component name may provide a clearer indication of what is keeping the servicing process active.

I hope this helps point you in the right direction. Please feel free to post the log excerpts, and the community can take a closer look at the servicing activity.

---

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.