The short answer
The timing of a Windows update is a useful clue, not proof that its audio driver changed. First inspect the selected endpoint and reproduce the problem in a second app. Then compare the driver version and Device Manager status before deciding on rollback.
Separate simultaneous changes
On Windows 11, a system update may coincide with a new audio package, a changed default output, an app update or a reconnected display. Note the date, whether playback or capture is affected, and whether headphones, internal speakers and display audio behave differently. Keep volume low while testing.
Build a timeline instead of guessing
A laptop is updated overnight while connected to a monitor. The next morning a browser plays video without sound. Before blaming the update, inspect Sound settings: the monitor may now be selected and may have no speakers. If reselecting the laptop speakers restores audio, the driver was not shown to be the cause.
In another case, the internal speakers and analog jack both stop working, Device Manager shows a new audio-driver provider or version, and USB headphones still play. That is better evidence for investigating the host audio path. Check for rollback on that identified controller or use the exact model's supported prior package, then compare the same tests.
A microphone failure appearing after the same update can have a different cause from a playback failure. Make a local recording and check privacy permissions and the app's input choice. Keep notes on which tests worked and which versions changed; official support can use that record if both configuration and targeted recovery fail.
Build a before-and-after record
Check Settings > System > Sound for the default output and input. Try a known local sound and a brief microphone recording; an app can separately choose its own devices or need microphone permission. In Device Manager, inspect the relevant controller's provider, version and status. Review available update history to identify an actual driver change.
- Record the symptom and the Windows update date without assuming causation.
- Re-select the intended playback/input endpoints and compare two apps.
- Compare the affected controller's version, provider and status with any saved pre-update record.
- If a specific audio driver changed and a regression is reproducible, check rollback or a previously supported OEM package.
Caution: Do not uninstall broad sets of drivers or reverse security updates simply to test an unconfirmed audio theory.
Choose the smallest relevant fix
If the old endpoint was just replaced by a connected monitor, restore routing. If only an app microphone fails, check that app's input choice and permissions. If a known driver changed and several tests fail after it, use the targeted recovery procedure and retest after restart.
If a headset fails on multiple devices or the built-in speaker fails maker diagnostics, pursue hardware support. If the update included several changes and causation remains unclear, document the pattern for the device maker rather than guessing packages.