KB5077181 fails on Win11 25H2 (26200.7623) with 0x800f0983; SoftwareDistribution rename triggered boot failure/BitLocker

1) Are others seeing it on KB5077181 / 26200.x?​

2) SSU / MSU install order question (important)​

3) About the SoftwareDistribution rename → crash → BitLocker recovery​

• you renamed it while the system was in a fragile servicing state (pending actions / partially staged update), and
• Windows subsequently failed boot/repair enough times that it dropped into WinRE/Automatic Repair, which commonly triggers a BitLocker recovery prompt (PCR measurements change when boot flow changes).

What I’d do next (in the order most likely to end this quickly)​

A) Remove “usual suspects” that cause 0x800f0983, then retry​

• Any additional display languages / language packs (leave only one)
• Optional features / FODs you added (RSAT, extra handwriting/speech packs, etc.)

B) Do a proper Windows Update component reset (don’t do it interactively in Explorer)​

net stop wuauserv
net stop bits
net stop cryptsvc

ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old

net start cryptsvc
net start bits
net start wuauserv

C) If it still fails: repair the component store using a matching ISO source​

• Mount an ISO for the same flight (26200.x), then:

dism /online /cleanup-image /restorehealth /source:wim:X:\sources\install.wim:1 /limitaccess
sfc /scannow

D) If you want the “most likely to work” fix: In‑place repair upgrade​

If you want to pinpoint the exact mismatch (so we’re not guessing)​

• language/FOD related,
• a pending actions problem,
• a genuinely broken component identity,
• or a known-bad KB package interaction on 26200.

Quick clarifying questions​

ChatGPT said:

0x800f0983 on an LCU like KB5077181 is almost always a servicing/component applicability mismatch (Windows Update can “see” the update, but CBS can’t match one or more components it expects when it goes to stage/apply). That can survive a Reset if the reset image you end up with still has the same mismatch (or if something you re-add immediately after reset recreates it—language/FOD/optional features are common triggers).

1) Are others seeing it on KB5077181 / 26200.x?​

Yes—there are already multiple reports of KB5077181 (Build 26200.7840) being problematic in the field, including install failures with 0x800f0983 on some systems. citeturn0search0turn0search1
Microsoft’s KB5077181 page (at least as of the sources I’m seeing) still states they’re “not currently aware of any issues”, so it’s not officially acknowledged there yet. citeturn1view0

2) SSU / MSU install order question (important)​

For this update line, Microsoft is shipping the SSU combined with the LCU (the normal modern model), so there generally isn’t a separate “SSU first, then LCU” manual order you can fix by hand anymore. citeturn1view0
That said, manual install from the Microsoft Update Catalog is still worth trying because it bypasses some WU orchestration issues (but it won’t fix a true component mismatch).

3) About the SoftwareDistribution rename → crash → BitLocker recovery​

Renaming C:\Windows\SoftwareDistribution shouldn’t by itself “brick” the OS. What usually happens in cases like yours is:

• you renamed it while the system was in a fragile servicing state (pending actions / partially staged update), and
• Windows subsequently failed boot/repair enough times that it dropped into WinRE/Automatic Repair, which commonly triggers a BitLocker recovery prompt (PCR measurements change when boot flow changes).

So I’d treat that as a symptom of the machine being mid-servicing / unstable, not as evidence that renaming the folder is inherently dangerous.

---

What I’d do next (in the order most likely to end this quickly)​

A) Remove “usual suspects” that cause 0x800f0983, then retry​

Before attempting the update again, temporarily remove:

• Any additional display languages / language packs (leave only one)
• Optional features / FODs you added (RSAT, extra handwriting/speech packs, etc.)

Then reboot and try KB5077181 again.

B) Do a proper Windows Update component reset (don’t do it interactively in Explorer)​

From an elevated terminal:

Code:

net stop wuauserv
net stop bits
net stop cryptsvc

ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old

net start cryptsvc
net start bits
net start wuauserv

Reboot, then try the update.

C) If it still fails: repair the component store using a matching ISO source​

Because SFC/DISM “no corruption” doesn’t guarantee the component store matches what the LCU expects, the most reliable DISM repair is RestoreHealth with a source image that matches your build train.

• Mount an ISO for the same flight (26200.x), then:

Code:

dism /online /cleanup-image /restorehealth /source:wim:X:\sources\install.wim:1 /limitaccess
sfc /scannow

(Replace X: and the index as appropriate.)

D) If you want the “most likely to work” fix: In‑place repair upgrade​

Given you already did Reset → Remove everything and the issue persists, the cleanest “servicing stack reset” is an in-place repair upgrade using an ISO for 26200.7840 or newer (keep files/apps).
This replaces the OS component set in a way WU resets often don’t, and it’s the most common way to eliminate stubborn 0x800f0983 when it isn’t a Microsoft-side packaging bug.
Tip: Suspend BitLocker/device encryption protectors before doing this to avoid another recovery prompt, then re-enable afterward.

---

If you want to pinpoint the exact mismatch (so we’re not guessing)​

Post the failure excerpt from CBS so we can see which component/package is “not applicable / missing”:
1) Run:
findstr /i /c:"0x800f0983" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\CBS_800f0983.txt"
2) Also export Windows Update events:
Event Viewer → Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational
If you paste/upload those excerpts, we can usually tell whether this is:

• language/FOD related,
• a pending actions problem,
• a genuinely broken component identity,
• or a known-bad KB package interaction on 26200.

Quick clarifying questions​

1) Are you on Windows Insider (Beta/Dev/Canary), and which channel does Settings show?
2) Do you have more than one language installed (or any handwriting/speech packs)?
3) After the reset, did you use Local reinstall or Cloud download?
Those three answers will strongly determine whether the best move is (C) source-based DISM repair vs (D) in-place repair upgrade vs “pause and wait for the next LCU.”

Click to expand...

1) First: stop stressing the servicing pipeline (stability/BitLocker)​

• Pause updates for now (Settings → Windows Update → Pause updates) to stop the automatic retry loop while you collect diagnostics.
• Before any more servicing experiments, confirm you have your BitLocker/device-encryption recovery key saved and consider temporarily suspending protectors right before major update operations:
  • manage-bde -protectors -disable C:
  • Re-enable later: manage-bde -protectors -enable C:

2) The single most useful diagnostic step: capture the actual CBS failure reason​

findstr /i /c:"0x800f0983" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\CBS_800f0983.txt"
findstr /i /c:"0x800f0991" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\CBS_800f0991.txt"

• Event Viewer → Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational (save as .evtx)

• prerequisite package missing/not installed
• PSFX “matching component not found” style issue
• pending actions / partially staged state
• source missing / manifest mismatch

3) Don’t assume “combined SSU means no ordering issues” — try the documented prerequisite method​

• install KB5043080 first, then KB5077181, OR
• put both MSUs in the same folder and let DISM resolve prerequisites.

Try this (low risk, no ISO required)​

• KB5043080
• KB5077181
  from the Microsoft Update Catalog.

DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5043080-x64.msu"
shutdown /r /t 0

4) If WU component resets are destabilizing: check for “pending” state instead of renaming folders again​

• Does this file exist?
  • C:\Windows\WinSxS\pending.xml
• What does DISM report?
  • dism /online /cleanup-image /checkhealth

5) If this really is Microsoft-side: what’s the practical play?​

• Pause updates until Microsoft republishes/replaces the LCU (or ships an OOB fix), and
• avoid repeated install attempts that keep throwing you into recovery flows.

What I need from you (minimal + decisive)​

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

ChatGPT said:

You’re right to push back on the “languages/FOD/RSAT” angle for your specific case if you truly reproduced this on a bare post‑reset system. And you’re also right that, with multiple users reporting KB5077181 → boot/login/network regressions + install error codes (0x800f0983 / 0x800f0991), a Microsoft-side packaging/regression is very plausible. WindowsForum’s own Feb 2026 roundup thread is already tracking those exact symptoms and error codes on this KB.
That said, the next “best diagnostic step” isn’t to assume local corruption—it’s to classify which failure signature you have (prereq ordering vs. PSFX/component match vs. stuck pending), using minimal additional churn on the machine.
Below is the path I’d take given your constraints (clean OS, no matching ISO, WU reset destabilized the system).

---

1) First: stop stressing the servicing pipeline (stability/BitLocker)​

Because you already saw a rename trigger a boot/WinRE path and BitLocker recovery, I would:

• Pause updates for now (Settings → Windows Update → Pause updates) to stop the automatic retry loop while you collect diagnostics.
• Before any more servicing experiments, confirm you have your BitLocker/device-encryption recovery key savedand consider temporarily suspending protectors right before major update operations:
  • manage-bde -protectors -disable C:
  • Re-enable later: manage-bde -protectors -enable C:

(You don’t need to do this for simple log collection—only if you’re going to do another install attempt.)

---

2) The single most useful diagnostic step: capture the actual CBS failure reason​

Even if this is a Microsoft-side payload issue, the CBS log will usually show the specific failure type (and if it matches other users, that’s strong evidence it’s not your machine).
Run these after a failed install attempt:

Code:

findstr /i /c:"0x800f0983" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\CBS_800f0983.txt"
findstr /i /c:"0x800f0991" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\CBS_800f0991.txt"

Also export:

• Event Viewer → Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational (save as .evtx)

If you paste (or attach) just the last ~100–200 lines around the first error occurrence from the CBS extract, we can tell very quickly whether this is:

• prerequisite package missing/not installed
• PSFX “matching component not found” style issue
• pending actions / partially staged state
• source missing / manifest mismatch

This is the fastest way to avoid guessing.

---

3) Don’t assume “combined SSU means no ordering issues” — try the documented prerequisite method​

Even with modern “combined” packaging, Microsoft has (in some cases) still documented prerequisite handling for standalone installs—and failures can happen if the prereq didn’t land cleanly via WU.
In our own WindowsForum history for this KB line, the documented workaround has been:

• install KB5043080 first, then KB5077181, OR
• put both MSUs in the same folder and let DISM resolve prerequisites.

Try this (low risk, no ISO required)​

1) Download the x64 MSUs for:

• KB5043080
• KB5077181
  from the Microsoft Update Catalog.

2) Put them both in C:\Packages
3) Run (elevated CMD/Terminal):
DISM /Online /Add-Package /PackagePath:C:\Packages
or (more explicit):

Code:

DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5043080-x64.msu"
shutdown /r /t 0

After reboot:
DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5077181-x64.msu"
If this succeeds, it strongly suggests your WU “orchestration” path was the problem—not necessarily local corruption.
If this fails with the same code, the CBS excerpt becomes the deciding evidence.

---

4) If WU component resets are destabilizing: check for “pending” state instead of renaming folders again​

On a system that’s repeatedly trying and failing an LCU, I’d check if you’re stuck with pending servicing actions:

• Does this file exist?
  • C:\Windows\WinSxS\pending.xml
• What does DISM report?
  • dism /online /cleanup-image /checkhealth

If you’re in a bad “pending” state, the correct next step can be reverting pending actions from WinRE, but I don’t want you to do that blindly because it can sometimes strand a system if storage/BitLocker/boot conditions aren’t ideal.
If your CBS extract shows “pending”/rollback loops, tell me and I’ll give you the safest WinRE command sequence for your situation.

---

5) If this really is Microsoft-side: what’s the practical play?​

If the CBS failure signature matches what others are seeing (and especially if it points to a PSFX/component mismatch), the pragmatic answer is:

• Pause updates until Microsoft republishes/replaces the LCU (or ships an OOB fix), and
• avoid repeated install attempts that keep throwing you into recovery flows.

This lines up with the pattern in current community reporting where uninstalling/avoiding KB5077181 is the short-term mitigation for the more severe regressions.

---

What I need from you (minimal + decisive)​

1) Attach/paste CBS_800f0983.txt (and CBS_800f0991.txt if it exists)
2) Paste the output of:

Code:

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

3) Confirm whether “Reset → Remove everything” was Cloud download or Local reinstall
With those, we can answer your core question confidently: “is this local state or a bad KB?”—without assuming corruption and without requiring an ISO.

Click to expand...

The next best step (practical + diagnostic) given your constraints​

Step 0 — Confirm we’re not mixing branches/builds (important)​

winver
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR

Step 1 — Force the prereq + LCU path via DISM (this can bypass a bad WU “express” orchestration)​

1. Download from Microsoft Update Catalog (matching your architecture):
   • KB5043080 (x64)
   • KB5077181 (x64)
2. Put both .msu files in C:\Packages
3. Run (Admin CMD/Terminal):

DISM /Online /Add-Package /PackagePath:C:\Packages
shutdown /r /t 0

• If it succeeds, it strongly indicates Windows Update’s delivery/orchestration path was the trigger (not general OS corruption).
• If it fails with the same PSFX directory-missing error, that’s strong evidence of a genuine payload/baseline mismatch.

Step 2 — Identify whether your Reset used an OEM/local image (this matters for “clean OS” claims)​

• do a second reset using Cloud download (after backing up anything important).

Step 3 — Stop doing WU component resets on this machine for now​

Step 4 — Escalation-quality data (to prove Microsoft-side packaging)​

• C:\Windows\Logs\CBS\CBS.log + the relevant CbsPersist_*.log
• C:\Windows\Logs\DISM\dism.log
• Event Viewer export:
  Microsoft → Windows → WindowsUpdateClient → Operational (EVTX)

• Parallel hydration failed … PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING

Two quick questions so I can give you a decisive “do X next”​

• “this is almost certainly wrong-branch targeting” vs
• “try prerequisite install (likely fix)” vs
• “pause and wait for a re-release/OOB because this looks Microsoft-side.”

ChatGPT said:

That CBS signature is very specific, and your interpretation is directionally correct:
PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING (0x800f0983) during “Parallel hydration” usually means the update is trying to apply a PSFX/express-style delta and can’t find the baseline component directory it expects under WinSxS, so staging can’t complete and the package never transitions cleanly to Staged.
With multiple reports around KB5077181 including install failures (0x800f0983 / 0x800f0991) plus other regressions, it’s absolutely plausible this is a bad package / bad applicability targeting scenario rather than “you have corruption.”

The next best step (practical + diagnostic) given your constraints​

Step 0 — Confirm we’re not mixing branches/builds (important)​

In your last message you referenced 26100.7623, but your thread title and screenshots indicate 26200.7623 (25H2). Those are different baseline branches (24H2 vs 25H2).
Please paste the output of:

Code:

winver
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR

If Windows Update is offering you an LCU for a different baseline branch, PSFX “missing component directory” is exactly the kind of failure you’d see.

Step 1 — Force the prereq + LCU path via DISM (this can bypass a bad WU “express” orchestration)​

Even when an SSU is “combined,” Microsoft has still had cases where a prerequisite package needs to be present/handled correctly when doing offline installs, and WindowsForum guidance for this KB line has repeatedly pointed to installing KB5043080 first, then KB5077181, or placing both MSUs together and letting DISM resolve prerequisites.
Do this:

1. Download from Microsoft Update Catalog (matching your architecture):
   • KB5043080 (x64)
   • KB5077181 (x64)
2. Put both .msu files in C:\Packages
3. Run (Admin CMD/Terminal):

Code:

DISM /Online /Add-Package /PackagePath:C:\Packages
shutdown /r /t 0

Then re-check Windows Update.
Why this is “best next”:

• If it succeeds, it strongly indicates Windows Update’s delivery/orchestration path was the trigger (not general OS corruption).
• If it fails with the same PSFX directory-missing error, that’s strong evidence of a genuine payload/baseline mismatch.

Step 2 — Identify whether your Reset used an OEM/local image (this matters for “clean OS” claims)​

A reset can still put you back onto an OEM recovery image (local reinstall) rather than a pristine Microsoft image, and if that image is missing some baseline components, PSFX deltas can choke.
So: Was your Reset → Remove everything done via “Cloud download” or “Local reinstall”?
If it was Local reinstall, the most meaningful next diagnostic is:

• do a second reset using Cloud download (after backing up anything important).

This is the closest thing to “getting a known-good baseline” you can do without a matching ISO.

Step 3 — Stop doing WU component resets on this machine for now​

Given you already got thrown into Automatic Repair → BitLocker recovery immediately after the SoftwareDistribution rename, I’d avoid more cache resets until the package issue is resolved (or you’re working from WinRE with a planned recovery path). Your system was likely mid-servicing when that happened, and repeated servicing interruptions can compound instability.

Step 4 — Escalation-quality data (to prove Microsoft-side packaging)​

If Step 1 fails, the next best “diagnostic” move isn’t more repair commands—it’s collecting the minimum evidence bundle that demonstrates the mismatch:

• C:\Windows\Logs\CBS\CBS.log + the relevant CbsPersist_*.log
• C:\Windows\Logs\DISM\dism.log
• Event Viewer export:
  Microsoft → Windows → WindowsUpdateClient → Operational (EVTX)

Then file it via Feedback Hub (Category: Windows Update / Install and Update) and/or Microsoft Q&A, referencing that the failure is consistently:

• Parallel hydration failed … PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING

This is the kind of signature that usually gets traction because it’s not a generic “update failed,” it’s an explicit PSFX baseline resolution failure.

---

Two quick questions so I can give you a decisive “do X next”​

1) Confirm: are you 26200.7623 or 26100.7623 right now? (Paste the registry + winver outputs above.)
2) Did you already try the KB5043080 → KB5077181 DISM method, or only Windows Update?
If you answer those two, I can tell you whether your best move is:

• “this is almost certainly wrong-branch targeting” vs
• “try prerequisite install (likely fix)” vs
• “pause and wait for a re-release/OOB because this looks Microsoft-side.”

Click to expand...

What I’d do next (best signal for least pain)​

1) Yes: run the KB5043080 → KB5077181 DISM test​

1. Make sure you have the BitLocker recovery key saved.
2. Temporarily suspend protectors:
   manage-bde -protectors -disable C:

1. Download the x64 MSUs from Microsoft Update Catalog:
   • KB5043080
   • KB5077181
2. Put both files in C:\Packages
3. Run:
   
   Code:

   DISM /Online /Add-Package /PackagePath:C:\Packages
   shutdown /r /t 0

• Check your build (winver) and also confirm what actually installed:
  dism /online /get-packages | findstr /i "5043080 5077181"

• If DISM succeeds: that strongly suggests this wasn’t “missing WinSxS baseline,” but rather Windows Update’s delivery path (express/PSFX orchestration/caching) hitting a failure mode.
• If DISM fails with the same PSFX directory-missing error: then your “baseline image is missing expected component directories” theory gets a lot stronger.

If DISM fails: next best step is not another Reset (Local) — it’s getting onto Microsoft media​

2) Clean install from official Microsoft installation media (USB)​

One thing I still need you to confirm (because it matters a lot)​

winver
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR

Bottom line​

• Run the DISM prereq test first (KB5043080 + KB5077181). It’s the best “next diagnostic step” with minimal risk and high information value.
• If it still fails with PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING, then stop hammering Windows Update and plan a true clean install from Microsoft media (not another Local reset), because your baseline really may be missing what the PSFX delta expects.

ChatGPT said:

Local reinstall is a strong hint, but by itself it’s not enough to conclude “missing components in the OEM image” vs “bad KB targeting/express payload,” because Reset/Local reinstall typically reconstructs Windows using the existing component store + WinRE image (and may incorporate OEM recovery customizations depending on the device). In other words: your hypothesis is very plausible, but we should still run one low-risk discriminating test before you wipe anything again. Your CBS pattern (Stage → “Parallel hydration failed” with PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING) is exactly the kind of signature that can be caused by either a baseline mismatch or a package targeting/delta issue.

What I’d do next (best signal for least pain)​

1) Yes: run the KB5043080 → KB5077181 DISM test​

Do this first. It’s the fastest way to learn whether Windows Update’s express/orchestration path is what’s getting you into a broken PSFX hydration state.
Prep (to avoid BitLocker surprises):

1. Make sure you have the BitLocker recovery key saved.
2. Temporarily suspend protectors:
   manage-bde -protectors -disable C:

Install (Admin CMD/Terminal):

1. Download the x64MSUs from Microsoft Update Catalog:
   • KB5043080
   • KB5077181
2. Put both files in C:\Packages
3. Run:
   
   Code:

   DISM /Online /Add-Package /PackagePath:C:\Packages
   shutdown /r /t 0

After reboot:

• Check your build (winver) and also confirm what actually installed:
  dism /online /get-packages | findstr /i "5043080 5077181"

This “prereq + LCU via DISM” method is a known workaround pattern for this KB line on WindowsForum (KB5043080 first, then KB5077181 / or both together).
Interpretation:

• If DISM succeeds: that strongly suggests this wasn’t “missing WinSxS baseline,” but rather Windows Update’s delivery path (express/PSFX orchestration/caching) hitting a failure mode.
• If DISM fails with the same PSFX directory-missing error: then your “baseline image is missing expected component directories” theory gets a lot stronger.

When you’re done testing, re-enable protectors:
manage-bde -protectors -enable C:

---

If DISM fails: next best step is not another Reset (Local) — it’s getting onto Microsoft media​

If you can’t do Cloud Reset and Local Reset keeps landing you in the same PSFX hydration failure, the next meaningful move is:

2) Clean install from official Microsoft installation media (USB)​

This is different from “Reset this PC.” It bypasses OEM recovery content and gives you a known-good baseline. Even if a 25H2 ISO isn’t publicly downloadable, installing the latest public Windows 11 release (whatever Microsoft is currently serving via Media Creation Tool/ISO) typically gets you onto a baseline that can then take cumulative updates normally, or at least lets you move forward until Microsoft re-releases a fixed LCU.
If you want, I can outline a “minimum downtime” approach (backup, clean install, then restore) and the exact partition choices so you don’t accidentally wipe a data drive.

---

One thing I still need you to confirm (because it matters a lot)​

Before you run anything, please paste:

Code:

winver
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR

You earlier referenced 26100.x once, but your thread starts with 26200.7623. A branch/build mismatch (24H2 vs 25H2 baseline confusion) can also manifest as PSFX “matching component directory missing” during staging/hydration.

---

Bottom line​

• Run the DISM prereq test first (KB5043080 + KB5077181). It’s the best “next diagnostic step” with minimal risk and high information value.
• If it still fails with PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING, then stop hammering Windows Update and plan a true clean install from Microsoft media (not another Local reset), because your baseline really may be missing what the PSFX delta expects.

Reply back with the winver/registry build + UBR and (if you run DISM) the final DISM error/output, and I’ll tell you which fork you’re on immediately.

Click to expand...

Proceed with the DISM prereq test (recommended)​

0) Safety prep (BitLocker / Device Encryption)​

• Search “Manage BitLocker” (or Device encryption) → Suspend protection

1) Download the two MSUs (x64)​

• KB5043080
• KB5077181

• C:\Packages

2) Install them with DISM (explicit order)​

DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5043080-x64.msu"
shutdown /r /t 0

DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5077181-x64.msu"
shutdown /r /t 0

3) Verify what happened​

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

4) Re-enable BitLocker protectors​

How to interpret the results​

If DISM succeeds​

If DISM fails with the same 0x800f0983 / PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING​

What I want you to paste back after you run it​

ChatGPT said:

Yes — with your confirmed baseline (25H2 / 26200.7623) and the consistent CBS signature (PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING during Stage) , the KB5043080 → KB5077181 DISM install is still the best “discriminating step” before you consider another reset/clean install. This is specifically because it tests whether the failure is tied to Windows Update’s express/orchestration path vs. a true baseline/component-store mismatch.

Proceed with the DISM prereq test (recommended)​

0) Safety prep (BitLocker / Device Encryption)​

Because you’ve already been forced into BitLocker recovery once during servicing changes, suspend protection before you start:
Option A (GUI):

• Search “Manage BitLocker” (or Device encryption) → Suspend protection

Option B (command line, Admin Terminal):
manage-bde -protectors -disable C:
(Keep the recovery key handy either way.)

1) Download the two MSUs (x64)​

From the Microsoft Update Catalog, download x64:

• KB5043080
• KB5077181

Put both files in:

• C:\Packages

2) Install them with DISM (explicit order)​

Open Terminal / Command Prompt (Admin):

Code:

DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5043080-x64.msu"
shutdown /r /t 0

After reboot:

Code:

DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5077181-x64.msu"
shutdown /r /t 0

This is the same prereq approach we’ve been discussing (KB5043080 first, then KB5077181) as a workaround path when WU/install sequencing is suspect.

3) Verify what happened​

After the final reboot, run:

Code:

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

4) Re-enable BitLocker protectors​

Once you’re done testing:
manage-bde -protectors -enable C:

---

How to interpret the results​

If DISM succeeds​

That points away from “OEM baseline missing component directories” and toward WU express/orchestration delivering a delta that can’t hydrate cleanly on your box (or WU’s local metadata/cache path causing the mismatch). In that case, the practical fix is often: “install the prerequisite + LCU manually” and then let Windows Update continue normally.

If DISM fails with the same 0x800f0983 / PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING​

Then your “Local reinstall baseline is missing what the PSFX delta expects” theory becomes much stronger, because you’ve removed most of Windows Update’s orchestration variables and still can’t stage/hydrate. This aligns with the Stage-phase failure pattern you’re already seeing (Resolved → Staged never completes).
At that point, the next most rational move is not more WU resets (given your previous instability), but getting onto a known-good Microsoft base image (Cloud reset if you can make it work, or a true clean install from official Microsoft media).

---

What I want you to paste back after you run it​

1) The exact DISM output for each package install (success or error code).
2) Output of:
dism /online /get-packages | findstr /i "5043080 5077181"
3) If it fails, paste the newest 10–20 CBS lines around the failure (you’ve already shown the consistent pattern, but we want the post-DISM attempt confirmation).
You’re in a great position to run this test now: you’ve confirmed the build/UBR, confirmed neither KB is installed, and you have a repeatable PSFX hydration failure signature.

Click to expand...

• Windows 11 25H2, Build 26200.7623 (UBR 7623)

Key point: KB5043080 is not the right prerequisite for your 25H2 (26200.x) system​

What to do next for your actual issue (KB5077181 / 0x800f0983 PSFX “component directory missing”)​

Option A (best, minimal drama): “Reinstall now” (in-place repair via Windows Update)​

Option B: Use the latest Media Creation Tool and do an in-place upgrade repair​

Two quick clarifiers (because one of your statements conflicts with your build)​

• Did the KB5077181 MSU/DISM command complete, but the system rolled back on reboot?
• Or did it truly install and you’re now on 26200.7840?

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

About “escalate this to Microsoft”​

• C:\Windows\Logs\CBS\CBS.log + newest CbsPersist_*.log
• C:\Windows\Logs\DISM\dism.log
• WindowsUpdateClient Operational EVTX export
  3) In the description, include the exact signature:
• PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING (0x800f0983) during Stage/Parallel hydration

ChatGPT said:

You did great work narrowing this down, and your build info confirms there’s no branch mismatch on your side:

• Windows 11 25H2, Build 26200.7623 (UBR 7623)

Key point: KB5043080 is not the right prerequisite for your 25H2 (26200.x) system​

KB5043080 is a September 10, 2024 cumulative update for Windows 11 24H2 (OS Build 26100.1742) and is tied to the “checkpoint cumulative update” era for that branch.
So, trying to force-install KB5043080 onto 25H2 / 26200.x is not a valid “prereq test” for KB5077181 on your system, and the fact that DISM throws 0x80070228 / 552 (“passed ACL…”) does not prove Microsoft has published a corrupted package for your scenario—it more likely proves “this MSU isn’t installable in this context / DISM chokes on its internal packaging when used this way.” (Other people have hit the same DISM error on KB5043080; one trace shows DISM failing while applying an Unattend.xml embedded in the MSU.)
So I’d stop spending cycles on KB5043080. It’s a dead end for 26200.7623 → 26200.7840.

---

What to do next for your actual issue (KB5077181 / 0x800f0983 PSFX “component directory missing”)​

KB5077181 is the Feb 10, 2026 cumulative that should take you to 26200.7840 on 25H2.
Your CBS signature PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING (0x800f0983) is consistent with an express/PSFX delta not finding the baseline it expects.
Given your Local reinstall reset (OEM recovery image) + the fact you’ve already hit recovery/BitLocker events during update pipeline changes, the most reliable “non-destructive” recovery path is to re-lay down a known-good Microsoft image (without waiting for a matching ISO to appear manually).

Option A (best, minimal drama): “Reinstall now” (in-place repair via Windows Update)​

Check this first:
Settings → System → Recovery → Fix problems using Windows Update → Reinstall now
This is essentially Microsoft’s supported in-place repair path for exactly these “servicing is stuck / update won’t apply” situations, and it doesn’t require you to hunt down an ISO. (Microsoft Q&A responses are already pointing people to this flow for KB5077181 install failures.)

Option B: Use the latest Media Creation Tool and do an in-place upgrade repair​

There’s evidence that the current Windows 11 Media Creation Tool is now producing install media with the 26200.7840 baseline (i.e., already includes KB5077181).
That gives you exactly what you said you were missing earlier: a way to get onto 26200.7840 using official media, even if Windows Update’s PSFX delta keeps failing.
Process (high level):
1) Create USB/ISO with Media Creation Tool
2) From within Windows, mount ISO or open USB and run setup.exe
3) Choose Keep personal files and apps (in-place repair upgrade)

---

Two quick clarifiers (because one of your statements conflicts with your build)​

You wrote: “KB5077181 installs normally.” But if it actually installed, winver would show 26200.7840 (not 26200.7623).
So can you confirm what you mean by “installs normally”?

• Did the KB5077181 MSU/DISM command complete, but the system rolled back on reboot?
• Or did it truly install and you’re now on 26200.7840?

If you paste the exact output of:

Code:

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

…I can tell which state you’re in.

---

About “escalate this to Microsoft”​

I can’t directly escalate internally to the Windows Servicing team from WindowsForum, but I can tell you the fastest path that tends to reach the right queue:
1) Feedback Hub → Category: Windows Update / Installing updates
2) Attach:

• C:\Windows\Logs\CBS\CBS.log + newest CbsPersist_*.log
• C:\Windows\Logs\DISM\dism.log
• WindowsUpdateClient Operational EVTX export
  3) In the description, include the exact signature:
• PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING (0x800f0983) during Stage/Parallel hydration

If you want, upload the relevant log snippets here (zip is fine) and I’ll tell you exactly which 20–30 lines to include in the Feedback Hub report so it’s maximally actionable.
Bottom line: ignore KB5043080 for this case, and move to Reinstall now or an in-place repair upgrade using current Microsoft media to replace the baseline your PSFX delta can’t match.

Click to expand...

Best next step (recommended): Use MCT, then verify the ISO contains 26200.7840​

• Run Media Creation Tool → choose ISO file

• Look in E:\sources\

Then do the in-place repair upgrade (keep apps/files)​

• E:\setup.exe → choose Keep personal files and apps

Option A (“Reinstall now”) vs Option B (MCT)​

One last check (just to align expectations)​

ChatGPT said:

Yes — as of today (February 13, 2026) there’s credible evidence that the Windows 11 Media Creation Tool (MCT) backend payload is installing Windows 11 25H2 at build 26200.7840 (KB5077181 baseline).
And Microsoft’s KB for KB5077181 confirms the target build for 25H2 is 26200.7840.
That said, the MCT image it pulls is server-side and can change, so the clean way to “confirm” is to verify the build inside the ISO/USB you generate before you commit to the repair install.

Best next step (recommended): Use MCT, then verify the ISO contains 26200.7840​

1) Create an ISO (easier to inspect than a USB):

• Run Media Creation Tool → choose ISO file

2) Mount the ISO (double-click it), note the drive letter (say E:).
3) Check whether the media uses install.wim or install.esd:

• Look in E:\sources\

4) Run one of these (Admin Command Prompt):
If you have install.wim:
dism /Get-WimInfo /WimFile:E:\sources\install.wim
If you have install.esd:
dism /Get-WimInfo /WimFile:E:\sources\install.esd
In the output, look for Version/Build ~ 26200.7840 (often shown as 10.0.26200.7840).
If it does show 26200.7840, you’ve got exactly what you want: media that should lay down the missing baseline components that the PSFX delta can’t “hydrate” on your current Local-reinstall image.

Then do the in-place repair upgrade (keep apps/files)​

1) Suspend BitLocker/device encryption first (important in your case):
manage-bde -protectors -disable C:
2) From the mounted ISO, run:

• E:\setup.exe → choose Keep personal files and apps

3) After you’re stable and booted, re-enable protectors:
manage-bde -protectors -enable C:

Option A (“Reinstall now”) vs Option B (MCT)​

Given your history (Local reinstall + PSFX directory missing), Option B (MCT in-place repair) is the more deterministic “replace the baseline” approach.
Option A (Settings → System → Recovery → Fix problems using Windows Update → Reinstall now) can work too, but it still depends on Windows’ ability to download and apply a repair image through WU plumbing—which is exactly where you’re seeing PSFX staging failures.

One last check (just to align expectations)​

Your dism /online /get-packages | findstr /i 5077181 returning nothing is consistent with what you’re seeing: the LCU never reaches a committed package state (fails at Stage/hydration), so it won’t show as installed. That matches the PSFX_E_MATCHING_COMPONENT_DIRECTORY_MISSING (0x800f0983) pattern you already captured.
If you want, paste the dism /Get-WimInfo output from the ISO once you generate it (just the header + the index that matches your edition), and I’ll confirm whether it’s the right build/edition before you run setup.exe.

Click to expand...

1) Confirm whether the ISO has install.wim or install.esd​

• X:\sources\install.wim
• X:\sources\install.esd

2) Dump the image info​

3) Paste back (minimum needed)​

• The header section (Version/Build/ServicePack Build/Architecture)
• The index entry that matches your edition (likely Windows 11 Home)

• Architecture: x64 (amd64)
• Edition: Home (or “Home / Home Single Language” depending on OEM)
• Build: ideally 10.0.26200.7840 (or at least a newer 26200.78xx baseline)

Before you ngly recommended on your machine)​

ChatGPT said:

Correct — that “Copying 26200.7840_amd64…” text is just a folder/file label and doesn’t prove what’s actually inside the image. Waiting until the ISO is on the target laptop, mounting it, and running DISM /Get-WimInfo is exactly the right way to validate it before you run setup.exe.
Also, your plan lines up with what we’ve been seeing broadly: Microsoft has been shifting Media Creation Tool’s backend payload to newer “Patch Tuesday-aligned” images (so fresh media is closer to the current cumulative baseline), but it’s not guaranteed and can change server-side—so verification is key. y finishes: what to run + what to look for

1) Confirm whether the ISO has install.wim or install.esd​

Check:

• X:\sources\install.wim
• X:\sources\install.esd

2) Dump the image info​

Run one of these (Admin CMD):
If WIM:
dism /Get-WimInfo /WimFile:X:\sources\install.wim
If ESD:
dism /Get-WimInfo /WimFile:X:\sources\install.esd

3) Paste back (minimum needed)​

Please paste:

• The header section (Version/Build/ServicePack Build/Architecture)
• The index entry that matches your edition (likely Windows 11 Home)

What we’re specifically checking:

• Architecture: x64 (amd64)
• Edition: Home (or “Home / Home Single Language” depending on OEM)
• Build: ideally 10.0.26200.7840 (or at least a newer 26200.78xx baseline)

If the WIM/ESD reports a 26200.7840-level build, that supports the “MCT media includes the Patch Tuesday baseline” pattern we’ve discussed.

---

Before you ngly recommended on your machine)​

Because you’ve already had a BitLocker recovery event during servicing:
1) Suspend BitLocker/device encryption
manage-bde -protectors -disable C:
(And confirm you have the recovery key saved.)
2) Plug into AC power and (optional but wise) temporarily uninstall any third-party AV/EDR.
3) When setup.exe asks about updates, choose “Not right now” for the upgrade run, so it doesn’t try to pull the same problematic delta mid-upgrade. You can update after the baseline is repaired.
4) Choose Keep personal files and apps (this is what “re-lays down” the servicing baseline without nuking the system).
After you’re stable and booted:
manage-bde -protectors -enable C:

---

Send the DISM output when you have it (header + matching index), and I’ll confirm whether it’s the right build/edition to proceed.

Click to expand...

Please run one more command (this will show the build)​

• Version :
• ServicePack Build :
• Architecture :
• (and the Name : line you already pasted is fine)

• Version : 10.0.26200
• ServicePack Build : 7840 (or higher)

• Choose Not right now (so it doesn’t try to pull updates mid-upgrade)
• Choose Keep personal files and apps

If it’s not newer than 26200.7623​

• x64
• Version 10.0.26200
• ServicePack Build 7840

Proceed (recommended checklist)​

0) Quick prep (prevents avoidable failures)​

1) BitLocker / Device Encryption (important)​

2) Run the repair install from the mounted ISO​

• Run X:\setup.exe
• When asked about updates: choose Not right now
• Choose Keep personal files and apps

3) After it finishes​

• winver should show 26200.7840
  2) Re-enable BitLocker protectors:
  manage-bde -protectors -enable C:
  3) Go to Settings → Windows Update and check updates.
• In many cases, KB5077181 will effectively already be “baked in” since you’re now on 26200.7840, and Windows Update should stop offering it / stop failing.

If setup fails (just in case)​

• C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
• C:\$WINDOWS.~BT\Sources\Panther\setupact.log