Full Diagnostic Tree & Step-by-Step Overview
How did you measure the size of the WinSxS folder, and what issue is it currently causing on drive C:?
- Windows Explorer reports WinSxS consuming 15GB-30GB+ based on folder properties (Possible hard link double-counting).
- DISM AnalyzeComponentStore explicitly confirms that 'Component Store Cleanup Recommended' is YES.
- WinSxS contains large amounts of superseded updates after a major Windows feature upgrade or patch cycle.
- DISM /StartComponentCleanup hangs, fails with error codes (e.g., 0x800f081f, 14098), or fails to free space.
NTFS Hard Link Reporting Miscalculation. What is the breakdown when running DISM Component Store Analysis?
- Windows Explorer displays 20GB+, but DISM reports 'Actual Size of Component Store' is significantly smaller.
- DISM analysis shows 'Shared with Windows' makes up the majority of the reported folder size.
- WinSxS Temp or Manifests subdirectories contain millions of orphaned temporary files (`CbsTemp` / `Temp`).
- File repository contains duplicate driver packages (`System32\DriverStore\FileRepository`) alongside WinSxS.
NTFS Hard Link Double-Counting Illusion in File Explorer
Solution:
Root Cause: NTFS Hard Link Pointer Double-Counting via Standard File Queries
Windows Explorer and third-party disk visualization tools (like TreeSize or WinDirStat) calculate directory sizes by summing file byte counts across folder paths. The WinSxS (Windows Side-by-Side) directory is the single source of truth for all operating system binaries (dll, exe, sys). Files appearing in C:\Windows\System32 or C:\Windows\SystemApps are not copies; they are NTFS Hard Links (HardLink pointers) that reference the identical physical clusters stored in WinSxS.
When standard disk analyzers scan C:\Windows, they count the physical bytes once in WinSxS and again for every hard link in System32. This creates an illusion that WinSxS is consuming 20GB-30GB when its actual unique memory footprint on the drive is substantially smaller.
# Diagnostic Verification:
1. Open Command Prompt as Administrator (Ctrl + Shift + Esc > Run new task > cmd with administrative privileges).
2. Run the official DISM Component Store analysis tool:
dism /Online /Cleanup-Image /AnalyzeComponentStore
3. Examine the output report fields:
Raw Size of Component Store: Total size reported by File Explorer (includes hard links).Actual Size of Component Store: True disk space consumed solely by WinSxS.Shared with Windows: Space utilized by system files referenced elsewhere via hard links.Backups and Disabled Features: Space occupied by rollback payload files and features.# Step-by-Step Fix:
1. Evaluate True Reclaimable Space:
Inspect the Component Store Cleanup Recommended line in the DISM output.If it reports No, performing aggressive manual deletion will not free meaningful disk space and risks breaking OS component integrity.2. Perform Safe Automated Component Store Maintenance:
If cleanup is recommended, execute the standard maintenance task: dism /Online /Cleanup-Image /StartComponentCleanup
3. Execute the Task Scheduler Maintenance Job Manually:
Run the built-in Windows background task that cleans up component stores: schtasks /Run /TN "\Microsoft\Windows\Servicing\StartComponentCleanup"
# Prevention & Long-Term Monitoring:
Never manually delete files directly from C:\Windows\WinSxS using File Explorer or third-party file unlockers; doing so destroys NTFS hard link metadata and corrupts the OS servicing stack.
Shared System File Allocation & Windows Servicing Stack Design
Solution:
Root Cause: Mandatory Windows Servicing Architecture Protection
In the Windows Component-Based Servicing (CBS) architecture, files listed under *Shared with Windows* in dism /AnalyzeComponentStore represent active OS components required for normal system operation. Because these files are hard-linked to running system executables in C:\Windows\System32, they cannot be deleted or compressed without breaking system boot integrity or application runtime dependencies.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Run: dism /Online /Cleanup-Image /AnalyzeComponentStore
3. Verify if Shared with Windows accounts for over 80% of the reported Raw Size of Component Store.
# Step-by-Step Fix:
1. Reclaim Space from Disabled Features (Optional Feature Payloads):
Query optional features configured to payload-staged mode: dism /Online /Get-Features /Format:Table
Remove payload files for unused optional features to free space inside WinSxS: dism /Online /Disable-Feature /FeatureName:TFTP /Remove
dism /Online /Disable-Feature /FeatureName:LegacyComponents /Remove
2. Compress Inactive WinSxS Components via CompactOS:
Use LZX or XPRESS compression algorithms on operating system binaries without breaking hard link integrity: compact /CompactOS:always
3. Verify Compression Status:
Confirm that compacting reduced system drive consumption: compact /CompactOS:query
# Prevention & Long-Term Monitoring:
Maintain at least 15% free space on drive C: to ensure Windows Update can process LCU (Latest Cumulative Update) patching without temporary workspace exhaustion.
Orphaned `CbsTemp` and Servicing Scratch Log Accumulation
Solution:
Root Cause: Interrupted Servicing Stack Transactions & CbsTemp File Accumulation
When a cumulative update, DISM operation, or SFC scan is interrupted by a force restart, crash, or power loss, the Component-Based Servicing engine leaves uncommitted temporary cab files and staging logs inside C:\Windows\CbsTemp and C:\Windows\Logs\CBS. Over time, these orphaned temporary directories can accumulate tens of gigabytes of uncompressed text logs and intermediate update payloads.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Check the size of the temporary servicing directories:
dir /s C:\Windows\CbsTemp
dir /s C:\Windows\Logs\CBS
3. If CbsTemp contains gigabytes of .cab or .log files, orphaned servicing files are confirmed.
# Step-by-Step Fix:
1. Stop Windows Update and Modules Installer Services:
Open Command Prompt as Administrator and run: net stop wuauserv
net stop TrustedInstaller
2. Clear CbsTemp Directory:
Force delete all temporary files in the servicing directory: del /f /s /q C:\Windows\CbsTemp\*.*
3. Clear CBS Log Cache:
Remove stale CBS log archives: del /f /q C:\Windows\Logs\CBS\*.log
del /f /q C:\Windows\Logs\CBS\*.cab
4. Restart Services:
Execute: net start TrustedInstaller & net start wuauserv# Prevention & Long-Term Monitoring:
Ensure system updates complete fully before shutting down or restarting the computer.
DriverStore FileRepository Stale Driver Package Accumulation
Solution:
Root Cause: Outdated OEM Driver Version Staging in DriverStore
While closely associated with WinSxS bloat, substantial C: drive storage loss often occurs in C:\Windows\System32\DriverStore\FileRepository. Every time graphics drivers (NVIDIA, AMD, Intel) or peripheral devices update, Windows stages the complete old driver package in FileRepository to allow rollback capability. Over multiple update cycles, superseded GPU driver builds can consume 20GB+ of storage.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Check the size of the DriverStore directory:
powershell "(Get-ChildItem C:\Windows\System32\DriverStore\FileRepository | Measure-Object -Property Length -Sum).Sum / 1GB"
3. If size exceeds 10GB, stale driver accumulation is present.
# Step-by-Step Fix:
1. Enumerate Installed Third-Party Drivers via PNPUTIL:
In administrative Command Prompt, run: pnputil /enum-drivers
2. Clean Up Superseded Drivers using DISM:
Remove old versions of drivers that are no longer active: dism /Online /Cleanup-Image /StartComponentCleanup
3. Delete Stale Driver Packages via Driver Store Explorer (pnputil method):
Target and remove specific old driver INF published names (e.g., oem12.inf): pnputil /delete-driver oem12.inf /uninstall
# Prevention & Long-Term Monitoring:
Select 'Clean Install' when updating GPU drivers to prevent staging redundant legacy package binaries.
DISM confirms Cleanup Recommended = YES. Which component category is occupying the largest proportion of WinSxS space?
- Superseded Cumulative Updates (LCU) payloads and uninstalled patch backups.
- Windows OS Feature Upgrades backup files (`Windows.old` or OS rollback containers).
- Disabled Windows Optional Features payloads (Staged components).
- Language packs and regional component staging payloads.
Superseded Update Consolidation & Base Reset (`/ResetBase`) Execution
Solution:
Root Cause: Accumulation of Superseded Patch Delta Packages
Windows Cumulative Updates (LCU) append new binary versions to the Component Store while retaining older superseded patch files in WinSxS. This architecture allows users to uninstall recent updates if bugs occur. Once a monthly update is verified as stable, these superseded baseline binaries become redundant overhead.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Run Component Store analysis:
dism /Online /Cleanup-Image /AnalyzeComponentStore
3. Confirm that Component Store Cleanup Recommended states Yes and Backups and Disabled Features occupies multiple gigabytes.
# Step-by-Step Fix:
1. Perform Standard Component Store Cleanup:
Execute the basic cleanup command to delete superseded update binaries: dism /Online /Cleanup-Image /StartComponentCleanup
2. Perform Deep Base Reset (/ResetBase):
Permanently purge all superseded versions of every component in the store (Note: This prevents rolling back existing cumulative updates): dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase
3. Reset Windows Update Agent Cache (Optional):
Stop update services and clear software download workspace: net stop wuauserv
del /f /q /s C:\Windows\SoftwareDistribution\Download\*.*
net start wuauserv
# Prevention & Long-Term Monitoring:
Run the /ResetBase command after major Windows cumulative updates confirm long-term stability.
Windows Upgrade Rollback Repository (`Windows.old` & `$Windows.~BT`) Retention
Solution:
Root Cause: Windows Feature Update Recovery Image Retention
When upgrading between major Windows 11/10 builds, the installer creates a complete recovery backup of the previous operating system state in C:\Windows.old and staging containers in C:\$Windows.~BT. These directories store system binaries, WinSxS state snapshots, and user profile backups to allow rolling back to the previous OS build within 10 days.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Check for the existence and size of upgrade recovery folders:
dir /a C:\Windows.old
dir /a C:\$Windows.~BT
3. If these directories exist, 15GB to 30GB+ of space is locked in rollback retention.
# Step-by-Step Fix:
1. Remove Rollback Backups via DISM / Storage Sense:
Open Command Prompt as Administrator and execute: dism /Online /Cleanup-Image /StartComponentCleanup
2. Delete Windows.old via Cleanmgr / PowerShell:
Force execution of the OS Setup Clean task using cleanmgr elevated flags: cleanmgr /sagerun:64
Or delete via administrative PowerShell: Remove-Item -Path "C:\Windows.old" -Recurse -Force -ErrorAction SilentlyContinue
3. Remove Staged Update Folders:
Purge hidden setup folders: rmdir /s /q "C:\$Windows.~BT"
rmdir /s /q "C:\$Windows.~WS"
# Prevention & Long-Term Monitoring:
Enable Storage Sense (Settings > System > Storage > Storage Sense) to automatically purge previous Windows installations after the 10-day rollback window expires.
Payload Staged Optional Features Purge (`/Remove` Flag)
Solution:
Root Cause: Retained Staged Payloads for Disabled Windows Features
When optional Windows features (such as Internet Information Services, Hyper-V, Windows Sandbox, or SNMP) are disabled via Control Panel, Windows does not delete their source binaries. Instead, it transitions them to a Disabled with Payload Removed or Staged state inside WinSxS so they can be re-enabled without installation media.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. List disabled features that still retain binary payloads in WinSxS:
dism /Online /Get-Features | findstr /i "Disabled"
# Step-by-Step Fix:
1. Remove Feature Payloads Completely from WinSxS:
Execute DISM specifying the /Remove parameter to delete source binaries from disk: dism /Online /Disable-Feature /FeatureName:MSMQ-Container /Remove
dism /Online /Disable-Feature /FeatureName:Xps-Viewer /Remove
2. Mass Purge All Disabled Feature Payloads:
Run component cleanup with feature removal enabled: dism /Online /Cleanup-Image /StartComponentCleanup
3. Re-installing Removed Features (If Needed Later):
If a removed feature is needed in the future, install it by pulling source binaries from Windows Update: dism /Online /Enable-Feature /FeatureName:Xps-Viewer /DownloadPackage
# Prevention & Long-Term Monitoring:
Use /Remove whenever disabling unused Windows features on low-capacity storage drives (e.g., 128GB SSDs).
Unused Language Pack & Regional Font Component Removal
Solution:
Root Cause: Unused Language Pack Component Staging
Pre-built OEM Windows installations or enterprise images frequently include multiple language packs and regional font packages staged inside WinSxS. Each language pack contains localized MUI files, help documentation, and speech recognition models that consume storage space.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Query all installed language packs:
dism /Online /Get-Intl
lpksetup /r
# Step-by-Step Fix:
1. Enumerate Installed Language Package Names:
Run: dism /Online /Get-Packages | findstr /i "LanguagePack"2. Remove Unused Language Packs via DISM:
Remove target language package (replace with actual package name found above): dism /Online /Remove-Package /PackageName:Microsoft-Windows-Client-LanguagePack-Package~31bf3856ad364e35~amd64~es-ES~10.0.22621.1
3. Uninstall Language Packs via LPKSETUP GUI:
Press Win + R, type lpksetup, hit Enter.Select Uninstall display languages, select unused languages, and click Next.4. Run Base Component Cleanup:
Finalize removal: dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase# Prevention & Long-Term Monitoring:
Only install language packs as required via Settings > Time & language > Language & region.
WinSxS folder expanded rapidly after a specific OS operation. What event preceded the growth?
- Installed a major Cumulative Update (LCU) or Patch Tuesday update package.
- Executed `sfc /scannow` or `DISM /RestoreHealth` repair operations.
- Installed multiple versions of .NET Framework or C++ Redistributable packages.
- Upgraded device drivers or installed OEM software suites.
Cumulative Update Differential Staging & Reverse Delta Retention
Solution:
Root Cause: Express Differential Delta Staging & Reverse Delta Storage
Modern Cumulative Updates use Express Delta patching. To apply updates quickly, Windows stores forward deltas (new code) and reverse deltas (data required to reconstruct the previous version if uninstalled) inside WinSxS. Until the update execution is consolidated by the automated background maintenance task, both version sets reside in the component store simultaneously.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Query recent update package states:
dism /Online /Get-Packages
3. Check if recent packages are listed as Staged or Installed alongside older superseded builds.
# Step-by-Step Fix:
1. Force Automated Component Cleanup Task Execution:
Trigger the official Windows servicing scheduled task: schtasks /Run /TN "\Microsoft\Windows\Servicing\StartComponentCleanup"
2. Execute Immediate Offline/Online Component Purge:
Run: dism /Online /Cleanup-Image /StartComponentCleanup3. Reset Base Image (If Update is Stable):
To permanently commit the update and discard reverse delta rollback files: dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase
# Prevention & Long-Term Monitoring:
Allow the system to remain powered on idle for 30 minutes post-update to permit automated background servicing tasks to complete.
SFC / DISM Component Repair Source File Staging
Solution:
Root Cause: DISM Component Store Source Payload Caching
When running sfc /scannow or dism /Online /Cleanup-Image /RestoreHealth, Windows downloads fresh component payloads from Windows Update to replace corrupted files in WinSxS. These repaired assemblies are staged into WinSxS and cached in C:\Windows\Logs\CBS to prevent future corruption errors.
# Diagnostic Verification:
1. Check C:\Windows\Logs\CBS\CBS.log for recent [SR] Repairing corrupted file entries.
2. Inspect C:\Windows\Logs\DISM\dism.log for component staging operations.
# Step-by-Step Fix:
1. Verify Component Store Health:
Confirm that no corruption remains: dism /Online /Cleanup-Image /CheckHealth
2. Clean Up Servicing Logs and Staging Cache:
Purge intermediate repair logs: del /f /q C:\Windows\Logs\CBS\*.log
del /f /q C:\Windows\Logs\DISM\*.log
3. Run Standard Component Cleanup:
Consolidate repaired files: dism /Online /Cleanup-Image /StartComponentCleanup
# Prevention & Long-Term Monitoring:
Run dism /Online /Cleanup-Image /StartComponentCleanup after completing system repairs.
Side-by-Side (.NET & C++ Runtime) Assembly Version Coexistence
Solution:
Root Cause: Native Side-by-Side Assembly Architecture (.NET & Visual C++ Runtimes)
The original architectural purpose of WinSxS (Windows Side-by-Side) was to resolve 'DLL Hell' by allowing different applications to run different versions of shared runtime libraries simultaneously. When software requiring legacy Visual C++ Redistributables (2005, 2008, 2012, 2015-2022) or .NET Framework assemblies is installed, Windows places each version in a separate subfolder inside WinSxS.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Check for installed Visual C++ runtime versions:
powershell "Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like '*Visual C++*'}"
3. Inspect WinSxS subdirectories starting with amd64_policy.vc or x86_policy.vc.
# Step-by-Step Fix:
1. Consolidate Visual C++ Runtimes:
Uninstall legacy, standalone Visual C++ redistributable packages that have been superseded by the unified Visual C++ 2015-2022 Redistributable.2. Run DISM Component Cleanup:
Consolidate orphaned runtime manifest links: dism /Online /Cleanup-Image /StartComponentCleanup
3. Remove Outdated .NET Framework Targeting Packs:
Uninstall old .NET Developer Packs and SDKs via Settings > Apps > Installed apps if not actively developing software.# Prevention & Long-Term Monitoring:
Install the latest cumulative Visual C++ Redistributable package rather than standalone legacy installers.
OEM Driver Payload Staging in Component Store
Solution:
Root Cause: Driver Package Manifest Staging in WinSxS
When new device drivers are installed, Windows creates manifest entries and copies payload files into WinSxS\Manifests and WinSxS subdirectories in addition to DriverStore\FileRepository. This ensures driver rollback functionality is preserved within the servicing stack.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Query installed driver packages:
dism /Online /Get-Drivers
# Step-by-Step Fix:
1. Clean Up Superseded Drivers via DISM:
Execute component cleanup to remove obsolete driver manifests: dism /Online /Cleanup-Image /StartComponentCleanup
2. Remove Specific Stale Driver INF Packages:
Identify third-party driver oemXX.inf names and remove outdated builds using pnputil: pnputil /delete-driver oemXX.inf /uninstall
# Prevention & Long-Term Monitoring:
Use DISM component cleanup after major graphics or chipset driver updates.
DISM /StartComponentCleanup fails or throws an error. Which error code or failure state is encountered?
- Error 0x800f081f or 0x800f0905 (Source files could not be found / CBS store corrupt).
- Error 14098 or 0x800f0a12 (ERROR_SXS_COMPONENT_STORE_CORRUPT).
- DISM cleanup command hangs indefinitely at 10%, 20%, or 50% without error.
- Error 0x80070005 (Access Denied / TrustedInstaller permissions blocked).
DISM Error 0x800f081f / 0x800f0905 - Source Files Missing in Component Store
Solution:
Root Cause: Missing Assembly Manifests in WinSxS Store
Error 0x800f081f occurs during DISM /StartComponentCleanup when the servicing engine attempts to verify a component package manifest before deletion, but finds that the manifest or payload file in WinSxS\Manifests is missing or corrupted. The cleanup process halts to prevent breaking package dependencies.
# Diagnostic Verification:
1. Open C:\Windows\Logs\CBS\CBS.log or C:\Windows\Logs\DISM\dism.log in Notepad.
2. Search for the error string 0x800f081f or Marking package failed.
3. Identify the missing package identity (e.g., Package_for_RollupFix...).
# Step-by-Step Fix:
1. Repair Component Store using Online Windows Update Source:
Open Command Prompt as Administrator and run: dism /Online /Cleanup-Image /RestoreHealth
2. Repair Component Store using ISO Source (If Online Repair Fails):
Mount a matching Windows 11/10 ISO to a drive letter (e.g., D:).Repair the store using install.wim as explicit source: dism /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:1 /LimitAccess
3. Execute SFC Repair:
Run: sfc /scannow4. Re-attempt DISM Cleanup:
Run: dism /Online /Cleanup-Image /StartComponentCleanup# Prevention & Long-Term Monitoring:
Always perform /RestoreHealth prior to executing /StartComponentCleanup /ResetBase on systems with a history of update failures.
DISM Error 14098 - Component Store Structural Corruption
Solution:
Root Cause: Critical SXS Component Store Schema Corruption
Error 14098 (ERROR_SXS_COMPONENT_STORE_CORRUPT) indicates that the internal transaction registry hives (COMPONENTS or SCHEMA) governing the WinSxS directory structure are corrupted. The servicing engine cannot parse the component dependency graph.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Run DISM store check:
dism /Online /Cleanup-Image /CheckHealth
3. Output will state The component store is repairable or The component store is corrupt.
# Step-by-Step Fix:
1. Execute RestoreHealth Command:
Open administrative Command Prompt and run: dism /Online /Cleanup-Image /RestoreHealth
2. Reset Windows Update / Servicing Components:
Stop servicing services: net stop wuauserv
net stop bits
net stop TrustedInstaller
Rename software distribution cache: ren C:\Windows\SoftwareDistribution SoftwareDistribution.bak
Restart services: net start TrustedInstaller
net start bits
net start wuauserv
3. Execute Cleanup Task:
Run: dism /Online /Cleanup-Image /StartComponentCleanup# Prevention & Long-Term Monitoring:
Run regular disk health checks (chkdsk C: /f) to prevent file system corruption from damaging servicing hives.
DISM Process Hang / Background Lock in `TiWorker.exe`
Solution:
Root Cause: Windows Modules Installer Worker (TiWorker.exe) Thread Stalling
When dism /Online /Cleanup-Image /StartComponentCleanup hangs at a specific percentage for hours, TiWorker.exe or TrustedInstaller.exe has hit an unhandled file lock or an infinite loop while attempting to parse corrupted LCU deltas in WinSxS\Temp.
# Diagnostic Verification:
1. Press Ctrl + Shift + Esc to open Task Manager.
2. Locate Windows Modules Installer Worker (TiWorker.exe).
3. If CPU usage is at 0% and Disk I/O is at 0 MB/s for over 30 minutes while DISM is running, the cleanup thread is deadlocked.
# Step-by-Step Fix:
1. Terminate Deadlocked Servicing Processes:
Open Command Prompt as Administrator and run: taskkill /f /im TiWorker.exe
taskkill /f /im TrustedInstaller.exe
taskkill /f /im dism.exe
2. Clear WinSxS Temp Staging Area:
Take ownership and delete files in the temporary staging directory: takeown /f C:\Windows\WinSxS\Temp /r /d y
icacls C:\Windows\WinSxS\Temp /grant administrators:F /t
del /f /s /q C:\Windows\WinSxS\Temp\*.*
3. Restart Servicing Service:
Execute: net start TrustedInstaller4. Re-run DISM Cleanup with explicit log routing:
Run: dism /Online /Cleanup-Image /StartComponentCleanup /LogPath:C:\dism_clean.log# Prevention & Long-Term Monitoring:
Ensure real-time antivirus scanning excludes %windir%\WinSxS\Temp during active cleanup maintenance.
DISM Error 0x80070005 - Access Denied / File Permissions Lock
Solution:
Root Cause: Access Control List (ACL) Permission Overrides on WinSxS Directory
Error 0x80070005 (ACCESS_DENIED) occurs during component cleanup when the TrustedInstaller SID or SYSTEM account is denied write/delete permissions on specific subfolders in WinSxS. This typically happens after users manually modify permissions on C:\Windows\WinSxS or when third-party security software locks component store handles.
# Diagnostic Verification:
1. Open Command Prompt as Administrator.
2. Query permissions on the WinSxS directory:
icacls C:\Windows\WinSxS
3. Verify if NT SERVICE\TrustedInstaller is missing (F) (Full Control) permissions.
# Step-by-Step Fix:
1. Restore Default ACL Permissions on WinSxS using ICACLS:
Open administrative Command Prompt and execute: icacls C:\Windows\WinSxS /grant "NT SERVICE\TrustedInstaller":(OI)(CI)(F) /t
icacls C:\Windows\WinSxS /grant "NT AUTHORITY\SYSTEM":(OI)(CI)(F) /t
2. Disable Third-Party Antivirus Real-Time Protection Temporarily:
Disable real-time file protection in your security software to prevent handle locks during cleanup.3. Execute DISM Cleanup:
Run: dism /Online /Cleanup-Image /StartComponentCleanup# Prevention & Long-Term Monitoring:
Never alter security descriptors or take manual ownership of C:\Windows\WinSxS.