Windows 11 26H2 and KB5124010: fixing AC-3 crashes and rolling back

KB5124010 (build 26300.9550, shipped 22 September) landed on Windows 11 26H2 with a Copilot key remapping, emoji 17.0 and a batch of Explorer fixes — and it brought two separate sets of complaints with it. I ran into the media side and spent the better part of an afternoon working out what was actually broken. This is the sequence I ended up with: figure out which problem you have, roll the package back, repair what it left behind, then prove the machine is stable instead of just quiet. Budget 25–40 minutes plus reboots, and treat it as intermediate level — elevated terminal, local admin rights, and one sacrificial test file.

The two problems look similar from the outside and they are not the same thing:

• On the media side, AC-3 (the codec marketed as Dolby Digital) decoding breaks inside legacy system components that Microsoft officially classifies as deprecated. Apps that route audio through those components abort instead of falling back to anything.
• On the preview-build side, people report random freezes, crashes when opening files, and one issue that touches security settings.

You need to know which one you are looking at before you remove anything. Two tools carry the whole fix: DISM handles system packages and component-store repair, SFC scans file integrity.

Before you start

• Confirm your own build number first. The numbers below are from my machine and may differ if the update never installed for you.
• Every command runs in an elevated Terminal, PowerShell or Command Prompt.
• At least 10 GB free on C: — the component-store repair writes temporary files there.
• One video or audio file whose soundtrack is AC-3. Without it you cannot reproduce the failure reliably.
• A second device with internet access, in case the affected PC gets unstable mid-fix and you need the steps on a screen.

Step 1: confirm the package and reproduce the crash

Start by checking what is actually installed:

Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OsVersion
Get-HotFix -Id KB5124010
dism /online /get-packages /format:table | Select-String "5124010"

You want OsBuildNumber showing 26300 and a Get-HotFix line with an InstalledOn date. If you instead get Get-HotFix : Cannot find the requested hotfix, the update is not your culprit and the rest of this guide is wasted effort — stop. Otherwise, copy the Package Identity that the third command prints; you will need it in step 2.

Now provoke the bug on purpose and grab the evidence:

Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000} -MaxEvents 10 |
  Select-Object TimeCreated, @{n='Event';e={$_.Message -split "`n" | Select-Object -First 4}}

Play the AC-3 file and open a handful of large files in Explorer at the same time. If new Application Error entries (Event ID 1000) show up with your test timestamp, and the player dies, refuses to launch, or quits mid-playback, you have reproduced it.

Step 2: remove the package, then repair the damage

The AC-3 failures come from legacy components the update breaks, so removing the package kills the cause rather than the symptom. The repair pass afterwards is what separates "stopped crashing" from "stopped crashing and stayed stable" — it fixes system files the failed update left in an inconsistent state.

wusa /uninstall /kb:5124010 /quiet /norestart

Plenty of cumulative packages refuse to go that way. If so, fall back to the identity you copied in step 1:

dism /online /remove-package /packagename:<exact Package Identity from Step 1> /norestart

Reboot, then go to Settings → Windows Update → Pause updates and pick the longest period offered, so the package does not quietly come back while you are testing. Then repair:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

A clean run prints The restore operation completed successfully. and then Windows Resource Protection did not find any integrity violations. If SFC reports that it found and repaired corrupt files, reboot once more and run it a second time — that pass should come back clean.

Two loose ends worth checking: in Settings → System → Optional features → More Windows features, make sure the media features you depend on are still enabled after the rollback, and confirm Get-HotFix -Id KB5124010 now returns "cannot find the requested hotfix". One caveat — if your apps themselves rely on the deprecated components, their availability is environment-specific. Check the vendor documentation rather than assuming the rollback restored them.

Step 3: verify with a timed window, not a vibe

The rollback also removes whatever the update brought with it: the Copilot key remapping, emoji 17.0, the Explorer fixes, plus those preview-build fixes. So confirm the machine is genuinely stable, don't just enjoy the silence.

Get-ComputerInfo | Select-Object OsBuildNumber
$since = (Get-Date).AddMinutes(-30)
(Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000; StartTime=$since} -ErrorAction SilentlyContinue).Count

That last number should be 0 after you repeat the same routine that used to crash. Anything non-zero means the failure is still there — check whether a fresh copy of the package reinstalled itself.

Run this checklist against your original symptoms:

• [ ] The AC-3 (Dolby Digital) file plays end to end and the app stays open.
• [ ] Opening 10–15 large files quickly in Explorer causes no freeze and no Explorer restart.
• [ ] Settings → Privacy & security renders normally.
• [ ] The Copilot key still does what you expect — if the remapping was part of what you rolled back, set it manually.
• [ ] Get-HotFix -Id KB5124010 reports the hotfix cannot be found.
• [ ] Updates stay paused until a fixed package ships.

All six boxes ticked plus a zero Event ID 1000 count across a full 30 minutes of normal work is the pass condition.

When it goes wrong

The media app closes or will not start once playback hits the Dolby Digital track. You will see Faulting application name: <app>.exe, Faulting module name: <legacy media module>.dll, Exception code: 0xc0000005 in Application Error (Event ID 1000), or The application was unable to start correctly (0xc0000142). on launch. That is the deprecated-component breakage described above; the fix is the uninstall, reboot, DISM /Online /Cleanup-Image /RestoreHealth, sfc /scannow sequence. As a stopgap while the machine is still patched, use a player that decodes AC-3 inside its own code instead of handing it to the system component, and switch the track to a non-AC-3 format.

The uninstall itself fails. Symptoms are 0x800f0922 from Windows Update, or DISM failed. No operation was performed. Both point at the same pair of causes: unfinished transactions sitting in the component store, or insufficient free space in the recovery environment. Clear those before you retry the removal.

Takeaway

The habit that saved me time here was ordering things properly: confirm the build before blaming an update, reproduce with a known test asset, timestamp your evidence from the Application log, remove by package identity when wusa balks, repair afterwards, and finish with a timed verification window instead of a quick smoke test. Nothing in this is exotic — it is the standard Windows repair loop, applied in the right order.

If you want the original write-up of this walkthrough, it first appeared on AI Release — https://ai-release.org — and shorter notes go out in the channel at https://t.me/ai_release1.