Windows 11のBAD_POOL_CALLERとtpm.sysエラー原因と対処まとめ｜TPM 2.0ブルースクリーンの切り分け手順

「PCが突然ブルースクリーン（BAD_POOL_CALLER）で落ち、ミニダンプを見ると tpm.sys と出ている。これってTPMが壊れている？放置していい？」——この記事では、そんな不安をできるだけ具体的に、しかし過度に心配しすぎないラインで解消していきます。

ケースの概要と前提整理

まず、今回想定している状況を整理します。

• OS：Windows 11
• 症状：初めてのブルースクリーン（BSOD）
• バグチェック：BugCheck 0xC2（BAD_POOL_CALLER）
• スタックトレース：tpm.sys（TPM 2.0 の Windows 標準ドライバー） が関与
• 発生回数：1回のみ（その後は再発なし）
• ミニダンプ：C:\Windows\Minidump に該当する .dmp が1つだけ保存されている

この状況でよくある疑問は、次の3つです。

• BAD_POOL_CALLER とは一体何が起きたエラーなのか？
• tpm.sys と出ている以上、TPM やセキュリティ機能が壊れているのか？
• 1回だけなら放置してよいのか、それとも何かしておくべきか？

結論から言うと、

• BAD_POOL_CALLER は「メモリプールの扱い方をミスった」系の汎用エラーで、直接の原因はドライバーやメモリ破損など色々あり得ること
• tpm.sys はあくまで「TPMドライバーが動いている最中に破損が顕在化した」だけで、犯人とは限らないこと
• 一度きり＋その後まったく再発しないなら、深追いせず「様子見＋最低限のメンテ」で十分なケースが多いこと

を押さえておけばOKです。そのうえで「今やっておくと安心な対処」と「再発したときの切り分け手順」を詳しく解説していきます。

BAD_POOL_CALLER（BugCheck 0xC2）とは何か

BAD_POOL_CALLER は、Windows カーネル内部の「プール」と呼ばれるメモリ領域の扱いに問題があったときに出るバグチェックです。Microsoft のドキュメントでは、次のようなケースが例に挙げられています。

• 解放済みのメモリをもう一度解放しようとした（ダブルフリー）
• そもそもプールではないアドレスを解放しようとした
• 割り込みレベル（IRQL）が不正な状態でプール操作を行った
• プールヘッダーが何らかの理由で破損していた

つまり、「あるドライバー（≒カーネルモードのコード）がメモリの扱いをヘタにやらかした結果、カーネルが『これ以上動かすのは危険』と判断して止まった状態」と考えるとイメージしやすいです。

重要なのは、

• 表示されるドライバー（今回の tpm.sys）が必ずしも「真犯人」とは限らない
• 実際には、もっと前に別のドライバーやハードウェア不良がプールを破壊していて、たまたま tpm.sys がアクセスしたタイミングで検出された可能性がある

という点です。これは後ほど「tpm.sys は犯人か被害者か？」のところで詳しく見ていきます。

tpm.sys は犯人か被害者か？ TPM 2.0ドライバーの役割

tpm.sys は、Windows に標準で入っている TPM 2.0 用のシステムドライバー です。TPM（Trusted Platform Module）は、Windows 11 の必須要件にもなっているセキュリティ関連ハードウェア／ファームウェアで、主に以下の用途に使われます。

• BitLocker や デバイス暗号化 の鍵管理
• Windows Hello（顔認証／指紋認証）の信頼の根
• 仮想化ベースのセキュリティ（VBS）、Credential Guard などのセキュリティ機能

ここで押さえておきたいポイント：

• tpm.sys 自体は Microsoft が提供する標準ドライバー である
• 海外フォーラムの解析例でも、BAD_POOL_CALLER が tpm.sys で止まっているケースで、実際の原因は RAM のオーバークロックやメモリ不良と判断されたケースが報告されています
• TPMファームウェアや BIOS アップデートで改善した事例もあり、「TPM周辺環境（BIOS・チップセット・ドライバー）の更新」は有効な対策になりうる

そのため、

「tpm.sys がスタックに出ている ＝ TPM が物理的に壊れている」ではない と考えるのが現実的です。あくまで「TPM関連の処理が走っているときに、どこかで壊れたメモリを触ってしまった」くらいに捉え、広めの視野で原因を探すのがポイントになります。

一度きり・再発なしの場合の考え方

今回のように、

• BSOD は 1回だけ
• その後、しばらく使っても再発なし
• 特定の操作で必ず落ちるわけでもない

という場合、現場の運用経験的には次のような扱いになることが多いです。

• 一過性の要因でメモリが一瞬だけ破壊され、それが二度と起きないことも普通にある
• 電源品質・ノイズ・一瞬だけ不安定だったドライバー／ファームウェアのタイミングなど、「完璧な再現が不可能」な要因も多い
• 再発しない限り、ミニダンプ1つから完璧な原因特定をするのはかなり難しい

よって、

• 「OS・ドライバー・BIOS／UEFI を最新化する」
• 「BitLocker などの回復キーをバックアップし、次に何かあっても復旧できる状態にしておく」

という「守りの対策」さえしておけば、即座にマザーボード交換やOS再インストールが必要というレベルではないと判断してよいケースがほとんどです。

今すぐやっておきたい基本対処

「とりあえず様子見」とはいえ、次のような基本的なメンテナンスは実施しておくと安心です。

項目	やること	ポイント
Windows Update	品質更新プログラム・オプション更新を含めて最新まで適用	TPM やセキュリティ周りの修正が含まれることも多い
チップセットドライバー	PC／マザーボードメーカーのサポートページから最新版をインストール	AMD/Intel のCPUとTPMの連携に関わる重要ドライバー
LAN/Wi‑Fiドライバー	Intel/Realtekなどベンダー提供版やメーカー提供版を更新	BAD_POOL_CALLER が LAN/Wi‑Fi ドライバーで起きるケースも報告あり
BIOS/UEFI	メーカーサイトの手順に従ってアップデート	TPMファームウェア更新を含むBIOSアップデートで改善したケースあり

ここまで実施しておけば、「既知の不具合で落ちる」リスクはかなり下げられます。

TPM 周りの健全性チェック

次に、TPMまわりが正常に認識・動作しているかを確認します。これは、BSOD対策というより「今後BitLocker等で詰まらないためのお守り」的な意味合いも強いです。

tpm.msc で状態を確認する

1. Win + R を押し、「ファイル名を指定して実行」を開く。
2. tpm.msc と入力して Enter。
3. 「TPM管理コンソール」が開くので、上部のステータスを確認する。
   • 「このTPMは使用可能です」やそれに類するメッセージであれば基本OK。
   • エラーや「利用できません」といった表示の場合は、BIOSでTPMが無効化されていないか、別途確認が必要です。

PowerShell の Get‑TPM で詳細を確認

1. スタートボタンを右クリック → 「Windows PowerShell（管理者）」または「ターミナル（管理者）」を開く。
2. 次のコマンドを実行：

Get-TPM

主にチェックしたいのは次の項目です。

• TpmPresent：True になっているか
• TpmReady：True になっているか

どちらも True であれば、Windows から見て TPM は正常に利用可能な状態と判断されています。

デバイスマネージャーで TPM ドライバーを再適用する

ドライバー側の軽いリフレッシュとして、TPM デバイスを一度アンインストールして再起動する方法があります。

1. Win + X → 「デバイス マネージャー」を開く。
2. 「セキュリティ デバイス」を展開し、Trusted Platform Module 2.0 を右クリック。
3. 「デバイスのアンインストール」を選択し、確認ダイアログで実行。
4. PC を再起動すると、Windows 標準ドライバー（tpm.sysを含む）が自動的に再インストールされる。

これにより、TPMデバイスの設定やドライバーが軽く再初期化されます。

TPMのクリアは「最後の手段」

TPMのクリア（初期化）は、基本的に最後の手段です。実行すると、TPM内部に格納されている鍵や情報が消去されます。

• BitLocker を利用している場合、回復キーの入力が必要になる可能性が高い
• 企業環境では、ドメインポリシーやセキュリティポリシーの影響もあるため、勝手にクリアしないこと

どうしても必要になった場合は：

1. BitLocker回復キーをすべて安全な場所にバックアップ
2. 必要なら会社のIT部門・管理者に事前相談
3. tpm.msc から「TPMのクリア」を実行

という順序で行いましょう。

システムファイルと整合性のチェック

メモリプール破損の裏には、システムファイルの破損が潜んでいる可能性もあります。以下2つのコマンドは、Windows標準の修復手段として定番です。

1. 「コマンド プロンプト（管理者）」または「ターミナル（管理者）」を開く。
2. 次の順番でコマンドを実行：

sfc /scannow

DISM /Online /Cleanup-Image /RestoreHealth

• sfc /scannow：システムファイルの整合性チェックと自動修復
• DISM ... /RestoreHealth：コンポーネントストアの修復を行い、SFCの修復元となるイメージを整える

BAD_POOL_CALLER に限らず、OSレベルの不整合を一度リセットしておく意味でも、実行して損はありません。

メモリ／ストレージなどハードウェア側のチェック

フォーラムの解析例では、BAD_POOL_CALLER と tpm.sys が絡むケースで、最終的に「メモリのオーバークロック」や「物理的なRAM不良」が疑われた例もあります。

メモリ診断（RAM）のチェック

まずは標準の「Windows メモリ診断」から試すと良いでしょう。

1. Win キーを押して「メモリ診断」と入力し、「Windows メモリ診断」を起動。
2. 「今すぐ再起動して問題の有無を確認する（推奨）」を選択。
3. 再起動後、テストが自動的に実行され、完了後に結果が表示される。

より本格的にチェックしたい場合は、memtest86 などのツールをUSBメモリから起動し、数周分回してみるのも有効です。

また、BIOSで

• XMP/DOCP プロファイルで高クロックにしている
• 電圧やタイミングを手動で詰めている

といった場合は、一度すべて「標準（Auto / JEDEC準拠）」に戻して様子を見ることを強くおすすめします。前述のフォーラムでも、メモリクロックを下げることで BAD_POOL_CALLER + tpm.sys の頻度が下がった例が報告されています。

ストレージ（SSD/HDD）の健全性チェック

• 各メーカー（Samsung / Western Digital / Crucial など）が提供する診断ツールで SMART 情報とファームウェア状態を確認
• 「代替処理済みセクタ」や「不良ブロック」が増えていないかをチェック
• ファームウェアアップデートがあれば適用

ストレージ不良が直接 BAD_POOL_CALLER を起こすわけではありませんが、ドライバーやページファイルの読み書きが不安定になると、結果的にメモリプール破損の引き金になることがあります。

イベントログ・信頼性モニターで「直前に何があったか」を見る

ミニダンプ1つだけでは情報が足りないとき、「直前にどんなイベントが起きていたか」を見るのは非常に有効です。

信頼性モニターの活用

1. Win キーを押し、「信頼性」と入力 → 「信頼性モニターの表示」を開く。
2. グラフから BSOD が発生した日付を探す。
3. その日の「重大なイベント」「警告」をクリックし、以下のようなエントリがないか確認。
   • 「ハードウェアエラー」
   • 「Windows が正しくシャットダウンしませんでした」
   • 特定のドライバーやアプリに関連するエラー

イベント ビューアーで詳細を確認

1. Win + X → 「イベント ビューアー」を開く。
2. 「Windows ログ」 → 「システム」を開き、BSOD 直前〜直後の時間帯を確認。

特にチェックしたいイベント：

• Kernel-Power 41：予期せぬシャットダウン／再起動があったことを示す
• BugCheck 1001：どのバグチェックコードで落ちたか（0xC2 なら BAD_POOL_CALLER）
• TPM関連、ACPI関連、Kernel-PnP関連の警告／エラー

これらのログと「どの作業中に落ちたか（ゲーム中／スリープ復帰直後／ブラウザ操作中など）」をセットでメモしておくと、再発時に原因を絞り込みやすくなります。

仮想化・セキュリティ機能・アンチチートソフトとの関係

TPM は Windows 11 のセキュリティ機能と密接に結びついており、

• 仮想化ベースのセキュリティ（VBS）
• Hyper-V / WSL2
• 一部のゲーム用アンチチートソフト

といった機能が TPM を利用・連携するケースがあります。

海外のユーザー報告では、TPM を利用するアンチチートソフト（例：一部オンラインゲームのドライバー）をインストールしてから BAD_POOL_CALLER が出始めたという事例もあり、BIOSアップデートやチップセットドライバー更新、RAMクロック調整などと合わせて対処が行われています。

ポイントとしては：

• アンチチートやセキュリティソフトが古いバージョンだと、TPMやメモリ保護機能と相性問題を起こす場合がある
• どうしても疑わしい場合は、一旦アンインストール → 再起動 → 最新版を入れ直すことで改善する可能性がある
• 仮想化ベースのセキュリティやメモリ整合性（Core Isolation）を、一時的に無効化して再発有無を確認するのも切り分けとして有効（ただし恒久的な無効化は非推奨）

セキュリティレベルを落とす設定変更は、あくまで「一時的な切り分け」のために行い、原因が判明したら戻すようにしましょう。

次回発生時に備えておくと楽になる設定

BAD_POOL_CALLER が再発したとき、より精密な解析ができるように「証拠集めの準備」をしておくのも、エンジニア視点では重要です。

起動と回復の設定（ダンプ種別の見直し）

1. Win + R → sysdm.cpl と入力して Enter。
2. 「詳細設定」タブ → 「起動と回復」の「設定」をクリック。
3. 「デバッグ情報の書き込み」を以下のいずれかに設定。
   • 自動メモリダンプ（推奨）
   • もしくは カーネルメモリダンプ
4. 「ダンプファイル」のパスは既定（%SystemRoot%\MEMORY.DMP / Minidump）のままでOK。

同時に、ページファイルが「すべてのドライブで自動管理」になっていることも確認しておきましょう。ページファイルを手動で極端に小さくしていると、メモリダンプが正しく保存されないことがあります。

ミニダンプ保存先の確認

標準では、ミニダンプは C:\Windows\Minidump に保存されます。次回 BSOD が発生したら：

1. Minidump フォルダー内の .dmp ファイルを全て選択。
2. 右クリック → 送る → 圧縮（zip形式）フォルダー。
3. できた ZIP を OneDrive / Google Drive などに置き、フォーラムやサポートにリンクを共有。

複数回 BSOD が出ている場合、複数のミニダンプをまとめて解析すると「共通して名前が出てくるドライバー」などのパターンが見えやすくなります。

再発したときの実務的な切り分けフロー

再発してしまった場合に、やみくもに設定をいじらず冷静に進めるための「おすすめフロー」を示します。

ステップ	やること	目的
1	発生時刻・実行していた操作をメモ	再現条件や共通点を後で洗い出すため
2	信頼性モニター／イベントログを確認	直前の警告・エラーを把握
3	Minidump を ZIP 化して退避	後から消されないよう証拠保全
4	ドライバーとBIOSの更新状況を再確認	古いバージョンが残っていないか確認
5	メモリクロックを標準に戻す／メモリ診断	ハードウェア起因かどうかの大きな切り分け
6	疑わしいソフト（アンチチート等）を一時的に外す	サードパーティソフトの影響を評価

これらを順に行えば、「ハードウェアっぽいか」「ドライバー／ソフトっぽいか」をかなり高い精度で切り分けることができます。

今回のケース（1回だけの BAD_POOL_CALLER + tpm.sys）ならどうするか

ここまでの内容を踏まえて、「1回だけ発生して再発していない BAD_POOL_CALLER（tpm.sys）」というケースを現実的にどう扱うかをまとめます。

今すぐやっておきたいこと

• Windows Update を最新まで適用
• マザーボード／PCメーカーのサイトから
  • チップセットドライバー
  • LAN/Wi‑Fi ドライバー
  • BIOS/UEFI（TPM関連の更新が含まれていないかリリースノートをチェック）
  をインストール
• BitLockerを利用している場合は、回復キーをUSBメモリや紙などで安全に保管
• sfc /scannow と DISM /Online /Cleanup-Image /RestoreHealth を実行
• tpm.msc と Get-TPM で TPM 状態を確認
• 起動と回復の設定を見直し、ミニダンプが確実に保存されるようにする

様子見でよい目安

上記を実施したうえで、

• 1ヶ月〜数ヶ月程度、普段通りに利用しても BSOD が一切出ない
• 特定の操作（ゲーム、スリープ復帰、高負荷処理など）での再現性もない

のであれば、「一過性のトラブル」と割り切って運用するのが現実的です。

もちろん、仕事でミッションクリティカルに使っているPCであれば、よりシビアに判断する必要はありますが、一般家庭のPCや個人利用であれば、「しっかりアップデートとバックアップはしたし、次に落ちたらログを集めて本格調査しよう」くらいのスタンスで問題ないことが多いです。

軽く知っておくと役に立つ：ミニダンプ解析のさわり

エンジニア寄りの話になりますが、ミニダンプを解析するときの最初の着眼点だけ簡単に紹介しておきます。

• BugCheck コードとパラメータ
  • BugCheck 0xC2 → BAD_POOL_CALLER
  • 第1パラメータで「ダブルフリー」「不正アドレス」「ヘッダー破損」など大まかな種別がわかる
• スタックトレース
  • どのドライバーのどの関数でクラッシュに至ったかを確認
  • tpm.sys が出ていても、そのさらに上位に別ドライバーがいないかを見る
• Loaded Modules（読み込まれているドライバー一覧）
  • サードパーティ製ドライバーのバージョン・日付を確認
  • 明らかに古いものや怪しい名前のものがないかをチェック

とはいえ、ここまでやるのはかなり「趣味の領域」でもあるので、実務上は「再発したら ZIP にして専門家や詳しい人に投げる」くらいで十分です。

チェックリスト（今回やっておくと安心な項目まとめ）

項目	状態	メモ
Windows／ドライバー／BIOSを最新化した	□ / ■	メーカーサイトを一度必ず確認
BitLocker回復キーをバックアップした	□ / ■	Microsoftアカウント／USB／紙などに保存
sfc／DISM を実行した	□ / ■	管理者権限で実行
tpm.msc／Get‑TPM で TPM 状態を確認した	□ / ■	TpmPresent, TpmReady が True か
メモリ診断（Windowsメモリ診断など）を実施した	□ / ■	オーバークロック中なら一度標準に戻す
信頼性モニターで関連エラーを確認した	□ / ■	BSOD 発生日のイベントをメモ
起動と回復の設定でミニダンプを確実に保存できるようにした	□ / ■	自動メモリダンプ／ページファイル自動管理

まとめ：tpm.sys が出ても慌てず「更新＋備え」でOK

• BAD_POOL_CALLER（0xC2）は「メモリプールの扱いミス」系の汎用エラーで、tpm.sys に限らず多くの要因が関わりうる。
• tpm.sys は TPM 2.0 用の標準ドライバーであり、「スタックに出た＝物理的TPM故障」とは限らない。
• 海外フォーラムの解析でも、RAMオーバークロック／メモリ不良／ドライバーの不具合／BIOS・TPMファームウェアの更新不足などが原因候補として挙げられている。
• 今回のように「1回だけ発生して再発がない」ケースでは、
  • Windows Update とドライバー・BIOS を最新化
  • BitLocker 回復キーのバックアップ
  • TPM・システム整合性・メモリの軽い健康診断
  を実施したうえで、しばらく様子見するのが現実的な対応。
• もし再発するようなら、この記事で紹介した
  • ログ確認
  • メモリ・ストレージの検査
  • アンチチートや仮想化機能の一時無効化
  • 追加のミニダンプ収集
  といった手順で、段階的に原因を絞り込んでいくのがおすすめです。

「とりあえず怖くなってPCを初期化する」前に、この記事の内容を一通り試しておけば、多くの場合は十分な備えになります。それでも不安な場合は、ミニダンプ一式をZIPにして専門フォーラムや信頼できるエンジニアに相談してみてください。