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.

 

[10thdimension]

Improving with the time.Keep it up.

It’s clear a lot of users were affected by this, so I’m glad the fix went up when it did. If anyone has specific questions or needs clarification on any part of the process, don’t hesitate to ask; I’ll be keeping an eye on the thread and responding. Also, thank you for pinning this post so the solution is easier for others to find