Windows 11 [SOLVED] 2026-02 Security Update (KB5077181) (26200.7840) Failing

[10thdimension]

[SOLVED] KB5077181 Failing at 78–79% — Full Start‑to‑Finish Fix Guide (With ISO Checks + BitLocker Notes)

Posting this to help anyone dealing with the same issue I spent days fighting. My system refused to install KB5077181 (26200.7840) and always failed in the exact same way. Here is everything I did from start to finish, including the final fix and the verification steps recommended by others in this thread.

---------------------------------------
1. Symptoms of the Problem
---------------------------------------
• Update would reach 78%
• Instantly jump to 79%
• Windows Error Reporting (WER) would pop up and stay open
• TrustedInstaller.exe would crash
• CPU would drop to 0%
• Update would immediately fail
• Manual MSU installs failed the same way
• CBS logs showed error 0x800F0983 (PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING)

This is classic behavior of a PSFX commit/hydration failure, often caused by a baseline/component mismatch or missing component directory.

---------------------------------------
2. Things I Tried That DID NOT Fix It
---------------------------------------
These did nothing to resolve the underlying issue:
• SFC /scannow
• DISM /restorehealth
• Resetting Windows Update components
• Clearing SoftwareDistribution
• Renaming Catroot2
• Manual MSU installs
• Safe Mode installs
• Reboots
• Removing optional features/languages
• Full OS reset (the failure returned immediately)

None of these touched the real corruption.

---------------------------------------
3. ISO Sanity Check (Important Before Repair-Install)
---------------------------------------
Before running setup.exe, I verified the ISO was the correct build and edition.

Command:
dism /Get-WimInfo /WimFile:X:\sources\install.wim

I confirmed:
• Architecture matched (x64)
• Edition matched (**Home**, Index 1)
• ServicePack Build was **7840**, which is newer than my broken system’s **7623**

This ensures “Keep personal files and apps” works and that the repair install actually lays down a newer servicing baseline.

---------------------------------------
4. BitLocker Safety Step (Highly Recommended)
---------------------------------------
Because I previously hit a BitLocker recovery prompt during failed servicing attempts, I suspended BitLocker before running the repair install.

Commands:
manage-bde -protectors -disable C:
(After everything was stable)
manage-bde -protectors -enable C:

To confirm BitLocker is fully re-enabled afterward:
manage-bde -protectors -get C:

---------------------------------------
5. The Actual Fix (The Only Thing That Worked)
---------------------------------------
I performed a full **repair‑install (in‑place upgrade)** using the verified Windows 11 ISO.

This rebuilds:
• WinSxS (component store)
• Servicing stack
• Catalogs and manifests
• PSFX delta structures
• Baseline component versions

This step completely resets the servicing chain without wiping apps or files.

---------------------------------------
6. What Happened After the Repair‑Install
---------------------------------------
After the repair‑install, I ran Windows Update again.

This time the behavior was totally different:
• It stayed at 78% for 15–20 minutes (normal during commit/hydration)
• TrustedInstaller used 1–2 GB RAM (normal)
• WER flashed briefly but did NOT stay open
• No crash
• No jump to 79%
• No rollback

Eventually it moved to 95%, then 100%, and completed successfully.

---------------------------------------
7. Post-Fix Verification (Recommended)
---------------------------------------
To confirm everything was correct, I ran:

winver
dism /online /get-packages | findstr /i 5077181

Both confirmed:
• System is now on the newer 26200.7840 baseline
• KB5077181 is properly installed
• Windows Update no longer offers the update

---------------------------------------
8. Final Result
---------------------------------------
Windows Update now shows:
• KB5077181 — Completed
• Windows Security Platform Update — Completed
• System fully up to date and stable

---------------------------------------
9. Optional Cleanup
---------------------------------------
After confirming stability for a day or two, you can safely remove the leftover Windows.old folder:

Settings → System → Storage → Temporary files
(or Disk Cleanup → “Previous Windows installation(s)”)

---------------------------------------
10. Conclusion
---------------------------------------
If KB5077181 (or any LCU) fails at 78→79% with a WER crash, the issue is a **baseline/component store mismatch (PSFX) that DISM cannot repair**.

A **repair‑install using correct or newer ISO media** is the fix.

Extra credit tip: keep the working ISO or USB you used — it becomes a known-good recovery path if servicing ever gets stuck again.

Optional cleanup (after confirming everything is stable):

Settings → System → Storage → Temporary files
Remove “Previous Windows installation(s)” (this deletes C:\Windows.old)

Note: Some OEM tools (like Dell SupportAssist) may automatically remove Windows.old or setup temp files. If you only see a small amount of cleanup data (e.g., ~5–6 GB), that’s normal — it just means the system already cleaned up the leftover setup files.

(Note: The screenshot below is from BEFORE the repair-install.)

 

[ChatGPT]

That write-up is now “drop-in” quality — it clearly documents the symptom pattern (78→79% + WER + TrustedInstaller crash), the CBS root clue (0x800f0983 / PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING), and the only durable fix (in-place repair upgrade using same branch + newer build media).
A couple of small housekeeping notes you may want to add (optional):
1) Clarify the screenshot
The screenshot you attached shows the failed KB5077181 entry (0x800f0983). If that screenshot is from before the repair-install, label it “Before” so it doesn’t confuse readers (since after success the system should be on 26200.7840 and Windows Update should stop offering it).
Also worth noting: even after a fix, Update history can still show prior failed attempts—that’s normal; the real confirmation is winver + dism /get-packages.
2) Post-upgrade cleanup
An in-place upgrade typically leaves C:\Windows.old and setup temp folders. Once you’ve confirmed everything is stable for a day or two:

• Settings → System → Storage → Temporary files (or Disk Cleanup)
  Remove Previous Windows installation(s).

3) BitLocker check (for completeness)
After re-enabling protectors, this confirms protection is actually back on:
manage-bde -protectors -get C:
If you want, reply with your exact post-fix winver line (just the version/build line), and I’ll sanity-check it against what KB5077181 should land on.

 

[10thdimension]

That write-up is now “drop-in” quality — it clearly documents the symptom pattern (78→79% + WER + TrustedInstaller crash), the CBS root clue (0x800f0983 / PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING), and the only durable fix (in-place repair upgrade using same branch + newer build media).
A couple of small housekeeping notes you may want to add (optional):
1) Clarify the screenshot
The screenshot you attached shows the failed KB5077181 entry (0x800f0983). If that screenshot is from before the repair-install, label it “Before” so it doesn’t confuse readers (since after success the system should be on 26200.7840 and Windows Update should stop offering it).
Also worth noting: even after a fix, Update history can still show prior failed attempts—that’s normal; the real confirmation is winver + dism /get-packages.
2) Post-upgrade cleanup
An in-place upgrade typically leaves C:\Windows.old and setup temp folders. Once you’ve confirmed everything is stable for a day or two:

• Settings → System → Storage → Temporary files (or Disk Cleanup)
  Remove Previous Windows installation(s).

3) BitLocker check (for completeness)
After re-enabling protectors, this confirms protection is actually back on:
manage-bde -protectors -get C:
If you want, reply with your exact post-fix winver line (just the version/build line), and I’ll sanity-check it against what KB5077181 should land on.

added to guide with updated recommendations

 

[ChatGPT]

Perfect — that’s the right way to “finish” the thread: clarify the before screenshot, call out that Update History can retain failed attempts, and add the post-upgrade cleanup + BitLocker verification notes.
If you want a clean final “validation block” to paste at the very end of your guide (optional), this is what I’d use:

winver
dism /online /get-packages | findstr /i 5077181
manage-bde -protectors -get C:

And for cleanup after you’re confident everything is stable:

• Settings → System → Storage → Temporary files
  • Remove Previous Windows installation(s) (this deletes C:\Windows.old)

If you decide to upload/post any logs/screenshots for completeness, tell me what you’re sharing (CBS/DISM/Panther/etc.) and I’ll point out exactly which lines are most useful for others to recognize the same failure pattern quickly.

 

[10thdimension]

Perfect — that’s the right way to “finish” the thread: clarify the before screenshot, call out that Update History can retain failed attempts, and add the post-upgrade cleanup + BitLocker verification notes.
If you want a clean final “validation block” to paste at the very end of your guide (optional), this is what I’d use:

winver
dism /online /get-packages | findstr /i 5077181
manage-bde -protectors -get C:

And for cleanup after you’re confident everything is stable:

• Settings → System → Storage → Temporary files
  • Remove Previous Windows installation(s) (this deletes C:\Windows.old)

If you decide to upload/post any logs/screenshots for completeness, tell me what you’re sharing (CBS/DISM/Panther/etc.) and I’ll point out exactly which lines are most useful for others to recognize the same failure pattern quickly.

guide is updated to standards, hope this helps people.

 

[ChatGPT]

Nice work — your final guide is exactly the kind of “pattern → proof → fix → verify” post that will save other people hours.
A few quick closing items (optional) that help keep the thread tidy and reduce repeat questions:

• Label the screenshot “Before” (since it shows the 0x800f0983 failure state). Your narrative clearly explains that the failure was the PSFX staging/hydration mismatch (PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING) and that the repair-install resolves it. lready, add the one-line media requirement near the top: the in-place upgrade must use same branch + same edition + same arch + same-or-newer build (you validated this with the ISO reporting ServicePack Build 7840 vs your installed 7623).
• After a day or tider adding a note to clean up C:\Windows.old via Storage/Temporary files (people often ask about the disk space hit after a repair install).

If WindowsForum offers it, definitely Solved / set your guide post as the solution** so it surfaces in search results more reliably.

 

[muzzammil]

[SOLVED] KB5077181 Failing at 78–79% — Full Start‑to‑Finish Fix Guide (With ISO Checks + BitLocker Notes)

Posting this to help anyone dealing with the same issue I spent days fighting. My system refused to install KB5077181 (26200.7840) and always failed in the exact same way. Here is everything I did from start to finish, including the final fix and the verification steps recommended by others in this thread.

---------------------------------------
1. Symptoms of the Problem
---------------------------------------
• Update would reach 78%
• Instantly jump to 79%
• Windows Error Reporting (WER) would pop up and stay open
• TrustedInstaller.exe would crash
• CPU would drop to 0%
• Update would immediately fail
• Manual MSU installs failed the same way
• CBS logs showed error 0x800F0983 (PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING)

This is classic behavior of a PSFX commit/hydration failure, often caused by a baseline/component mismatch or missing component directory.

---------------------------------------
2. Things I Tried That DID NOT Fix It
---------------------------------------
These did nothing to resolve the underlying issue:
• SFC /scannow
• DISM /restorehealth
• Resetting Windows Update components
• Clearing SoftwareDistribution
• Renaming Catroot2
• Manual MSU installs
• Safe Mode installs
• Reboots
• Removing optional features/languages
• Full OS reset (the failure returned immediately)

None of these touched the real corruption.

---------------------------------------
3. ISO Sanity Check (Important Before Repair-Install)
---------------------------------------
Before running setup.exe, I verified the ISO was the correct build and edition.

Command:
dism /Get-WimInfo /WimFile:X:\sources\install.wim

I confirmed:
• Architecture matched (x64)
• Edition matched (**Home**, Index 1)
• ServicePack Build was **7840**, which is newer than my broken system’s **7623**

This ensures “Keep personal files and apps” works and that the repair install actually lays down a newer servicing baseline.

---------------------------------------
4. BitLocker Safety Step (Highly Recommended)
---------------------------------------
Because I previously hit a BitLocker recovery prompt during failed servicing attempts, I suspended BitLocker before running the repair install.

Commands:
manage-bde -protectors -disable C:
(After everything was stable)
manage-bde -protectors -enable C:

To confirm BitLocker is fully re-enabled afterward:
manage-bde -protectors -get C:

---------------------------------------
5. The Actual Fix (The Only Thing That Worked)
---------------------------------------
I performed a full **repair‑install (in‑place upgrade)** using the verified Windows 11 ISO.

This rebuilds:
• WinSxS (component store)
• Servicing stack
• Catalogs and manifests
• PSFX delta structures
• Baseline component versions

This step completely resets the servicing chain without wiping apps or files.

---------------------------------------
6. What Happened After the Repair‑Install
---------------------------------------
After the repair‑install, I ran Windows Update again.

This time the behavior was totally different:
• It stayed at 78% for 15–20 minutes (normal during commit/hydration)
• TrustedInstaller used 1–2 GB RAM (normal)
• WER flashed briefly but did NOT stay open
• No crash
• No jump to 79%
• No rollback

Eventually it moved to 95%, then 100%, and completed successfully.

---------------------------------------
7. Post-Fix Verification (Recommended)
---------------------------------------
To confirm everything was correct, I ran:

winver
dism /online /get-packages | findstr /i 5077181

Both confirmed:
• System is now on the newer 26200.7840 baseline
• KB5077181 is properly installed
• Windows Update no longer offers the update

---------------------------------------
8. Final Result
---------------------------------------
Windows Update now shows:
• KB5077181 — Completed
• Windows Security Platform Update — Completed
• System fully up to date and stable

---------------------------------------
9. Optional Cleanup
---------------------------------------
After confirming stability for a day or two, you can safely remove the leftover Windows.old folder:

Settings → System → Storage → Temporary files
(or Disk Cleanup → “Previous Windows installation(s)”)

---------------------------------------
10. Conclusion
---------------------------------------
If KB5077181 (or any LCU) fails at 78→79% with a WER crash, the issue is a **baseline/component store mismatch (PSFX) that DISM cannot repair**.

A **repair‑install using correct or newer ISO media** is the fix.

Extra credit tip: keep the working ISO or USB you used — it becomes a known-good recovery path if servicing ever gets stuck again.

Optional cleanup (after confirming everything is stable):

Settings → System → Storage → Temporary files
Remove “Previous Windows installation(s)” (this deletes C:\Windows.old)

Note: Some OEM tools (like Dell SupportAssist) may automatically remove Windows.old or setup temp files. If you only see a small amount of cleanup data (e.g., ~5–6 GB), that’s normal — it just means the system already cleaned up the leftover setup files.

(Note: The screenshot below is from BEFORE the repair-install.)

Improving with the time.Keep it up.