![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(0, 43%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELF%3C/text%3E%3C/svg%3E)
Hi Leonid,
Your diagnostics already point at the cause. 0xC000038E is STATUS_DRIVER_FAILED_PRIOR_UNLOAD: after the DSP firmware timeout, the previous instance of IntcOED.sys never finished unloading, so Windows can't load a new one. That's why audio services keep running and only a reboot brings the microphones back. A fix has to come from Intel/Surface in the driver or firmware. Until then, here's how to recover without a reboot, reduce how often it happens, and get it to the right team.
1. Try to recover without rebooting
Restarting only the OED device usually fails with the same status, because the old image is still loaded. Restart the whole audio controller stack instead, so the parent unloads its children. In an elevated PowerShell:
# Find the Intel SST audio controller and the OED device
Get-PnpDevice | Where-Object FriendlyName -match "Smart Sound|SST|Audio Controller" |
Format-Table Status, FriendlyName, InstanceId -AutoSize
# Restart the parent controller (use its InstanceId from the list above)
pnputil /restart-device "<InstanceId of the Intel Smart Sound Technology Audio Controller>"
If the microphones come back, save it as a script you can run instead of rebooting. If pnputil reports that a restart is required, the stack can't unload without a reboot on the current driver.
2. Make sure you're on the latest Surface driver pack
Windows Update often lags behind the Surface driver/firmware MSI. Download the Surface Laptop for Business 7th Edition (Intel) driver and firmware pack from the Microsoft Download Center and install it. Then compare the version of Intel Smart Sound Technology OED (Device Manager → System devices → Properties → Driver) before and after.
3. Reduce exposure while waiting for a fix
Every occurrence you describe involves a Bluetooth headset. On recent Intel platforms, Bluetooth audio, especially the headset microphone (Hands-Free profile), is routed through the SST DSP. Two things to test, one at a time:
- Settings → System → Power & battery → Power mode: Best performance while on calls. This reduces aggressive DSP power transitions, which fits your power-management suspicion.
- Use the laptop's built-in microphone with BT headphones for output only. Control Panel → Devices and Printers → your headset → Properties → Services → untick Handsfree Telephony. You lose the headset mic but keep stereo audio. If the crashes stop, that's strong evidence for the HFP offload path, and worth reporting.
4. Get it in front of the right people
Q&A can't trigger a driver investigation, but these channels can:
- Feedback Hub → Hardware, Devices and Drivers → Audio. Use Recreate my problem with Audio selected. Start the capture, reproduce until the mic disappears, then stop. This attaches the audio and PnP traces engineers need. Share the feedback link here so others with the same device can upvote it.
- Surface for Business support (through the Surface Management Portal or your business support contract). Mention the device ID
INTELAUDIO\DSP_CTLR_DEV_A828, Intel-SST-OED Event 22, Kernel-PnP Event 219 with0xC000038E, and the timestamps you listed.
I'm not aware of a published known issue for this exact signature, so a Feedback Hub entry with traces is the most useful thing you can add.