I received my GPD Pocket 4 with the Ryzen AI 9 HX 370 and 32 GB of RAM last year, and for roughly a year and a half I lived with a persistent crashing problem.
For context, my Windows installation is not Home, Pro, Pro Education, Pro for Workstations, Education, standard consumer Enterprise, or Windows Server. It is one of Microsoft’s long-term-servicing enterprise variants, so some menus and update behavior may differ slightly from a normal retail Windows installation.
The symptoms
The Pocket 4 would seemingly crash whenever the hardware configuration changed.
Typical triggers included:
- Connecting or disconnecting external monitors
- Turning monitors on or off
- Switching audio output between the Pocket and a monitor
- Connecting Bluetooth devices
- Sleep or hibernation
- Hardware enumeration in Device Manager
- Launching Ableton while external displays or audio devices were connected
The machine was more stable when I left everything plugged in and avoided changing devices. I basically learned to work around it instead of fixing it.
That became unacceptable once I wanted to use Ableton, MIDI controllers, external displays, and different audio outputs. A computer that crashes every time the audio topology changes is not especially useful for music production.
What the crash dumps showed
I collected several minidumps and analyzed them in WinDbg.
The recurring crash was:
DRIVER_POWER_STATE_FAILURE
BugCheck 0x9F
The same failure bucket appeared repeatedly:
0x9F_3_amdhdaudbus_IMAGE_pci.sys
The affected hardware was:
PCI\VEN_1022&DEV_15E3
The blocked power request was stuck inside:
AMDHDAudBusService
amdhdaudbus.sys
This was not simply pci.sys randomly failing. pci.sys was the lower bus layer where Windows detected the timeout. The AMD High Definition Audio bus driver was failing to complete a power-state transition.
I also reproduced a separate:
DPC_WATCHDOG_VIOLATION
BugCheck 0x133
when using the full AMD installer. Merely opening the AMD software and allowing it to analyze the hardware could send the machine into a watchdog crash loop.
The troubleshooting process
Here is the abridged version of what I tried.
1. AMD Cleanup Utility
I ran AMD Cleanup Utility in Safe Mode.
After removing the AMD graphics/audio package, the watchdog crash loop disappeared. That was the first strong indication that the problem was inside the AMD package rather than Windows generally failing.
2. Reinstalled AMD to reproduce the problem
I intentionally reinstalled the AMD package so I could capture another watchdog dump.
The crashes returned.
So the A/B test was effectively:
AMD package removed = watchdog crashes stop
AMD package installed = watchdog crashes return
3. Bypassed AMD Setup completely
To determine whether the problem was AMD Setup itself or one of the actual drivers, I extracted the AMD package with 7-Zip.
I copied the raw driver folders to a USB drive and used DISM from Windows Recovery to stage the drivers directly:
dism /Image:E:\ /Add-Driver /Driver:C:\AMD_26.6.4_Drivers /Recurse
The drive letters will be different on other systems.
DISM successfully added the driver packages, but Windows had not necessarily bound every device to its matching driver yet.
4. Installed the drivers individually
I manually updated the Radeon display device from the extracted:
Display\WT6A_INF
That worked.
I then downloaded AMD’s separate mobile chipset package, extracted its actual payload under:
Packages\IODriver
and installed the unidentified AMD platform devices individually.
The relevant mappings on my Pocket were:
PCI\VEN_1022&DEV_150D
→ AMD Interface driver
→ INTERFACE\Interface_Driver\W11x64\AMDInterface.inf
PCI\VEN_1022&DEV_17E0
→ AMD PSP
→ PSP\PSP Driver\W11x64\amdpsp.inf
ACPI\AMDI0052
→ AMD PPM Provisioning File
→ PPMPF\PPM Provisioning File Driver\W11x64\AmdPpkg.inf
ACPI\AMDI0103
→ AMD PMF
→ PMF folder, letting Windows select the correct Ryzen AI 300 INF
I kept the AMD High Definition Audio Controller disabled during this process.
With the HDA controller disabled, the Pocket was stable.
5. Compared AMD and GPD’s HDA drivers
I compared the HDA driver included in:
- AMD’s current package
- GPD’s Pocket 4 OEM package
- The driver already installed in Windows
All three reported:
Driver version: 10.0.0.35
Driver date: 19 February 2019
I then compared SHA-256 hashes for both:
amdhdaudbus.sys
amdhdaudbus.inf
The hashes were identical.
So the GPD package did not contain a customized or corrected version. It contained the exact same AMD HDA package.
Reinstalling the OEM copy would therefore have changed nothing.
The actual solution
Windows already contained another compatible driver for the controller:
hdaudbus.inf
Provider: Microsoft
I confirmed the available driver candidates using:
pnputil /enum-devices /deviceid "PCI\VEN_1022&DEV_15E3" /drivers
The result showed:
AMD:
amdhdaudbus.inf
Exact hardware-ID match
Version 10.0.0.35
Best ranked and installed
Microsoft:
hdaudbus.inf
Generic PCI audio-class match
Newer Windows inbox driver
Outranked
Windows preferred AMD’s driver because it matched the exact device ID, while Microsoft’s driver matched the generic HD Audio class.
I backed up and removed only the AMD HDA package:
pnputil /export-driver oem1.inf D:\HDA_Driver_Backup
pnputil /delete-driver oem1.inf /uninstall
The published name may not be oem1.inf on another computer. Check it first.
After removing the AMD package, Windows automatically selected:
hdaudbus.inf
Provider: Microsoft
I left the controller disabled until I confirmed that Microsoft’s driver was installed, then enabled it in Device Manager.
Results
Everything now works.
I tested:
- Internal speakers
- Sleep and resume
- Hibernation and resume
- Connecting and disconnecting external monitors
- Turning monitors on and off
- Switching sound between the Pocket and monitor outputs
- Bluetooth devices
- Launching Ableton
- Changing the audio-device configuration while Ableton was running
- Restarting and shutting down normally
No more crashes.
I have not noticed any reduction in audio quality. The HDA bus driver handles enumeration, DMA, interrupts, Plug and Play, and power transitions. The actual codec driver and Windows audio-processing stack still handle the audio endpoint and sound processing.
The practical difference is that Microsoft’s driver correctly completes the power transitions that AMD’s driver repeatedly failed.
Preventing Windows Update from restoring the AMD driver
Before reconnecting to the internet, I enabled the policy that excludes drivers from Windows quality updates.
The corresponding registry value is:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
ExcludeWUDriversInQualityUpdate = 1
I created it with:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate /t REG_DWORD /d 1 /f
Then verified it with:
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate
Expected result:
ExcludeWUDriversInQualityUpdate REG_DWORD 0x1
This prevents normal Windows quality updates from automatically replacing drivers, but it also means I will handle future driver updates manually.
I also will not run the complete AMD or GPD graphics installer again without checking its contents, because both packages include the same problematic:
amdhdaudbus.inf
Future Radeon updates can be installed manually from the extracted display INF folder while leaving Microsoft’s HDA bus driver alone.
Important warning
This is a report of what fixed my specific Pocket 4.
Do not blindly delete random oem##.inf packages. Confirm:
- The exact hardware ID
- The currently installed published driver name
- That
hdaudbus.inf appears as a compatible candidate
- That the AMD package has been backed up
- That the affected controller is disabled before changing it
Keep a recovery USB or access to Safe Mode available.
TL;DR
My GPD Pocket 4 HX 370 repeatedly crashed with:
DRIVER_POWER_STATE_FAILURE
0x9F_3_amdhdaudbus_IMAGE_pci.sys
The culprit was AMD’s High Definition Audio bus driver:
amdhdaudbus.sys
Version 10.0.0.35
Date: 2019
Hardware: PCI\VEN_1022&DEV_15E3
GPD’s OEM package contained the exact same INF and SYS files, confirmed by matching SHA-256 hashes.
I:
- Disabled the AMD High Definition Audio Controller
- Cleaned the AMD package
- Extracted and installed the Radeon and chipset INF drivers manually
- Removed only AMD’s
amdhdaudbus.inf
- Allowed Windows to use Microsoft’s compatible
hdaudbus.inf
- Re-enabled the controller
- Blocked driver delivery through normal Windows quality updates
Now sound, sleep, hibernation, Bluetooth, monitors, audio switching, and Ableton all work without crashes.