Windows PCのフリーズ・カクつきを徹底調査｜AMD_WATCHDOGとAMD Crash Defenderが原因？PowerShellで切り分けた記録

ここ1週間ほど、仕事で使っているWindows 11のノートPCの調子がおかしくなりました。

最初は「少しカクつくな」程度だったのですが、徐々に症状が増えていきました。

PCは仕事でかなりハードに使っています。

「さすがに本体が壊れたのでは？」

最初はそう思いました。

しかし、PowerShell、Windowsイベントログ、WinDbg、HPのハードウェア診断などを使って一つずつ原因を潰していったところ、単純なSSD故障やWindows破損では説明できないことが分かってきました。

最終的には、AMDのグラフィックスドライバーだけでなく、「AMD Crash Defender」という普段ほとんど意識しないシステムコンポーネントまで調べることになりました。

今回トラブルが発生したPC

今回問題が起きたのは、HPのノートPCです。

なお、今回の問題を複雑にした事情が一つあります。

以前、不具合のあるDDR4メモリを一時的に装着していました。

そのメモリについてはHPの診断でもエラーが確認され、その後は正常なメモリへ戻しています。

ところが、その前後からCMOS関連と思われるエラーや再起動時の異常なども発生。

そのため当初は、

• 不良メモリが原因なのか
• メモリ交換をきっかけにBIOSや電源管理がおかしくなったのか
• そもそも全く別の問題なのか

という状態から調査を開始しました。

まずはハードウェア故障を疑った

症状だけを見ると、マザーボード、SSD、メモリ、GPUなど、何が壊れていてもおかしくありません。

そこで最初に、HPのUEFIハードウェア診断を実施しました。

少なくとも実施した診断では、大きなハードウェア異常は確認できませんでした。

ファンは「壊れているようで壊れていない」

特に気になったのがファンです。

Windows使用中にファンが回っていないように見えることがあり、さらに過去には「90B」というファン関連の警告も発生していました。

ところが、HPのファンテストを実行すると、ファンは実際に回転してテストを通過します。

つまり、少なくとも

「ファンモーターそのものが完全に壊れている」

とは言い切れません。

ここから、ファンそのものではなく、ファンを制御しているEC（Embedded Controller）や電源管理も疑うことになりました。

PowerShellでWindows内部のログを調べる

ここからPowerShellをかなり使いました。

普段ここまでPowerShellを使うことはありませんが、今回はGUIだけでは確認できない情報が多かったためです。

まず、WindowsイベントログからACPI関連のエラーを抽出しました。

Get-WinEvent -FilterHashtable @{
    LogName='System'
    StartTime=(Get-Date).AddMinutes(-10)
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.ProviderName -eq 'ACPI' -and ($_.Id -in 13,15)
} |
Select TimeCreated,Id,LevelDisplayName,Message |
Format-List

すると、症状がひどいタイミングではACPI 13 / 15が記録されていました。

ACPIとECとは何なのか

かなり簡単に説明すると、ACPIはWindowsとPC内部の電源管理をつなぐ仕組みです。

スリープ、バッテリー、電源状態、温度管理などにも関係します。

さらにノートPCには、こうした処理を低レベルで管理するEC（Embedded Controller）があります。

今回のPCでは、

• バッテリー関連の挙動がおかしい
• 意図しないスリープ・復帰異常
• ACPI 13 / 15
• ファン90B
• 画面が正常に復帰しない

といった症状が重なっていました。

内蔵バッテリーを完全に外して検証

そこで、内蔵バッテリーを物理的に取り外し、ACアダプターだけでPCを動かすテストを行いました。

バッテリーを外した状態では、当然ACアダプターを抜けばその瞬間にPCの電源も落ちます。

この状態でしばらく使用したところ、かなり興味深い変化がありました。

ただし、後述するAMD_WATCHDOGはバッテリーを外した状態でも再発しました。

そのため、「バッテリーだけが全ての原因」という結論にはなりませんでした。

AMD_WATCHDOGという大量のダンプファイルを発見

さらに調査していくと、かなり気になるものが見つかりました。

Get-ChildItem C:\Windows\LiveKernelReports\AMD_WATCHDOG |
Sort-Object LastWriteTime -Descending |
Select-Object -First 5 Name,LastWriteTime

すると、次のようなダンプファイルが大量に作られていました。

AMD_WATCHDOG-20260917-1400.dmp
AMD_WATCHDOG-20260917-1358.dmp
AMD_WATCHDOG-20260917-1356.dmp
AMD_WATCHDOG-20260917-1123.dmp
AMD_WATCHDOG-20260917-1122.dmp

しかも、カクつきを感じた時間とかなり一致します。

9月17日には、

と、短時間に連発しました。

ここで、単なる「PCが重い」という話ではないことが分かりました。

WinDbgでAMD_WATCHDOGの中身を解析

そこでMicrosoftのWinDbgを使い、実際のAMD_WATCHDOGダンプを開いてみました。

基本的に実行したのは次の3つです。

.symfix
.reload
!analyze -v

すると、何度解析しても同じものが出てきました。

BUGCHECK_CODE:  a1000001

MODULE_NAME: amdfendr

IMAGE_NAME: amdfendr.sys

SYMBOL_NAME: amdfendr+4b428

FAILURE_BUCKET_ID:
LKD_0xA1000001_amdfendr!unknown_function

さらに複数回のダンプでFailure Hashまで一致。

{cb7e6729-7af8-a999-da57-477d44c3b788}

amdfendr.sys＝AMD Crash Defenderだった

調べていくと、amdfendr.sysはAMDのCrash Defenderに関係するドライバーでした。

名前の通り、GPU周辺で異常が発生した際の検知や復旧に関係するコンポーネントです。

つまり今回、異常発生時のダンプでは、

AMD Crash Defender自身が繰り返し中心に出ていました。

ここからAMD関連ドライバーを本格的に調べることになります。

まずAMD RadeonのDisplayドライバーを削除

当初入っていたRadeonドライバーは、

31.0.21925.1001

でした。

まずこれを削除。

一時的にデバイスマネージャー上では、

Microsoft 基本ディスプレイ アダプター

だけで動かす状態にしました。

PowerShellでも確認します。

Get-PnpDevice -Class Display

しかし、ここで予想外の結果になりました。

AMDのDisplayドライバー本体を削除しても、AMD_WATCHDOGが完全には止まらなかったのです。

当初は「それならAMD Displayは原因ではないのでは？」とも考えました。

しかし、後になってこの判断が早かったことが分かります。

Windows UpdateをPowerShellから直接検索

HPのサポートページでは目的のグラフィックスドライバーを簡単に見つけられなかったため、Windows UpdateがこのPCに提示しているドライバーをPowerShellから直接検索しました。

$session=New-Object -ComObject Microsoft.Update.Session
$searcher=$session.CreateUpdateSearcher()
$r=$searcher.Search("IsInstalled=0 and Type='Driver'")
$r.Updates | ForEach-Object {$_.Title}

すると、

Advanced Micro Devices, Inc. - Display - 31.0.12044.3

が見つかりました。

そこで問題が起きていた2026年系ではなく、31.0.12044.3（2022年10月25日）へロールバックしました。

導入後はPowerShellで確認。

Get-CimInstance Win32_VideoController |
Select Name,DriverVersion,Status

結果は、

AMD Radeon (TM) Graphics
31.0.12044.3
OK

正常です。

ところが、古いDisplayドライバーでもWATCHDOGが再発

これで解決したかと思いました。

しかし、Displayドライバーを2022年版に戻した後も、

• 13:56
• 13:58
• 14:00

とAMD_WATCHDOGが発生。

14:00のダンプをWinDbgで再び解析すると、また同じ

amdfendr.sys

が出てきました。

しかもFailure Hashまで、これまでのAMD_WATCHDOGと同じです。

Failure.Hash
{cb7e6729-7af8-a999-da57-477d44c3b788}

Displayドライバー以外のAMDコンポーネントを調べる

ここで、「AMDのグラフィックスドライバー＝Displayドライバーだけ」と考えるのをやめました。

PowerShellからDriver Storeや現在動作しているドライバーを直接調べます。

driverquery /v | findstr /i amdfendr

pnputil /enum-drivers |
Select-String "amdfendr" -Context 3,7

すると、かなり重要なことが分かりました。

PCのDriver Storeに、AMD Crash Defenderが2世代存在していたのです。

2026年版

公開名: oem32.inf
元の名前: amdfendr.inf
プロバイダー: AMD
バージョン: 23.19.0.6
日付: 2026/03/18

2022年版

公開名: oem19.inf
元の名前: amdfendr.inf
プロバイダー: AMD
バージョン: 22.20.0.2
日付: 2022/05/12

つまり、同じamdfendr.infについて、新旧2種類のドライバーパッケージがDriver Storeに存在していました。

では、実際に使われているCrash Defenderはどちらなのか

Driver Storeに存在しているだけでは、どちらが実際に使用されているのか分かりません。

そこで、現在デバイスに割り当てられている署名済みドライバーをPowerShellで確認しました。

Get-CimInstance Win32_PnPSignedDriver |
Where-Object {$_.InfName -in 'oem32.inf','oem19.inf'} |
Select DeviceName,DriverVersion,DriverDate,InfName,DeviceID |
Format-List

結果は、

DeviceName    : AMD Crash Defender
DriverVersion : 23.19.0.6
InfName       : oem32.inf
DeviceID      : ROOT\AMDLOG\0000

でした。

つまり、AMD関連ドライバーの世代が混在していたことになります。

これなら、Displayドライバーを古いものへ戻してもamdfendr.sysによるAMD_WATCHDOGが止まらなかったことにも説明がつきます。

問題が出ているAMD Crash Defender 23.19.0.6を削除

そこで、2026年版のAMD Crash DefenderだけをDriver Storeから削除することにしました。

実行したコマンドはこちらです。

pnputil /delete-driver oem32.inf /uninstall

結果は、

ドライバー パッケージがアンインストールされました。
ドライバー パッケージが正常に削除されました。

となり、削除に成功しました。

続いてDriver Storeを再確認します。

pnputil /enum-drivers |
Select-String "amdfendr.inf" -Context 3,7

すると、2026年版のoem32.infは消え、2022年版だけが残りました。

公開名: oem19.inf
元の名前: amdfendr.inf
プロバイダー: AMD
ドライバー バージョン: 05/12/2022 22.20.0.2

再起動後、AMD Crash Defenderが2022年版へ切り替わった

ここでPCを再起動しました。

再起動後、実際にどのCrash Defenderが使われているかを確認します。

Get-CimInstance Win32_PnPSignedDriver |
Where-Object {$_.DeviceName -match 'AMD Crash Defender'} |
Select DeviceName,DriverVersion,InfName

結果は、

DeviceName         DriverVersion InfName
----------         ------------- -------
AMD Crash Defender 22.20.0.2     oem19.inf

2022年版へのロールバックに成功しました。

AMD Crash Defender 23.19.0.6はいつ入ったのか

ここまで調べると、もう一つ気になることが出てきます。

「そもそも23.19.0.6は、いつこのPCに入ったのか？」

ここでもPowerShellを使いました。

Windowsには、デバイスやドライバーのインストール履歴が保存されているsetupapi.dev.logがあります。

そこで、amdfendr.infとAMD Crash DefenderのDevice IDでログを検索しました。

Select-String "C:\Windows\INF\setupapi.dev.log" `
-Pattern "amdfendr.inf|ROOT\\AMDLOG" `
-Context 8,15 |
Select-Object -Last 120

すると、導入日時まで追跡できました。

Section start 2026/09/16 17:05:39
Driver INF     - oem32.inf
Driver Version - 03/18/2026,23.19.0.6
Configuration  - ROOT\AMDLOG

AMD Crash Defender 23.19.0.6がこのPCへ設定されたのは、2026年9月16日17時05分ごろでした。

さらにログを追うと、amdfendr.sysやamdfendrmgr.sysの設定、AMD Crash Defenderサービスの作成・起動まで確認できました。

「ここ1週間の不具合＝Crash Defender」ではなかった

ここは今回の調査で重要な点です。

PCの不具合自体は、AMD Crash Defender 23.19.0.6が導入されるより前から発生していました。

そのため、

「ここ1週間に発生したすべての不具合の原因がCrash Defender 23.19.0.6だった」

とは言えません。

一方で、9月17日に短時間で連発したAMD_WATCHDOGについては、WinDbgで何度解析してもamdfendr.sysが出ていました。

そして23.19.0.6を削除して22.20.0.2へ戻した後、AMD_WATCHDOGの生成状況を確認すると、最後の記録は、

AMD_WATCHDOG-20260917-1400.dmp
2026/09/17 14:00:45

のまま。

ロールバック後は、新しいAMD_WATCHDOGが作られていません。

ロールバック後にあえて高負荷処理を実行

その後は、単にPCを放置したわけではありません。

普段仕事で使用しているPythonの重い処理を動かしながら、ChromeやGoogle Driveなども通常通り使用しました。

実行中だったPython処理は、3時間のheavyプロファイルかつ並列処理を使用するものです。

python -X utf8 app.py run-pipeline --profile heavy --hours 3 ... --parallel-stages

この状態で多少の軽いカクつきを感じたため、再びPowerShellでCPU、メモリ、SSD、DPC、Interruptなどを確認しました。

しかし、この時点では午前中とは状況が大きく違いました。

CPUについては、一部の論理CPUが瞬間的に80％台まで上がる場面はありましたが、CPU全体では余裕があり、Processor Queue Lengthも0でした。

つまり、この時点で感じた軽いカクつきは、少なくとも午前中に発生していた「AMD_WATCHDOGを伴う異常なカクつき」とは性質が違う可能性が高いと判断しました。

WindowsそのものやSSDも一通り確認した

AMDだけを疑ったわけではありません。

調査中には、WindowsやSSD側の問題もできる限り切り分けました。

CHKDSK

chkdsk C: /scan

結果は、

Windows でファイル システムのスキャンが終了しました。
問題は見つかりませんでした。
これ以上の操作は必要ありません。

0 KB : 不良セクター

ファイルシステムの問題や不良セクターは確認されませんでした。

SSDのReTrim

Optimize-Volume -DriveLetter C -ReTrim -Verbose

SSDについてもTRIMを再実行しました。

Windowsコンポーネントのクリーンアップ

DISM /Online /Cleanup-Image /StartComponentCleanup

こちらも最終的に、

100.0%
操作は正常に完了しました。

となりました。

SFCやDISMによるWindowsイメージの確認でも、大きな破損は確認されませんでした。

不要な常駐ソフトやサービスも整理

今回の調査を機に、バックグラウンドで動いている不要なサービスや残骸もかなり整理しました。

PowerShellからインストール済みソフト、スタートアップ、Microsoft以外のサービス、タスクスケジューラなどを一覧化。

その中から、使用していないものや残骸になっていたものを個別に確認しました。

• McAfee WebAdvisorの残存サービス
• Googleの旧Updateサービス
• HP Connection Optimizer
• Logi Download Assistantのスタートアップ残骸
• Adobeの一部バックグラウンドタスク
• 不要なスタートアップ
• 使用していないWSL関連サービス

特にMcAfee WebAdvisorはアンインストール一覧に存在しないにもかかわらずサービスだけが残っていたため、確認後に削除しました。

sc.exe delete "McAfee WebAdvisor"

ChromeのGPUキャッシュやDirect3Dキャッシュ、一時ファイルなども整理しています。

高速スタートアップもOFFにした

ドライバーや電源管理の問題を調査しているため、Windowsの高速スタートアップもOFFにしました。

現在の設定はPowerShellから確認できます。

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled

結果は、

HiberbootEnabled    REG_DWORD    0x0

0x0なので高速スタートアップは無効です。

これにより、シャットダウン後の次回起動時に以前のカーネル状態を引き継ぐ要素を減らしています。

もう一つ残った問題が「バッテリー・EC・電源管理」

ここまでAMD_WATCHDOGを中心に書いてきましたが、今回のトラブルはAMDだけでは説明できません。

別系統として残ったのが、バッテリー、EC（Embedded Controller）、ACPI、ファン制御などの電源管理系です。

実際、症状がひどかった時期にはWindowsのSystemログでACPI 13 / 15が記録されていました。

さらに、バッテリー残量や電源状態に関連する不自然な挙動、スリープ・復帰の異常なども発生していました。

System Fan（90B）が出るのに、ファンテストは合格

今回かなり不可解だったのがファンです。

起動時にはHPのSystem Fan（90B）が表示されることがありました。

普通に考えれば「ファンが壊れた」と判断したくなるところです。

ところがHP PC Hardware Diagnostics UEFIからファン速度テストを実行すると、結果は合格。

さらにファン温度テストについても合格しました。

テスト実行中には、実際にファンが回転していることも確認できました。

一方、Windowsを通常使用しているときには、目視ではファンが回っていないように見える場面もありました。

このため、ファンそのものだけでなく、温度に応じてファンを動かすEC側の制御、温度検出、電源管理なども含めて切り分ける必要があると考えています。

HPのシステムボードテストは合格

「マザーボード自体が壊れているのでは？」という可能性も考え、HPのシステムボードテストも実施しました。

結果は、

• PCI読み取りデバイス：合格
• メモリ：合格
• オンボードビデオ：合格
• オーディオ：合格
• USB：合格

となりました。

プロセッサテストや無線モジュールテストなど、ほかのコンポーネントテストについても実施した範囲では合格しています。

したがって、少なくともHPの診断ツールで即座に検出できるような明確なシステムボード故障は確認できませんでした。

BIOS RecoveryやCMOS Resetまで発生した

今回の調査中には、Windowsよりさらに下のレイヤーでも不穏な現象がありました。

HP BIOS Recoveryが起動し、BIOSイメージの書き戻しが行われたことがあります。

さらに別のタイミングでは、

CMOS Reset (502)

The CMOS checksum is invalid.
The CMOS will reset to the default configuration.

という画面も表示されました。

つまり今回のPCでは、Windows上のAMDドライバー問題だけでなく、BIOS / CMOS / EC / 電源管理側についても疑うだけの材料がありました。

ただし、BIOS RecoveryやCMOS Resetが発生したことだけをもって、マザーボード故障と断定することもできません。

そのため今回の調査では、一つのエラーだけを見て原因を決めつけず、症状ごとに切り分けることを意識しました。

バッテリーを物理的に外してACアダプターだけで動かした

ACPIやEC関連の異常を切り分けるため、最終的にはノートPCの内蔵バッテリーを物理的に取り外しました。

つまり、現在はACアダプターだけでPCを動かしている状態です。

HPの電源テストでも、バッテリーを正常にテストできない状態が確認されていました。

バッテリーを外した状態では、ACアダプターを抜けば当然その瞬間に電源が落ちます。

この状態で通常使用を続けたところ、少なくとも確認している範囲では、以前頻発していたACPI 13 / 15が出なくなりました。

さらに、スリープ・画面OFF状態からの復帰も一度正常に行えました。

バッテリーを外してもAMD_WATCHDOGは一時発生していたため、「バッテリーだけがすべての原因」という説明は成立しません。

逆に、AMD Crash Defenderをロールバックしたからといって、バッテリー・EC問題まで解決したと判断することもできません。

今回一番重要だったのは「原因を一つに決めつけない」こと

今回のトラブルでは、途中で何度も「これが原因だ」と思えるものが出てきました。

例えば、

• 不良メモリ
• System Fan（90B）
• CMOS Reset（502）
• BIOS Recovery
• ACPI 13 / 15
• バッテリー
• AMD Radeon Displayドライバー
• AMD Crash Defender
• amdfendr.sys
• Windows Update

です。

しかし、一つずつ検証すると「それだけでは全症状を説明できない」ということが何度もありました。

特に象徴的だったのがAMDです。

最初はDisplayドライバーを疑って2022年版へ戻しました。

それでもAMD_WATCHDOGが発生。

さらに調べると、Displayとは別にAMD Crash Defenderというコンポーネントがあり、そこだけ2026年版のまま残っていました。

そしてWinDbgのダンプ解析では、そのCrash Defenderのamdfendr.sysが繰り返し同じFailure Bucketに出ていました。

GUI上で「AMD Radeonのドライバーを戻した」だけでは、AMD関連コンポーネントを完全に戻したことにはなっていなかったわけです。

現時点のPCの状態

記事執筆時点では、PCを次の状態で使用しています。

ロールバック後も「軽いカクつき」は一度感じた

ここも正直に書いておきます。

AMD Crash Defenderを2022年版へ戻した後、PCが完全にヌルヌルになり、一切のカクつきが消えたわけではありません。

16時ごろに、文字入力や操作でわずかな引っかかりを感じる場面がありました。

ただし、そのときは仕事用のPythonパイプラインを--profile heavyかつ--parallel-stagesで実行中でした。

そこで、カクついている最中にPowerShellでCPU、DPC、Interrupt、メモリ、SSDなどを測定しました。

結果として、CPU全体が飽和しているわけではありませんでしたが、一部の論理CPUが瞬間的に80％台まで上昇する場面は確認できました。

一方で、

• Processor Queue Length：0
• メモリ不足：なし
• SSDの大きな待ち：なし
• DPCの異常な上昇：なし
• Interruptの異常な上昇：なし
• Systemログの新規重大エラー：なし
• AMD_WATCHDOG：新規生成なし

という状態でした。

このため、現時点では「ロールバック後に感じた軽いカクつき」と「以前のAMD_WATCHDOGを伴う異常なカクつき」は、同じものとは限らないと考えています。

現時点で分かったこと

まだ「完全に直った」とは断定しない

ここまで読むと、「AMD Crash Defender 23.19.0.6が原因だった」と結論付けたくなるかもしれません。

しかし、現時点ではそこまで断定していません。

理由は単純で、今回のPCではCrash Defenderが導入される前から別の不調が発生していたからです。

また、バッテリーやACPI、EC、System Fan（90B）、CMOS Resetなど、AMD Crash Defenderだけでは説明できない現象もありました。

今後さらに長時間使用し、スリープ・復帰や高負荷処理などを繰り返してもAMD_WATCHDOGが増えないかを確認する必要があります。