VIDEO_SCHEDULER_INTERNAL_ERROR(0x119)の原因と直し方｜Parameter 1で切り分ける

Q: Parameter 1の値はどこで確認できますか

Windowsが自動で生成するMinidumpファイル(C:\Windows\Minidump)をWinDbgで開き、!analyze -vコマンドを実行すると、Arg1として画面に表示されます。

トラブル・設定

2026.8.23

VIDEO_SCHEDULER_INTERNAL_ERROR(0x119)の原因と直し方｜Parameter 1で切り分ける

本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。

VIDEO_SCHEDULER_INTERNAL_ERRORの直し方 / 2026年8月23日

VIDEO_SCHEDULER_INTERNAL_ERROR(0x119)の原因と直し方
Parameter 1の値で疑うべき原因が変わる

ゲーム中にWindowsが停止し、「VIDEO_SCHEDULER_INTERNAL_ERROR」と表示されることがあります。0x119という停止コードだけでは原因を絞り込めず、同時に記録されるParameter 1の値によって、疑うべき対象がGPUドライバーなのかハードウェアなのかメモリなのか大きく変わります。

Parameter 1の全パターンを一覧化VIDEO_TDR_FAILURE(0x116)との違いを整理Minidump・WinDbgでの確認手順も解説

ゲーム中に前触れなく画面が止まり、再起動後のイベントビューアーや信頼性の履歴を確認すると、Stopコード「0x00000119」「VIDEO_SCHEDULER_INTERNAL_ERROR」が記録されていることがあります。検索してみても「GPUドライバーの不具合」「GPU故障」「メモリ不良」など原因の説明がサイトによってバラバラで、結局何から確認すればいいのか分かりにくい停止コードです。

これは、WindowsのGPUスケジューラーが致命的な違反を検出したことを示すバグチェックです。Microsoft公式ドキュメントでは、この違反の詳しい内容が「Parameter 1」という値で分類されており、値が0x2ならドライバーがコマンドの送信に失敗した状態を、0xCなら致命的なハードウェア関連の障害を、0x400などならメモリ破損や不良ハードウェアを意味すると明記されています。同じ0x119でも、Parameter 1の値によって中身はまったく違います。

この記事では、Microsoft公式のBugCheck 0x119ドキュメントに掲載されているParameter 1の値をすべて整理し、値ごとに優先して確認すべき対象を示します。あわせて混同されやすいVIDEO_TDR_FAILURE(0x116)との違い、Minidumpの保存場所とWinDbgでの!analyze -vの使い方も解説します。GPUドライバーの更新手順やOC・アンダーボルトの解除、XMP・EXPOの確認方法といった一般的な対処は、それぞれ専門の記事に譲り、0x119というバグチェック固有の内容に絞って扱います。

1核心Parameter 1で原因が変わる0x2・0xC・0x400などで疑う対象が違う 2混同注意0x116(TDR失敗)との違い復旧の失敗と違反の検出は別物 3最初に触らないTdrDelayの変更は根治策ではないドライバー開発・デバッグ専用のキー 4自分で解析Minidump・WinDbgの使い方Parameter 1(Arg1)の読み方

定義VIDEO_SCHEDULER_INTERNAL_ERROR(0x119)とは

VIDEO_SCHEDULER_INTERNAL_ERRORは、Windowsのバグチェックコード「0x00000119」です。Microsoft公式ドキュメントは、このバグチェックについて「ビデオスケジューラーが致命的な違反を検出したことを示す」と定義しています。GPUの温度異常やゲームの不具合そのものを指すエラーではなく、Windows内部でGPUの処理を管理している仕組みが「これ以上処理を続けられない状態」を検出したときに発生するという点が、他の一般的なゲームクラッシュとの違いです。

WindowsはWDDM(Windows Display Driver Model)という仕組みでGPUを制御しています。WDDMの中には「GPUスケジューラー」と呼ばれる部分があり、複数のアプリやゲームから届く描画命令を順番にGPUへ渡し、それぞれの処理がいつ完了したかを管理する役割を持っています。VIDEO_SCHEDULER_INTERNAL_ERRORは、このスケジューラーが処理の途中で、ドライバーからの矛盾した報告や内部データの不整合など、本来あってはならない状態を検出した際に発生するバグチェックです。

Windows 11 バージョン24H2以降は黒い画面で表示される場合がある

Microsoft公式サポートページの「Windows 11, version 24H2 and later」の項目では、この種の予期しない再起動が発生した際の画面デザインが、従来の青い背景ではなく黒い背景に変わっていることが案内されています。VIDEO_SCHEDULER_INTERNAL_ERRORが発生した場合も、24H2以降の環境ではいわゆる「ブラックスクリーン」で停止コードとエラー名が表示されることがあります。画面の色が変わっただけで、停止コードやParameter 1を確認する手順自体は変わりません。

出典：Microsoft公式ドキュメント「Bug Check 0x119 VIDEO_SCHEDULER_INTERNAL_ERROR」、および公式サポートページ「Troubleshooting Windows unexpected restarts and stop code errors」を参照しています。

核心Parameter 1の値で原因の見立てが変わる

0x119という数字だけでは、対処法を決められません。エラー画面やWinDbgの解析結果に同時に表示される「Parameter 1」(WinDbgではArg1として表示されます)の値によって、疑うべき対象がまったく変わるとMicrosoftは明記しています。公式ドキュメントには「Parameter 1 is the only parameter of interest. It identifies the exact violation.」(Parameter 1だけが注目すべき値であり、違反の内容を正確に示す)と記載されており、Parameter 2〜4は参考情報の扱いです。公式ドキュメントに掲載されているParameter 1の値と意味は次の通りです。

Parameter 1	意味
`0x1`	ドライバーが無効なフェンスIDを報告した状態
`0x2`	ドライバーがコマンドの送信に失敗した状態
`0x3`	ドライバーがコマンドバッファーのパッチ処理に失敗した状態
`0x4`	ドライバーが無効なフリップキューの長さを報告した状態
`0x5`	ドライバーがシステムコマンドまたはページングコマンドの処理に失敗した状態
`0x6`	マルチアダプターGPUでの割り込みに対し、ドライバーが無効な物理アダプターマスクを報告した状態
`0x7`	レンダリング専用アダプターで、ドライバーが表示VSyncを報告した状態
`0x8`	リセットの原因となったドライバーノードに対応するビットが設定されていなかった状態
`0x9`	ドライバーがコマンドのキャンセル処理に失敗した状態
`0xA`	ドライバーが範囲外の無効な中断フェンスを報告した状態
`0xB`	ドライバーがマルチプレーンオーバーレイのアドレス設定コマンドの処理に失敗した状態
`0xC`	ドライバーが報告したページフォールト情報が、致命的なハードウェア関連の障害を示している状態
`0xD`	ドライバーがDMAページフォールト割り込みで、不正なページフォールト情報を報告した状態
`0xE`	ドライバーがGPU上の最大オーバーレイプレーン数を超えるプレーンインデックスでVSyncを報告した状態
`0xF`	未使用の値
`0x10`	エンジンリセット後、OSがエンジンの動作を再開する前に、ドライバーが予期しない割り込みを報告した状態
`0x11`	ドライバーが、OSがまだ生成していないサスペンド完了フェンス値を報告した状態
`0x12`	ドライバーがネイティブフェンスの監視対象値の更新に失敗した状態
`0x13`	ドライバーがネイティブフェンスの現在値の更新に失敗した状態
`0x400`	OS内部の状態エラー。多くの場合、メモリ破損または不良ハードウェアが原因
`0xE00`	パッシブフリップ要求を処理するための事前確保パケット用メモリを、OSが使い果たした状態
`0x1000`	OS内部の状態エラー。多くの場合、メモリ破損または不良ハードウェアが原因
`0xA000`	OS内部の状態エラー。多くの場合、メモリ破損または不良ハードウェアが原因
`0x10000`	OS内部の状態エラー。多くの場合、メモリ破損または不良ハードウェアが原因

出典：Microsoft公式ドキュメント「Bug Check 0x119 VIDEO_SCHEDULER_INTERNAL_ERROR」のParameter 1一覧表を、原則としてそのまま日本語化して掲載しています。

切り分け方Parameter 1の値ごとに優先して確認する対象

すべての値を覚える必要はありません。実際に切り分けるときは、Parameter 1がどの範囲に入るかで、優先して確認する対象を切り替えてください。

0x1〜0x13台(特に0x2・0x3・0x5)ならGPUドライバーを最優先この範囲の値の多くは、Microsoft公式ドキュメントでドライバー側の処理失敗として定義されています。特に頻度が高いのは0x2(コマンドの送信失敗)と0x3(コマンドバッファーのパッチ処理失敗)です。この範囲の値が出ている場合は、GPUドライバーの更新・ロールバック・クリーンインストールを最優先で確認してください。具体的な確認手順は「ディスプレイドライバーが応答を停止した」の解説記事にまとめています。

0xCならドライバーに加えハードウェア側も疑う0xCは、ドライバーが報告したページフォールト情報が致命的なハードウェア関連の障害を示していることをMicrosoftが明記している値です。ドライバーの不具合だけでなく、GPU本体やVRAM、PCIeスロットの接触不良といったハードウェア側の要因もあわせて疑う必要があります。オーバークロック・アンダーボルト設定を工場出荷時に戻したうえで再現するかどうかも確認してください。

0x400・0x1000・0xA000・0x10000ならRAMも確認この4つの値はいずれもMicrosoft公式ドキュメントで「内部OS状態エラーで、多くの場合メモリ破損または不良ハードウェアが原因」と明記されています。GPUドライバーの問題というより、システムメモリ(RAM)やその設定を疑う必要がある値です。XMP・EXPOを有効にしている場合は、それが原因で不安定になっていないかXMP・EXPO有効化で不安定になる原因の解説記事で確認してください。

0xE00だけは毛色が違う特殊枠0xE00は、Microsoftが「パッシブフリップ要求を処理するための事前確保パケット用メモリを、OSが使い果たした状態」と定義している値です。メモリ破損やハードウェア故障というより、複数ディスプレイの接続や高負荷な描画処理で、OS内部の管理用リソースが不足した状況を示している点で他の値と性質が異なります。

比較VIDEO_TDR_FAILURE(0x116)との違い

0x119は、番号が近いVIDEO_TDR_FAILURE(0x116)と混同されがちです。どちらもGPU関連のバグチェックですが、Microsoft公式ドキュメント上の定義は明確に異なります。

VIDEO_TDR_FAILURE復旧の失敗

BugCheck0x00000116

意味ディスプレイドライバーのリセットと、タイムアウトからの回復を試みたが失敗した状態

発生のきっかけTDR(Timeout Detection and Recovery)がGPUの応答遅延を検知し、既定2秒のタイムアウトから復旧しようとしたが、その復旧処理自体が失敗した場合。または既定で1分以内に5回を超えるTDRが発生した場合

VIDEO_SCHEDULER_INTERNAL_ERROR違反の検出

BugCheck0x00000119

意味GPUスケジューラーが致命的な違反を検出した状態

発生のきっかけタイムアウトからの復旧の成否とは関係なく、ドライバーからの矛盾した報告や内部データの不整合など、スケジューラーが処理を継続できない状態をParameter 1の内容として検出した時点で発生する

違いを一言でいうと、0x116は「TDRによる復旧を試みて、失敗した」結果のバグチェックであるのに対し、0x119は「復旧を試みる前の段階で、スケジューラー自体が致命的な矛盾を検出した」結果のバグチェックです。TDRが正常に働いた場合に表示される「ディスプレイドライバーが応答を停止したため、正常に回復しました」というメッセージや、TDRの仕組みそのものの詳細はこちらの解説記事で扱っています。同記事内でもVIDEO_TDR_FAILURE(0x116)に触れていますが、今回解説したParameter 1ごとの切り分け方と矛盾しない内容です。

出典：Microsoft公式ドキュメント「Bug Check 0x116 VIDEO_TDR_FAILURE」を参照しています。

注意TdrDelayのレジストリ変更を最初に試すべきでない理由

0x119が表示されると、「TdrDelay」というレジストリキーの値を大きくしてタイムアウトを延ばす対処法がよく紹介されます。しかし0x119は、TDRのタイムアウト検知そのものではなく、GPUスケジューラーが致命的な違反を検出した結果のバグチェックです。TdrDelayを変更しても、この違反の発生自体を防ぐことはできません。

Microsoft公式は「エンドユーザーは操作すべきでない」と明記

Microsoft公式ドキュメントは、TdrDelayや関連するTdrLevelといったレジストリキーについて、本来はドライバー開発時のテスト・デバッグ専用であり、エンドユーザーが操作すべきものではないと明記しています。タイムアウト時間を延ばす行為は、根本原因(ドライバーの不具合・ハードウェア障害・メモリ破損など)を直すものではなく、症状が表面化するまでの時間を先送りにしているだけです。レジストリ変更の詳しいリスクと、TdrLevelとの違いはTDRの解説記事で解説しているので、そちらを参照してください。

出典：Microsoft公式ドキュメント「TDR registry keys」を参照しています。

解析Minidumpの場所とWinDbgでの確認手順

Parameter 1の値は、体感やゲームのエラー画面だけでは分かりません。Windowsが自動生成するクラッシュダンプを自分で確認する必要があります。0x119を含むバグチェックが発生すると、多くの環境でC:\Windows\Minidumpフォルダーに、日付が入ったファイル名の小容量ダンプファイル(拡張子.dmp)が保存されます。

詳しい原因を自分で確認したい場合は、Microsoft Storeで配布されているWinDbgを導入し、生成されたダンプファイルを開いて!analyze -vコマンドを実行します。このコマンドはダンプファイルの自動解析を行い、バグチェックの名称・番号と、Parameter 1(Arg1)を含む各パラメーターの値、処理を担当していたドライバーモジュール名を表示します。

!analyze -vの出力イメージ(値は環境によって変わります)

VIDEO_SCHEDULER_INTERNAL_ERROR (119)
Arg1: 0000000000000002
Arg2: fffff8016470c14c, ドライバーモジュールへのポインタ
Arg3: 0000000000000000
Arg4: 0000000000000000

MODULE_NAME: nvlddmkm
IMAGE_NAME:  nvlddmkm.sys

この例ではArg1が0000000000000002、つまりParameter 1が0x2です。先ほどの一覧表と照合すると、「ドライバーがコマンドの送信に失敗した状態」だったと分かります。MODULE_NAMEやIMAGE_NAMEの欄には、違反の発生時に処理を担当していたドライバーモジュール名が表示されます。

出典：Microsoft公式ドキュメント「Analyze a Kernel-Mode Dump File by Using WinDbg」、「Read small memory dump files」を参照しています。

誤解に注意nvlddmkm.sys等が表示されてもGPU故障と断定できない理由

NVIDIA環境ではnvlddmkm.sys、AMD環境ではamdkmdag.sysなど、ディスプレイドライバー本体のファイル名がMODULE_NAMEやIMAGE_NAMEの欄に表示されることがよくあります。GPUを直接制御するディスプレイドライバーは、Windowsのグラフィックス処理における最終的な窓口にあたるため、電圧不足によるハードウェアエラーや、破損したメモリ領域へのアクセスなど、ドライバー自身の不具合ではない要因によって発生した違反でも、結果的にドライバーのモジュール名が解析結果に残りやすい構造になっています。

そのため、nvlddmkm.sysやamdkmdag.sysが表示された直後にGPU本体の故障と断定しないでください。まずParameter 1の値を確認し、ドライバー系の値(0x1〜0x13台)なのか、ハードウェア・メモリ系の値(0xC・0x400・0x1000・0xA000・0x10000)なのかを見立てたうえで、後述する確認順に沿って切り分けを進めてください。

出口0x119を切り分けるおすすめの順番

闇雲にパーツを交換する前に、次の順番で確認すると、大半のケースで見当がつきます。

Parameter 1(Arg1)の値を確認するMinidumpファイルを!analyze -vで解析し、Arg1の値を先ほどの表と照合します。ドライバー系(0x1〜0x13台)か、ハードウェア・メモリ系(0xC・0x400・0x1000・0xA000・0x10000)かで、この先の優先順位が変わります。

GPUドライバーを確認する更新・ロールバック・クリーンインストールの具体的な手順は「ディスプレイドライバーが応答を停止した」の解説記事で扱っています。同記事ではGPU側のオーバークロック・アンダーボルト設定を工場出荷時に戻す手順も解説しています。

XMP・EXPO設定を確認する特にParameter 1が0x400・0x1000・0xA000・0x10000だった場合は、RAM側の設定を優先して確認してください。停止コードとの対応や電圧の目安はXMP・EXPO有効化で不安定になる原因の解説記事にまとめています。

特定ゲームだけか、複数ゲームで再現するか確認する特定ゲームだけで発生する場合は、ゲーム側の不具合やDirectXの処理も切り分け対象になります。DXGI関連のエラーが同時に出ている場合の発生パターン別の確認先はDXGI_ERROR_DEVICE_HUNG・REMOVED・RESETの解説記事で整理しています。複数のゲームで再現する場合は、ハードウェアを疑う優先度を上げてください。

この順番で確認しても改善しない場合や、Parameter 1が0xC・0x400番台でハードウェア関連が濃厚な場合は、別のGPUやRAMモジュールでの交換検証に進んでください。元のパーツを別のPCへ取り付けても同じ症状が出る場合は、そのパーツ自体を疑う有力な根拠になります。

Q&Aよくある質問

VIDEO_SCHEDULER_INTERNAL_ERRORは必ずGPU故障が原因ですか

いいえ。Parameter 1の値によって疑うべき対象が変わり、GPUドライバーの不具合やメモリ破損など幅広い原因が考えられます。表示されたParameter 1(WinDbgのArg1)の値を確認してから対処を判断してください。

VIDEO_TDR_FAILURE(0x116)とVIDEO_SCHEDULER_INTERNAL_ERROR(0x119)はどちらが深刻ですか

深刻度の優劣を示す関係ではありません。0x116はTDRによる復旧処理自体が失敗した状態、0x119はスケジューラーが致命的な違反を検出した状態で、発生する段階が異なります。どちらもParameter 1やArg2以降の内容を確認して原因を切り分けてください。

Parameter 1の値はどこで確認できますか

Windowsが自動で生成するMinidumpファイル(C:\Windows\Minidump)をWinDbgで開き、!analyze -vコマンドを実行すると、Arg1として画面に表示されます。

TdrDelayを変更すれば直りますか

根本原因は直りません。0x119はTDRのタイムアウト検知そのものとは別の仕組みで発生するバグチェックのため、タイムアウト時間を延ばしても違反の発生自体を防げません。Microsoft公式も、このレジストリキーはエンドユーザーが操作すべきものではないと明記しています。

nvlddmkm.sysが表示されたら、GPU交換を検討すべきですか

すぐに交換する必要はありません。ディスプレイドライバーはGPU処理の最終窓口にあたるため、他の要因が原因でもドライバーのモジュール名が解析結果に残ることがあります。Parameter 1の値、ドライバー、XMP・EXPOの順に確認し、それでも複数のゲームで再現する場合に交換検証を検討してください。

まとめまとめ｜0x119という数字だけで原因を決めつけない

まとめ

VIDEO_SCHEDULER_INTERNAL_ERROR(BugCheck 0x00000119)は、WindowsのGPUスケジューラーが致命的な違反を検出したことを示すバグチェックです。0x119という数字だけでは原因を絞り込めず、同時に記録されるParameter 1の値によって疑うべき対象が変わります。0x1〜0x13台の多くの値はドライバー側の処理失敗、0xCは致命的なハードウェア関連の障害、0x400・0x1000・0xA000・0x10000はメモリ破損や不良ハードウェアとMicrosoftが明記しています。

混同されやすいVIDEO_TDR_FAILURE(0x116)は、TDRによる復旧処理自体が失敗した結果のバグチェックであり、0x119とは発生する段階が異なります。TdrDelayの変更で直せる問題ではないため、まずParameter 1の値を確認したうえで、GPUドライバー、XMP・EXPO設定という順番で切り分け、特定ゲームだけか複数ゲームで再現するかでハードウェアを疑う優先度を判断してください。