英語版で読む
技術約8分で読めます

ROG Zephyrus G14が繰り返し落ちるのでダンプを調べてAMDドライバを削除した

WindowsAMDNVIDIAGPUトラブルシューティング
いけさん目次

使用しているノートPC、ASUS ROG Zephyrus G14（公式サポートページ）が繰り返しクラッシュする。
9月30日に残っていたダンプに加えて、10月3日と10月15日にもGPUまわりの異常停止が記録されていた。
原因を切り分けるため、次にクラッシュしたときのログを常時残すスクリプトを動かしつつ、過去のダンプとドライバの構成を調べてみた。

PC環境

項目内容
機種ASUS ROG Zephyrus G14
OSWindows 11 Home（バージョン 10.0.26200.0）
CPUAMD Ryzen 7 5800HS（8コア / 16スレッド）
メモリ16GB
内蔵GPUAMD Radeon Graphics
外部GPUNVIDIA GeForce RTX 3050 Ti Laptop GPU（4GB VRAM）

このPCはCPU内蔵のAMD Radeon Graphicsと外部GPUのNVIDIA GeForce RTX 3050 Tiを併用する構成で、普段の画面表示や省電力制御はAMD側が担っている。そのため、外部GPUとは別にAMD側ドライバの不調でも画面のタイムアウトやシステムクラッシュが起きる。

音声処理で起きていたMEMORY_MANAGEMENT

Windowsがブルースクリーン（BSoD）で停止したときの記録は、C:\Windows\Minidump に保存されていた。
WinDbgでミニダンプを解析したところ、9月30日の2件と10月15日の1件はいずれも停止コード 0x1A（MEMORY_MANAGEMENT）だった。

3件ともプロセスは audiodg.exe、第1引数は 0x1230、停止位置は portcls!CPortPinWaveRT::Close+0x31f（モジュール名!関数名+オフセット 表記）で完全に一致している。

発生日時（JST）停止コードプロセス停止位置
9月30日 02:46:000x1A (arg1: 0x1230)audiodg.exeportcls!CPortPinWaveRT::Close+0x31f
9月30日 02:53:040x1A (arg1: 0x1230)audiodg.exeportcls!CPortPinWaveRT::Close+0x31f
10月15日 03:44:320x1A (arg1: 0x1230)audiodg.exeportcls!CPortPinWaveRT::Close+0x31f

portcls.sys はWindowsのオーディオドライバ共通部分（MicrosoftのPort Classの説明）で、音声ストリームを閉じる CPortPinWaveRT::Close からメモリの割り当て解除（MmUnmapLockedPages）へ進んだところで停止していた。

処理の呼び出し履歴（スタック）には、Realtekのオーディオドライバ RTKVHD64.sys も含まれている。関係する部分のスタックはこんな感じ。

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::Close

日をまたいで同じ audiodg.exe と RTKVHD64.sys の組み合わせで停止しており、音声の再生・終了処理が絡む箇所でメモリ解放エラーが起きていた。

amdkmdag.sysによるGPUタイムアウト

ミニダンプとは別に、C:\Windows\LiveKernelReports\WATCHDOG にも記録が残っていた。
こちらはOS全体を強制停止させずに異常状態を保存するライブカーネルダンプ（LiveKernelダンプ）だ。

保存されていた7件のうち5件は VIDEO_ENGINE_TIMEOUT_DETECTED（コード 0x141）だった。
グラフィックス処理エンジンが時間内に応答しなかったことを示すコードで、通常のブルースクリーンではなくLiveKernelダンプとして記録される（Microsoftの0x141の説明）。

発生日時（JST）コード概要解析結果
9月30日 02:52:430x193VIDEO_DXGKRNL_LIVEDUMP-
9月30日 02:56:530x141VIDEO_ENGINE_TIMEOUT_DETECTEDamdkmdag.sys (+0xfa9c0)
10月3日 17:19:220x141VIDEO_ENGINE_TIMEOUT_DETECTEDamdkmdag.sys (+0xfa9c0)
10月15日 03:20:100x141VIDEO_ENGINE_TIMEOUT_DETECTEDamdkmdag.sys (+0xfa9c0)
10月15日 03:47:280x141VIDEO_ENGINE_TIMEOUT_DETECTEDamdkmdag.sys (+0xfa9c0)
10月15日 03:56:180x141VIDEO_ENGINE_TIMEOUT_DETECTEDamdkmdag.sys (+0xfa9c0)
10月15日 04:05:370x1A8VIDEO_DXGKRNL_BLACK_SCREEN_LIVEDUMP-

5件のタイムアウトはすべてAMDのGPUドライバ amdkmdag.sys で発生しており、停止位置も同じ +0xfa9c0 だった。9月30日から10月15日にかけて同じ場所でタイムアウトを繰り返している。

音声処理のエラーに加えてAMDドライバのタイムアウトが頻発していたため、まずはグラフィックス関連のドライバ構成を見直すことにした。

常時監視スクリプトCrashMonの導入

過去のダンプ解析と並行して、クラッシュ直前のシステム状態を継続して記録するPowerShellスクリプト「CrashMon」を用意した。
保存先は C:\CrashMon。

システムクラッシュ時の完全メモリダンプを有効にし、ディスク容量不足時でも MEMORY.DMP が自動削除されない設定を入れた。
あわせて System と Application のイベントログサイズを拡張し、電源、ストレージ、GPUなどの関連ログも有効化した。

常時記録用の logger.ps1 は、タスクスケジューラからSYSTEM権限で常駐させた。
システム起動時および5分ごとの生存確認で動かし、スクリプト側でも多重起動を防止している。セットアップ後のタスク状態は Running で正常に開始した。

記録項目内容
生存確認時刻、起動からの経過時間
CPUとメモリCPU使用率、空きメモリ、コミット使用率、非ページプール量
ディスク使用率、待ち行列、I/O待ち時間、読み書き量
電源と温度取得できる温度、AC接続、バッテリー残量
ネットワークゲートウェイと外部IPへのPing応答
プロセスプロセス数、RustDesk等の特定常駐、CPU・メモリ上位プロセス

基本ループは1回あたり15秒間隔で、負荷の高いプロセス一覧取得は4回に1回（約1分間隔）に絞った。
クラッシュ直前のログがバッファに残って失われないよう、ファイルへの書き込みごとに即時フラッシュ（Flush）させている。
USBメモリなどのリムーバブルドライブに CrashMon フォルダーを作っておけば、外付けメディアにも同じログをミラー保存する設定にした。

あわせて、再起動後にイベントログやダンプ、システム情報を一括採取する collect.ps1 も配置し、次回クラッシュ時の詳細ログを回収できるようにした。

チップセットドライバの旧バージョン切り戻し

GPUクラッシュに加えてチップセット側の影響も疑い、システムの復元ポイントを作成したうえで高速スタートアップを無効化した。
続いて、AMDチップセット関連ドライバを過去の安定構成へ切り戻すスクリプトを実行した。
Windowsのドライバ保管場所（DriverStore）に残っている旧パッケージを適用するため、新しいパッケージを削除してからデバイスを再検出させる手順だ。

スクリプトによるパッケージ削除自体はエラーなく完了したが、削除直後に確認した各デバイスのドライババージョンは実行前と変わっていなかった。

デバイス実行前バージョン実行直後バージョン
AMD Micro PEP Device1.0.29.01.0.29.0
AMD I2C Controller1.2.0.1311.2.0.131
AMD GPIO Controller2.2.0.1372.2.0.137
AMD SMBus5.12.0.445.12.0.44
AMD PSP 10.0 Device5.46.0.05.46.0.0

Micro PEPでは稼働中の 1.0.29.0 とは別に保管されていた未使用パッケージ 1.0.47.1 が削除されていた。
また、GPIO ControllerとPSP Deviceではドライバの反映にシステムの再起動が必要と通知されており、この時点ではまだ旧ドライバへの切り替えは完了していなかった。

AMD Adrenalinのアンインストール

チップセットの調整中にも、LiveKernelダンプには amdkmdag.sys によるタイムアウト（0x141）が再度記録された。
AMD純正の汎用ドライバ「Adrenalin」が不安定要因になっている可能性が高いため、メーカーであるASUSの純正ドライバへ戻すことにした。

削除対象は、9月30日に手動導入されていたAdrenalin 26.5.2 だ。
AMD Settingsなどのユーティリティ5件をアンインストールし、グラフィックスドライバ本体、OpenCL、Crash Defenderなどの関連パッケージを一括削除した。

アンインストールはすべて正常終了し、AMD側のGPUはWindows標準の「Microsoft 基本ディスプレイ アダプター」へ切り替わった。この時点のディスプレイアダプター一覧はこんな感じ。

ディスプレイアダプタードライババージョン
NVIDIA GeForce RTX 3050 Ti Laptop GPU32.0.16.1714
Microsoft 基本ディスプレイ アダプター10.0.26100.1

なお、Adrenalinのアンインストール作業中、ブラックスクリーンに関する 0x1A8（VIDEO_DXGKRNL_BLACK_SCREEN_LIVEDUMP）のLiveKernelダンプが記録されていた。
引数の解析によると「モニターは接続されているが表示経路を有効化できなかった」という内容で、AMDドライバの削除に伴って映像出力が一時的にリセットされたときの挙動とみられる。

仮想GPU処理（vmwp.exe）でのSYSTEM_SERVICE_EXCEPTION

Adrenalin削除直後、音声処理とは異なる系統のミニダンプが記録された。
停止コードは SYSTEM_SERVICE_EXCEPTION（0x3B）で、例外コードはメモリアクセス違反を示す 0xC0000005 だった。

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+0x19394f2

クラッシュしたプロセスは、Hyper-VやWSL2などの仮想マシンを動かす vmwp.exe だった。
スタックにはWindowsグラフィックスコア（dxgkrnl.sys）の仮想GPUインターフェースと、NVIDIAドライバ nvlddmkm.sys が記録されていた。AMD側のタイムアウトとは異なり、仮想GPUを通じたNVIDIA側の処理中に起きたアクセス違反を示している。

また、ドライバを入れ直す途中でWindows Updateが勝手に別のドライバを上書き配信しないよう、ExcludeWUDriversInQualityUpdate=1 と SearchOrderConfig=0 を設定して自動更新を止めた。

手元に残っていたダンプの停止位置は、音声処理の 0x1A、AMD側のタイムアウト 0x141、仮想GPU処理中の 0x3B のそれぞれで整理できた。常時監視スクリプトも稼働させた状態で、次はASUS純正ドライバを導入して動作を確かめる。