Safely Uninstall KB5063878 on Windows 11: DISM and SFC Guide

Last month’s Windows 11 patch KB5063878 triggered a flurry of alarm among power users and IT pros after a narrow set of SSDs began disappearing under heavy write conditions — a regression serious enough that some users experienced irrecoverable data loss. This feature walks through a practical, safe workflow to remove KB5063878 when necessary, explains why the problem occurred, and offers measured guidance for recovery, blocking the faulty package, and restoring system stability while preserving security posture.

Background: what KB5063878 changed and why it matters​

Microsoft shipped KB5063878 as a cumulative update for Windows 11 (24H2), delivered as a combined servicing stack update (SSU) plus the latest cumulative update (LCU). Combined SSU+LCU packages change how removals behave: the included servicing stack content cannot be rolled back by simple wusa commands, and in many cases the recommended removal path requires DISM with the LCU package name. This implementation detail explains why some attempts to uninstall the August cumulative failed with servicing errors.
Two distinct classes of regressions emerged after the rollout. First, creators using NDI/OBS reported severe stuttering when the NDI default transport (RUDP) was used — a high-profile streaming regression requiring immediate workarounds for production workflows. Second, and more concerning to end users, a small subset of SSDs (under very specific workloads and firmware conditions) would go offline during prolonged large writes, sometimes resulting in corrupted partitions and lost data. Community reproductions and vendor testing prompted Microsoft and storage vendors to investigate.
Early vendor and community triage suggested the storage incidents were workload-sensitive rather than universal: aggressive single-session writes (for example, sustained 50+ GB transfers on drives that are far from empty) were the typical trigger. That pattern, plus vendor telemetry, narrowed the impact to certain controller/firmware combinations — notably engineering or review‑sample firmware in some reports — rather than a wholesale failure affecting all retail SSDs. Still, the risk of data loss is non-trivial for affected systems, which is why many admins and enthusiasts chose to roll back the update as a precaution.

---

Quick summary: when to consider uninstalling KB5063878​

• You experienced an SSD that became inaccessible, disappeared from Disk Management, or showed corrupted partitions after installing KB5063878.
• You’ve observed recurring device disappearances during large sequential writes after the update.
• You are running production workloads (content capture, large file transfers, VMs) where an intermittent drive disappearance is unacceptable.

If none of the above apply — if your machine is behaving normally and your SSD vendor confirms your model/firmware is unaffected — uninstalling a security cumulative update is usually unnecessary and increases exposure. Proceed thoughtfully: removing an LCU reopens the attack surface patched by that update.

---

Before you begin: safety steps every user must take​

• Make a full backup or disk image of any machine you will modify. Use tools like Macrium Reflect, Acronis, or your vendor’s imaging utility. Backups are non-negotiable when servicing OS-level updates or touching storage that has already shown instability.
• If your SSD is still visible but exhibiting problems, do not perform destructive actions (no repartitioning, reformatting, or low-level writes) until you’ve attempted non-destructive recovery and collected vendor logs.
• Identify your exact Windows build (run winver) and confirm whether KB5063878 (or the correlated KB on older builds) is installed. This prevents mistaken uninstalls.

---

How to uninstall KB5063878 on Windows 11 — safe, step-by-step guide​

The user-friendly uninstall path is Settings → Windows Update → Update history → Uninstall updates. However, because KB5063878 was often shipped as a combined SSU+LCU, some systems will not let Settings remove the package completely. Follow this ordered approach: try the simple path first, then escalate to the supported DISM removal and repair steps if you encounter errors.

1) Standard GUI removal (try this first)​

• Open Settings → System → Optional features → More Windows features. If Windows Sandbox is enabled, uncheck it and click OK (this can prevent installer errors like 0x800F0825 reported during some uninstall attempts). Restart when prompted.
• After reboot, open Settings → Windows Update → Update history → Uninstall updates. Locate KB5063878 (example: OS Build 26100.4946) and choose Uninstall. Restart when instructed.
• Once the system restarts and you confirm behavior has improved, go back to Settings → Windows Update and Pause updates for 1 week (you can use this pause repeatedly) to prevent automatic reinstallation while you wait for a vendor/Microsoft fix.

If the GUI removal succeeds and your SSD stability is restored, preserve the backup and monitor vendor advisories before re-enabling updates.

2) If Settings fails: use DISM to remove the LCU​

When the combined package prevents standard uninstallation, the supported approach is to remove just the LCU using DISM:

• Open an elevated Command Prompt (Run as Administrator).
• List installed packages and find the LCU identifier:
• dism /online /get-packages | findstr KB5063878
  Note the full Package Identity string that matches the LCU.
• Remove the package by identity:
• dism /online /remove-package /packagename:<PackageIdentity>
• Reboot and check whether the drive reappears and stability is restored.

Caveat: DISM manipulates the component store; removal can fail if the component store is unhealthy. If DISM returns errors, run the repair flow below and retry. This removal method is documented by Microsoft for combined SSU+LCU scenarios.

3) Repair the component store and system files (SFC + DISM restore)​

If removals fail with servicing errors (for example, 0x800f0905), repair the image and protected files before retrying:

• Open elevated CMD and run:
• DISM /Online /Cleanup-Image /RestoreHealth
• sfc /scannow
• Reboot and retry the DISM remove-package command if needed.

This sequence is Microsoft's recommended method to repair image corruption that can block uninstall operations.

4) If you still get installer errors: additional tips​

• Stop update services and clear update caches:
• net stop wuauserv
• net stop bits
• net stop cryptsvc
• ren %SystemRoot%\SoftwareDistribution SoftwareDistribution.old
• ren %SystemRoot%\System32\catroot2 catroot2.old
• net start wuauserv
• net start bits
• net start cryptsvc
  Then reboot and retry the uninstall. This removes possibly corrupted update payloads that can cause 0x800f0905/0x800f0825 failures.
• Try a Clean Boot (msconfig → selective startup) to exclude third‑party interference, then retry uninstall steps.

---

How to prevent KB5063878 from reinstalling (block the KB)​

After a successful rollback you’ll want to stop Windows Update from reapplying the faulty package until Microsoft ships a corrected build.

• Pause updates: Settings → Windows Update → Pause updates for 7 days (repeat as needed). This gives time but is temporary.
• Use Microsoft’s “Show or hide updates” troubleshooter (wushowhide.diagcab) to hide KB5063878 so Windows Update won’t reinstall it automatically. Run the tool and select Hide updates → pick KB5063878. This is the most reliable way for consumer machines to block a specific KB.
• Enterprise: hold approvals in WSUS/Intune/SCCM or apply Known Issue Rollback (KIR) policies where available. For large fleets, uninstalling the LCU on every endpoint is impractical; use update-management tooling to stage and block the problematic package.

---

If your SSD already disappeared: recovery and diagnosis checklist​

If the drive vanished after the update and isn’t recovered by uninstalling the KB, follow this ordered approach:

• Reboot gracefully and check Device Manager and Disk Management for the device. If the drive appears offline or uninitialized, do not format or initialize the disk without a backup or diagnostic data dump.
• Run vendor diagnostic tools (WD Dashboard, Crucial Storage Executive, Samsung Magician, CrystalDiskInfo) to collect SMART data and controller status. These tools often reveal whether the controller responded to host commands or if firmware entered a fail‑state.
• If the vendor provides a firmware recovery or reflash utility and explicitly documents it as safe, follow vendor instructions (back up first; firmware updates are not risk-free).
• If diagnostics fail and data is critical, stop additional attempts and consult professional data-recovery services; further random writes may reduce the chance of successful recovery.

---

Root cause analysis: what likely happened (and what’s still uncertain)​

Community investigations and vendor triage indicate the issue was narrowly scoped: certain controller firmware revisions, when combined with the OS change in KB5063878 and particular large-write workloads, could cause the drive to become unresponsive. Independent testing replicated the failure on affected samples; vendors and Microsoft were engaged to reproduce and confirm telemetry. Some reports pointed to engineering or review-sample firmware used in early press samples as being the primary culprit for many of the reproducible failures, explaining why many retail drives remained unaffected. However, distinguishing engineering-firmware-only incidents from retail firmware regressions across millions of devices requires vendor confirmation per model and firmware revision. Until that vendor-level confirmation exists for a specific drive, assume risk if you match the reproduction profile (large sustained writes, particular controller families, older firmware).
Caution: while the community reproduced and narrowed the conditions to a small set of combinations, not every claim has been independently verified at scale — treat model lists shared by enthusiasts as candidate lists, not final blacklists. Always confirm with your SSD vendor before assuming your drive is safe.

---

Weighing the trade-offs: security vs. reliability​

Uninstalling a cumulative security update is not a neutral action. The August cumulative patched vulnerabilities and delivered important fixes; rolling it back re-exposes those systems until a patched replacement is installed. The right choice depends on risk calculus:

• If your machine is a production or media-creation rig where a disappearing drive can destroy work-in-progress, rollback is often the safer short-term choice, combined with blocking the KB and applying vendor firmware updates where available.
• If your machine is used for general web browsing and personal tasks, and your SSD shows no sign of instability, staying patched is usually preferable. Monitor vendor advisories and the Windows Release Health dashboard for fixes before deciding to uninstall.

Administrators should pilot any rollback or re-deployment on a small ring and validate large-write behavior across representative hardware before widescale changes. The Known Issue Rollback mechanism and targeted Microsoft mitigations are preferable for enterprises when available.

---

What vendors and Microsoft did — and what to watch for next​

Vendors and Microsoft coordinated to investigate and validate reproductions. Microsoft has historically used Known Issue Rollback (KIR) for similar cases and may release a targeted out‑of‑band patch or corrected cumulative once the precise failure mode is identified and mitigations tested. SSD vendors may publish firmware updates or advisory guidance for affected controller revisions.
What to watch for:

• Vendor firmware advisories and firmware downloads for your exact model/revision.
• Microsoft Release Health updates or an updated cumulative demonstrating a corrected build number.
• Official guidance confirming whether affected units were engineering/review samples or retail models.

Until official vendor confirmation for your drive, treat community lists and reproduce reports as credible but requiring vendor validation.

---

Practical recommendations for users and IT pros (short checklist)​

• Back up: create a full system image before attempting rollbacks or firmware updates.
• Test in a small ring: don’t push changes to mission-critical machines without staging.
• If affected: uninstall the LCU (Settings or DISM), pause/hide the update, and install vendor firmware updates if available.
• If not affected: continue to patch. Monitor vendor patches and Microsoft Release Health before applying the next cumulative.
• For enterprises: prefer KIR or managed-blocking approaches; avoid mass uninstalls unless absolutely necessary.

---

Frequently encountered error codes and quick fixes​

• 0x800F0825 (Windows Features / Sandbox interaction): Disable Windows Sandbox under System → Optional features → More Windows features, reboot, and then retry uninstall. Re-enable Sandbox after the uninstall if needed.
• 0x800f0905 (DISM / LCU removal failures): Repair component store with DISM /RestoreHealth and run sfc /scannow, clear Windows Update caches, then retry DISM removal. If the GUI fails, target the LCU by name with DISM.

---

Final analysis: strengths and risks of the ecosystem response​

Strengths:

• Rapid community triage surfaced reproducible test vectors quickly and accelerated vendor triage. Enthusiast testing often finds real-world edge cases that large vendor labs may not exercise frequently.
• Microsoft’s update-management tools (DISM, KIR, wushowhide) give administrators practical ways to remediate while a permanent fix is developed.

Risks:

• Hardware diversity makes exhaustive pre-release testing impossible; rare controller/firmware combos can still slip through. The consequence — potential data loss — is severe and far exceeds typical driver or peripheral regressions.
• Rolling back security updates creates windows of exposure. Blocking updates must be a controlled, temporary measure paired with a plan to reinstall corrected patches as soon as they’re available.

---

Conclusion — practical takeaways​

The KB5063878 incident is a textbook example of how deep interactions between OS updates and diverse device firmware can surface rare but painful regressions. For most users, retail SSDs remained safe; for a small cohort under specific workloads and firmware states, the update could trigger drive disappearances. If you are affected, the responsible path is clear: back up immediately, uninstall the LCU (using Settings or DISM), hide/pause the KB to prevent reinstallation, and coordinate with your SSD vendor for firmware fixes or recovery instructions. If you are not affected, stay patched and watch vendor and Microsoft advisories for a corrected release.
This is a reminder that robust backup habits and staged update policies are not optional — they’re essential insurance against the low-probability but high-impact failure modes that can emerge from interactions between OS changes and device firmware.

---

Source: Windows Report How to Uninstall KB5063878 Update to Fix SSD Failures on Windows 11