Fix Windows Update error 0x800f0986 (PSFX_E_APPLY_FORWARD_DELTA_FAILED) on Windows Server 2019 / Windows 10

Cumulative updates fail every month with 0x800f0986, 0x800f0982, or "Hydration failed for component" in CBS.log - while DISM /RestoreHealth and SFC /scannow report no corruption? This toolkit pinpoints the exact corrupt file in the WinSxS component store by replaying the servicing stack's own delta math with msdelta.dll, then reconstructs a verified-good replacement from files already on your disk - no donor machine, no ISO, no in-place upgrade, no reinstall. Typical time to fix: about 30 minutes.

Applies to: Windows Server 2019 (1809, build 17763), Windows 10 1809, and generally any Windows build that services updates with PSF/PA30 forward+reverse deltas (Server 2016/2022 variants of the same errors).

Symptoms this solves

• Every monthly LCU fails at ~some % and rolls back with 0x800f0986 (also seen: 0x800f0982, 0x800f0985)
• CBS.log shows lines like:

  Error CSI ... DeltaDecompressBuffer ... NTSTATUS_FROM_WIN32(ERROR_INVALID_DATA)
  Error CSI ... Hydration failed for component <Name>, version <x>, ... on file <file> ...
  CBS Failed to stage execution package: ... [HRESULT = 0x800f0986 - PSFX_E_APPLY_FORWARD_DELTA_FAILED]
  

• DISM /Online /Cleanup-Image /RestoreHealth and sfc /scannow find nothing (they do not deep-verify delta payloads - this is why months of standard repair loops go nowhere)
• Manual .msu installs via wusa or DISM fail identically

Why this happens (30-second version)

1809-era updates are delta-based. The component store keeps, per component: the RTM base file, the current full file, a forward delta (base -> current) and a reverse delta (current -> base). Each new CU hydrates its new file version by applying its forward delta against the base. If the base, the full file, or a reverse delta on disk is corrupt (truncation, storage glitch, interrupted servicing), every future CU dies at the same component - and DISM cannot see it.

The key insight: PA30 deltas embed a hash of their intended output. A delta that applies cleanly has cryptographically certified its own result. So by replaying the chain in both directions with msdelta.dll (the same engine CBS uses), you can (a) identify exactly which of the four pieces is corrupt and (b) often regenerate the correct bytes of the corrupt piece from the surviving pieces.

Quick start

All scripts require an elevated PowerShell session. Take a VM snapshot or backup before the repair step.

# 1. After a failed CU attempt: find the failing component + file
.\scripts\Collect-CbsEvidence.ps1
#    -> read hydration_failures.txt: gives you component name + payload file

# 2. Replay the delta chain for that component (READ-ONLY)
.\scripts\Test-ComponentDeltaChain.ps1 -ComponentNameTail 'driverpolicy' -PayloadFileName 'driversipolicy.p7b'
#    -> verdict names the corrupt piece; good reconstructions are saved to C:\Temp

# 3. Swap the corrupt piece for the verified reconstruction (SNAPSHOT FIRST)
.\scripts\Fix-ComponentBase.ps1 -ComponentNameTail 'driverpolicy' -PayloadFileName 'driversipolicy.p7b'

# 4. Restore TrustedInstaller ownership (icacls alone cannot do this)
.\scripts\Restore-TIOwnership.ps1 -Path <file-and-folder-paths-from-step-3>

# 5. Install the CU offline via DISM with full logging
.\scripts\Install-KB-Offline.ps1 -MsuPath C:\Temp\<your-KB>.msu

Full walkthrough with a real-world case (a SQL Server host that had failed every CU for months due to a single truncated 1,395-byte policy file): docs/SOLUTION.md

What's in the box

Script	Purpose
Collect-CbsEvidence.ps1	Parses CBS.log; extracts failing component names + payload files (handles both SxS and nonSxS components), plus package inventory and pending-reboot state
Test-ComponentDeltaChain.ps1	Read-only delta-chain replay for any component via msdelta.dll P/Invoke; verdict matrix pinpoints the corrupt piece; saves verified reconstructions
Fix-ComponentBase.ps1	Snapshot-gated, idempotent swap of the corrupt store file for the verified reconstruction, with directory-level ownership handling
Restore-TIOwnership.ps1	Returns ownership to NT SERVICE\TrustedInstaller via SeRestorePrivilege + SetNamedSecurityInfo (icacls /setowner cannot assign foreign ownership)
Install-KB-Offline.ps1	Expands an .msu, installs SSU cab then LCU cab via DISM /Add-Package with per-attempt logs
Reset-WindowsUpdate.ps1	Standard WU component reset (SoftwareDistribution, catroot2, BITS)

Hard-won gotchas encoded in these scripts

• WinSxS contracts long component names with .. (e.g. amd64_microsoft-windows-c..egrity-driverpolicy_...) - never filter by full literal names; match name tails
• nonSxS components don't follow the hashed folder-name pattern most log parsers expect - the evidence collector reads the Hydration failed for component lines directly
• CBS delta blobs carry a 4-byte CRC32 prefix before the PA30 magic; strip and verify it before ApplyDeltaB
• Writing a file into a TrustedInstaller-owned folder needs ownership/write on the directory, not just the file
• icacls /setowner "NT SERVICE\TrustedInstaller" fails with access denied; assigning foreign ownership requires SeRestorePrivilege enabled via AdjustTokenPrivileges
• Never run DISM /StartComponentCleanup /ResetBase while broken - it deletes the reverse deltas you need for reconstruction and can make the box permanently unrepairable

When this does NOT apply

• The failing piece is a manifest/catalog rather than a payload (rare; the chain replay will tell you - all tests pass)
• Corruption is widespread across many components (an in-place repair upgrade is then the better trade; see SOLUTION.md Phase 4)
• Errors other than delta/hydration failures (0x800f0922, 0x80073712 have different root causes)

License

MIT - see LICENSE. Use it, ship it, save your weekend.

Credits and references

Method developed while remediating a production Windows Server 2019 / SQL Server 2019 VM that had failed every CU for months. Community context: the many solved 0x800f0986 threads at Sysnative Forums (whose analysts fix this class of issue via manual component repair), and Microsoft Q&A threads documenting the DISM-clean-but-updates-fail pattern.