audio-revive

Diagnose and repair Windows playback devices that stop producing audio, without rebooting.

The problem

Your speakers stop working. Nothing plays in any application. YouTube shows "Audio renderer error. Please restart your computer." Spotify looks like it is playing but you hear nothing.

You check everything. Volume is up. Nothing is muted. The correct output device is selected. Device Manager shows no warning icon, and the device properties say "This device is working properly". Restarting the Windows Audio service changes nothing.

Rebooting fixes it. Then a few days later it happens again.

Why the usual advice does not help

Almost every guide for this assumes the driver failed to load: a yellow triangle, a red X, Code 10, "no audio device is installed". That is a real failure mode and it has known fixes.

This is a different one. The driver is loaded and healthy. The device reports CM_PROB_NONE. Windows will happily show you a volume slider for a device that cannot play a single sample. What actually fails is one layer lower: the audio engine cannot create the endpoint, and IAudioClient::Initialize returns AUDCLNT_E_ENDPOINT_CREATE_FAILED (0x8889000F) to every application that asks for it. Nothing in the Windows UI surfaces that error, so you are left staring at a device that claims to be fine.

A common trigger is a driver update that could not finish. OEM audio packages ship helper services and tray apps that keep handles open on the codec. When Windows Update tries to replace the driver it has to eject and recreate the device, those handles block the eject, and the install ends up half applied. Windows flags the device as needing a restart, and until that restart happens the controller refuses to open a streaming pin. You can see the blocked eject in the System event log as Kernel-PnP event 225.

That flag is also why the usual remedies do nothing. pnputil /restart-device does not fail silently, it refuses outright: "The device has a pending system restart to complete a previous operation."

What this does differently

It does not trust status flags. For every active playback endpoint it opens a real WASAPI stream, renders a short quiet tone, and reads the hardware peak meter. An endpoint that reports healthy but cannot render is caught immediately. This is also what distinguishes a broken output from a working one you simply are not listening to.

It repairs the device node, not just the service. The pending-restart flag lives on the device node itself, so destroying the node destroys the flag. Removing the node and rescanning rebuilds it clean, which is the part a reboot was doing for you.

It escalates, and stops as soon as audio works. Cheap and safe steps run first. The invasive one is opt-in and never runs by default.

It releases the handles first. The vendor services and tray apps that blocked the original driver install will block the rebuild in exactly the same way. They are stopped before the device is touched and started again afterwards.

Usage

Diagnose only. Changes nothing, needs no elevation for the checks that matter:

.\AudioRevive.ps1

Repair using the conservative steps. Requires an elevated PowerShell session:

.\AudioRevive.ps1 -Repair

Also allow rebuilding the parent controller, which is what recovers a device stuck behind a pending-restart flag:

.\AudioRevive.ps1 -Repair -Aggressive

Useful extras:

.\AudioRevive.ps1 -Repair -Aggressive -WhatIf      # show every action without performing it
.\AudioRevive.ps1 -Repair -Force                   # attempt repair on an unrecognised failure
.\AudioRevive.ps1 -LogPath .\audio.log             # keep a transcript

If PowerShell blocks the script, either unblock the file (Unblock-File .\AudioRevive.ps1) or run it with powershell -ExecutionPolicy Bypass -File .\AudioRevive.ps1.

What the repair actually does

Each step is followed by a fresh probe. If audio works, it stops there.

1. Restart the audio engine. Audiosrv and AudioEndpointBuilder. This fixes the subset of failures caused by a stuck service rather than a stuck device, and it is what most other scripts stop at.
2. Release vendor components and restart the device in place. Stops running audio services and tray apps from Realtek, Senary, Dolby, Waves, Nahimic, DTS, Elevoc, Conexant, Synaptics, Cirrus and similar, then pnputil /restart-device.
3. Rebuild the audio device node. pnputil /remove-device followed by /scan-devices. Windows reinstalls it from the existing driver package.
4. Rebuild the parent controller (-Aggressive only). Same operation one level up the device tree, with /subtree. This is the step that clears a pending-restart flag.

Afterwards it restarts the vendor services it stopped, and restarts the long-lived audio process inside Chrome, Edge, Brave, Opera and Vivaldi so they reconnect to the rebuilt endpoint. That is safe: browsers respawn it on demand and no tabs are lost.

Risks

Step 4 removes the device node of your audio controller and asks Windows to rediscover it. Windows reinstalls it automatically from the driver package already in the DriverStore, and in testing the device came back within seconds. But you should know what you are agreeing to:

• If the rebuild does not complete, you have no audio until you reboot. A reboot recovers it, because that is exactly the pending operation Windows was waiting to perform.
• Audio drops out for several seconds during the rebuild. Do not run this in the middle of a call.
• The script never deletes driver packages and never touches the DriverStore, so nothing is permanently removed. This is a rebuild, not an uninstall.

Run with -WhatIf first if you want to see the exact sequence for your machine.

The script also reports pending-reboot markers when it finds them, but deliberately does not clear them. Removing those registry keys by hand can leave Windows servicing in an inconsistent state, and it is not needed: rebuilding the device node is enough.

When this will not help

• The driver genuinely failed to load (yellow triangle, Code 10, "no audio device is installed"). Different problem, well covered elsewhere. The diagnostic output will tell you, since the failure appears at a different stage.
• No active endpoints at all. If Windows sees no output device, there is nothing to probe.
• The output is fine and you are listening to the wrong one. The diagnostic covers this: if every endpoint renders correctly, the problem is your output selection, a muted app in the volume mixer, or the hardware itself.
• Bluetooth headsets. They fail in their own ways and go through a different stack.

Background

This came out of debugging one machine where the internal speakers went silent while both monitor outputs over HDMI kept working. That contrast is the giveaway: the HDMI outputs hang off the GPU, and the internal speakers off the audio controller that was stuck.

The measured evidence on that machine:

Endpoint	WASAPI result
Display audio (monitor 1)	renders, peak 0.35
Internal speakers (default)	AUDCLNT_E_ENDPOINT_CREATE_FAILED
Display audio (monitor 2)	renders, peak 0.35

Restarting the audio services, disabling and re-enabling the endpoint, pnputil /restart-device and WASAPI raw mode all failed. Rebuilding the codec's own device node was not enough either. Rebuilding the parent controller worked, and audio returned without a reboot.

One caveat worth stating plainly: the repair path has been verified end to end on a single machine, an Intel Smart Sound controller with a Senary codec. The diagnostic half is generic and safe everywhere. If it works, or fails, on other hardware, please open an issue with the diagnostic output so the vendor patterns and escalation can be improved.

License

MIT