ASUS ROG Zephyrus G14: Analyzing Crash Dumps and Removing the AMD Driver
Contents
My laptop, an ASUS ROG Zephyrus G14 (official support page), has been crashing repeatedly.
In addition to crash dumps recorded on September 30, abnormal GPU-related shutdowns were logged on October 3 and October 15.
To isolate the root cause, I set up a script to continuously record system logs during subsequent crashes while analyzing past dumps and the existing driver setup.
PC Environment
| Item | Details |
|---|---|
| Model | ASUS ROG Zephyrus G14 |
| OS | Windows 11 Home (version 10.0.26200.0) |
| CPU | AMD Ryzen 7 5800HS (8 cores / 16 threads) |
| Memory | 16 GB |
| Integrated GPU | AMD Radeon Graphics |
| Discrete GPU | NVIDIA GeForce RTX 3050 Ti Laptop GPU (4 GB VRAM) |
This laptop has an integrated AMD Radeon Graphics unit on the CPU and a discrete NVIDIA GeForce RTX 3050 Ti Laptop GPU. The AMD GPU handles day-to-day display output and power-saving controls. Because of this setup, malfunctions in the AMD driver can trigger display timeouts and system crashes independently of the discrete GPU.
MEMORY_MANAGEMENT During Audio Processing
Records of Windows Blue Screen of Death (BSoD) events were saved in C:\Windows\Minidump.
Analyzing these minidumps with WinDbg revealed that the two crashes on September 30 and the crash on October 15 all shared stop code 0x1A (MEMORY_MANAGEMENT).
In all three instances, the crashing process was audiodg.exe, the first argument was 0x1230, and the failure location was identically portcls!CPortPinWaveRT::Close+0x31f.
| Timestamp (JST) | Stop Code | Process | Failure Location |
|---|---|---|---|
| September 30, 02:46:00 | 0x1A (arg1: 0x1230) | audiodg.exe | portcls!CPortPinWaveRT::Close+0x31f |
| September 30, 02:53:04 | 0x1A (arg1: 0x1230) | audiodg.exe | portcls!CPortPinWaveRT::Close+0x31f |
| October 15, 03:44:32 | 0x1A (arg1: 0x1230) | audiodg.exe | portcls!CPortPinWaveRT::Close+0x31f |
portcls.sys is the Windows Port Class audio driver component (Microsoft Port Class documentation). The crashes occurred during the transition from CPortPinWaveRT::Close, which closes an audio stream, to memory deallocation (MmUnmapLockedPages).
The call stack also included Realtek’s audio driver RTKVHD64.sys. The relevant portion of the stack trace:
PROCESS_NAME: audiodg.exe
nt!MiUnmapLockedPagesInUserSpace
nt!MmUnmapLockedPages
portcls!CPortPinWaveRT::Close+0x31f
portcls!DispatchClose
ks!KsDispatchIrp
portcls!PcDispatchIrp
RTKVHD64+0x243aaa
FAILURE_BUCKET_ID: 0x1a_1230_portcls!CPortPinWaveRT::CloseThe system halted on different days with the same combination of audiodg.exe and RTKVHD64.sys. Memory unmapping errors repeatedly triggered during audio stream teardown.
GPU Timeouts in amdkmdag.sys
In addition to minidumps, separate logs were stored in C:\Windows\LiveKernelReports\WATCHDOG.
These are Windows live kernel dumps (LiveKernel), which record abnormal system states without halting the entire operating system.
Five of the seven saved files were VIDEO_ENGINE_TIMEOUT_DETECTED (code 0x141).
This bug check code indicates that a graphics processing engine failed to respond within its allotted time. Windows records these as LiveKernel dumps rather than full system halts (Microsoft 0x141 documentation).
| Timestamp (JST) | Code | Description | Analysis Result |
|---|---|---|---|
| September 30, 02:52:43 | 0x193 | VIDEO_DXGKRNL_LIVEDUMP | - |
| September 30, 02:56:53 | 0x141 | VIDEO_ENGINE_TIMEOUT_DETECTED | amdkmdag.sys (+0xfa9c0) |
| October 3, 17:19:22 | 0x141 | VIDEO_ENGINE_TIMEOUT_DETECTED | amdkmdag.sys (+0xfa9c0) |
| October 15, 03:20:10 | 0x141 | VIDEO_ENGINE_TIMEOUT_DETECTED | amdkmdag.sys (+0xfa9c0) |
| October 15, 03:47:28 | 0x141 | VIDEO_ENGINE_TIMEOUT_DETECTED | amdkmdag.sys (+0xfa9c0) |
| October 15, 03:56:18 | 0x141 | VIDEO_ENGINE_TIMEOUT_DETECTED | amdkmdag.sys (+0xfa9c0) |
| October 15, 04:05:37 | 0x1A8 | VIDEO_DXGKRNL_BLACK_SCREEN_LIVEDUMP | - |
All five timeouts originated in amdkmdag.sys, AMD’s GPU driver, at the identical offset +0xfa9c0. The timeouts occurred repeatedly at the exact same location between September 30 and October 15.
With AMD driver timeouts recurring alongside audio processing crashes, I started by reviewing the graphics driver setup.
CrashMon: Continuous System Monitoring via PowerShell
Alongside dump analysis, I prepared a PowerShell monitoring script named “CrashMon” to continuously log system metrics leading up to a crash.
The script is located in C:\CrashMon.
I configured Windows to produce complete memory dumps upon system failure and disabled automatic deletion of MEMORY.DMP during low disk space conditions.
I also expanded event log capacities for both System and Application, and enabled diagnostic logs for power management, storage, and GPU events.
The recording script, logger.ps1, runs under the SYSTEM account via Windows Task Scheduler.
It triggers at system startup and every five minutes as a heartbeat check, with internal locks to prevent concurrent runs. After setup, the scheduled task registered as Running.
| Logged Metric | Details |
|---|---|
| Heartbeat | Timestamp, system uptime |
| CPU and Memory | CPU utilization, available memory, commit charge, non-paged pool size |
| Disk | Utilization rate, queue length, I/O latency, read/write volume |
| Power and Thermals | Reported sensor temperatures, AC power status, battery level |
| Network | Ping response times to the local gateway and external IPs |
| Processes | Total process count, targeted background services (e.g., RustDesk), top CPU/memory consumers |
The primary loop runs every 15 seconds, while heavy queries for top processes run once every four iterations (roughly once per minute).
To prevent buffered logs from being lost during sudden system freezes, every write operation flushes immediately to disk.
The script also mirrors logs to external media if a CrashMon directory is present on a removable USB drive.
In the same directory, collect.ps1 gathers event logs, dump files, and system information in a single pass after reboots to collect detailed diagnostic records following any future crash.
Chipset Driver Rollback via DriverStore
Suspecting potential chipset involvement in addition to GPU issues, I created a system restore point and disabled Windows Fast Startup.
Next, I ran a script to roll back AMD chipset drivers to an earlier stable state.
The script uninstalls newer driver packages from the Windows DriverStore and prompts device redetection. This allows the system to fall back onto older stored packages.
While package removals completed without errors, the driver versions reported immediately afterward remained identical to their pre-execution states:
| Device | Pre-Rollback Version | Post-Rollback Version |
|---|---|---|
| AMD Micro PEP Device | 1.0.29.0 | 1.0.29.0 |
| AMD I2C Controller | 1.2.0.131 | 1.2.0.131 |
| AMD GPIO Controller | 2.2.0.137 | 2.2.0.137 |
| AMD SMBus | 5.12.0.44 | 5.12.0.44 |
| AMD PSP 10.0 Device | 5.46.0.0 | 5.46.0.0 |
For the Micro PEP device, an unused package (1.0.47.1) was purged, while active version 1.0.29.0 stayed in place.
The GPIO Controller and PSP Device reported that changes required a full system restart to take effect.
Removing AMD Adrenalin
During the chipset adjustment, another 0x141 timeout in amdkmdag.sys was logged in the LiveKernel dump directory.
Because AMD’s generic Adrenalin software appeared to be a key source of instability, I decided to revert to ASUS’s certified OEM drivers instead.
The target was Adrenalin 26.5.2, manually installed on September 30.
I uninstalled five AMD utilities, including AMD Settings, and removed the display driver package along with components such as OpenCL and AMD Crash Defender.
All uninstallers completed cleanly. The integrated AMD graphics controller fell back to the Windows in-box “Microsoft Basic Display Adapter.” Display adapter status at this stage:
| Display Adapter | Driver Version |
|---|---|
| NVIDIA GeForce RTX 3050 Ti Laptop GPU | 32.0.16.1714 |
| Microsoft Basic Display Adapter | 10.0.26100.1 |
During the Adrenalin uninstallation, a black screen LiveKernel dump (0x1A8: VIDEO_DXGKRNL_BLACK_SCREEN_LIVEDUMP) was logged.
Arguments indicated that the operating system detected a connected display but failed to activate the display path, matching the expected behavior when video output resets as the AMD driver detaches.
SYSTEM_SERVICE_EXCEPTION During Virtual GPU Processing
Shortly after removing Adrenalin, a minidump from a different failure category appeared.
The stop code was SYSTEM_SERVICE_EXCEPTION (0x3B), with exception code 0xC0000005 denoting an access violation:
PROCESS_NAME: vmwp.exe
BUGCHECK_CODE: 3b
BUGCHECK_P1: c0000005
dxgkrnl!DXGAUTOPUSHLOCKSHARED::DXGAUTOPUSHLOCKSHARED
dxgkrnl!DXGK_VIRTUAL_GPU_PARAV::VirtualGpuDriverEscape
dxgkrnl!DxgkDdiVirtualGpuDriverEscape
dxgkrnl!DpiFdoDispatchIoctl
dxgkrnl!DpiDispatchIoctl
nvlddmkm+0x19394f2The crashed process was vmwp.exe, the worker process that hosts virtual machines for Hyper-V and WSL2.
The stack trace contained virtual GPU interfaces from the Windows DirectX graphics kernel (dxgkrnl.sys) along with NVIDIA’s kernel driver, nvlddmkm.sys. Unlike the timeouts on the AMD side, this indicated an access violation occurring within NVIDIA GPU paths accessed through GPU virtualization.
To prevent Windows Update from automatically delivering replacement drivers during subsequent installations, I set ExcludeWUDriversInQualityUpdate=1 and SearchOrderConfig=0 to suppress automatic driver updates.
The crash dumps collected from the system separated into three distinct failure points: 0x1A in audio processing, 0x141 timeouts in the AMD driver, and 0x3B inside virtual GPU handling. With CrashMon actively logging system health, testing now continues with ASUS’s certified OEM drivers to observe system stability.