Driver Verifier を使用して問題のあるドライバーを特定します。 DRIVER_VERIFIER_DETECTED_VIOLATION ブルー スクリーン エラー (0x000000C4) を修正する方法 PC 上で破損したドライバーを見つける方法

アンドロイド用 31.10.2021
アンドロイド用

ドライバーを使った実験は危険であり、システムに損傷を与える可能性があることを警告します。 事前にシステムのバックアップを作成し、Windows から別の不審なドライバーを削除するなどの行為をしないことをお勧めします。

そして彼らが叱らなくなるとすぐに ウィンドウズから マイクロソフト、貧しいものを同時に遅く、不具合があり、さらには不安定であると呼びます。 しかし、急いでそれを放棄しようとする人は誰もいませんし、一般的に、彼らがそれを放棄する可能性は低いです。 したがって、貧しい開発者を叱ったり、無意味な炎上を起こしたりするのではなく、実際にシステムにバグがある理由を理解したほうがよいでしょう。 ちょっとした秘密を教えます。 死と不安定な仕事の悪名高いスクリーンの中で ウィンドウズほとんどの場合、サードパーティのドライバが原因であり、オペレーティング システム自体はまったく関係ありません。 ここでは、そのようなドライバーを検出し、システムから削除する方法を説明します。

ドライバーの設計上の欠陥は、クラッシュから死のブルー スクリーン ( BSOD– 死のブルー スクリーン）、コンピューターの速度低下、ドライバーとはまったく関係のない一部のアプリケーションの奇妙な動作などに影響します。

「死のブルー スクリーン」は、重大な問題の存在を明確に示し、どこを掘るべきかについてのヒントを提供するという点で、注目に値します (皮肉ではありません!)。 多くの場合 (常にではありませんが)、「違反した」ドライバーの名前が、死のブルー スクリーンの右上隅に直接表示されます。 ただし、その名前が存在しない可能性もあり、さらに悪いことに、まったく関係のないドライバーの名前が存在する可能性もあります。

たとえば、非常に一般的なビデオ カード ドライバーの 1 つは、 マトロクス G450グラフィックス サブシステムの基本構造を破壊する傾向があります ウィンドウズ 2000 その結果、BSOD にシステム ドライバーの名前が表示されます。 win32k.sys、これは USER および GDI 関数の重要な部分を実装しますが、当然のことながら、それとは何の関係もありません。 したがって、死の読み取りのブルー スクリーンを解釈することは、魔法、直感、科学、芸術、あらゆるものを少しずつ組み合わせたものです。

ブルー スクリーンは、ドライバの欠陥に加えて、オーバークロックされたプロセッサ、RAM の欠陥、ハード ドライブ コントローラの歪み、スロットに完全に挿入されていない PCI カード、いずれかのコネクタの接触不良などのハードウェア障害によって発生することもあります。コネクタ、電源の不良、マザーボードの電解コンデンサの膨張。 そして、後者はさまざまな理由で不機嫌になります。近くのプロセッサからの過熱、メーカーによって「報告されていない」セラミックコンデンサの不足（その結果、RFコンポーネントが電解液を通過して大幅に加熱されるため）、そして最終的には、ユニットスタビライザー内の主要なトランジスタのリークが原因です。 したがって、木を切る前に、座っているアイロンが完全に機能することを確認する必要があります。 これはどうすればできるのでしょうか?

鉄との対決

ハードウェア障害によって発生するブルー スクリーンは自然発生的に発生し、ユーザーの特定の操作とは関係なく、予期せずに表示されます。 アプリケーションもさまざまな場所で重大なエラーを発生し始めており、システムによって発行されるエラー コード、アドレス、その他の情報はすべての場合で異なります。 ちなみに、ワイヤレス ネットワークなどの I/O デバイスからの非同期要求を処理するドライバーは、ほぼ同じように動作します。 欠陥のあるドライバーによって引き起こされる死亡のブルー スクリーンは、通常、特定の一連の操作を実行するときに発生し、多かれ少なかれ一定の情報が含まれています。

ハードウェアからすべての疑いを取り除くには、別のハードドライブをシステムに接続し、新品のクリーンなハードドライブをインストールするだけで十分です。 ウィンドウズそしてしばらくそれに取り組みます。 死のブルー スクリーンが消えない場合は、実際にはハードウェアが原因であり、ハードウェアを変更する時期が来たことを意味します。 欠陥のあるコンポーネントの発見については、別の議論のトピックとして次回に譲りますが、今は袖をまくって、これらの潜伏性の要因を把握してください。

証明書のない薪はそのまま火室に入る

ドライバー開発に必要なツールのセット全体 ( 第一電子工業株式会社– ドライバー開発キット)、Microsoft はこれを付属のドキュメントとともに無料で配布しています。 ドライバーは、非常にバグが多く不安定な場合があります。

このような混乱を避けるために、 マイクロソフト古くは、ドライバーに課せられた要件を遵守していることをドライバーに証明する手順が導入され、その後、ドライバーにはデジタル署名が発行されました。 それとも...発行されず、修正のために送られました。 そして、認証は単なる正式な手順であり、致命的なエラーや開発上の欠陥がないことを保証するものではありませんが、それでも、率直に言って「先駆者」ドライバーの一部を排除します。

理想的には、デジタル署名されたドライバーのみをシステム上に保持する必要があります。 また、デジタル署名は保険ではありませんが、その存在はすでに一定レベルの開発文化を示しています。 デジタル署名のないドライバーは、刺された豚よりも悪質であり、可能であれば削除する必要があります (特に、ドライバーの多くは、システムの奥深くに侵入して不安定性を引き起こすルートキットまたは積極的な防御メカニズムによってインストールされたマルウェアであるため)。 つまり、デマゴギーに耽るのはやめて、デジタル署名なしでドライバーのリストを作成するにはどうすればよいかという 1 つの単純な質問に答えてみましょう。

このユーティリティはこれに役立ちます sigverif.exe、オペレーティング システムの標準配信パッケージに含まれており、WINNT\System32 ディレクトリにあります。 これを起動すると、ダイアログ ボックスが表示されます。 「詳細」ボタンをクリックし、「検索」タブでラジオボタンを「署名されていないシステムファイルについて通知する」位置（デフォルトでは表示されない）から「署名されていない他のファイルを検索する」位置に移動して選択基準を設定します。デジタル署名」の立場。 その後、「検索オプション」で「次の種類のファイルを検索する」ボックスを開いて「*.sys」を選択し、以下に検索フォルダー「C:\WINNT」を指定し、「次の種類のファイルを検索する」にチェックを入れてください。サブフォルダー」チェックボックスをオンにします。

実際、厳密に言えば、ドライバーは sys 拡張子を持つ必要はなく、必ずしも WINNT ディレクトリに限定されるわけではなく、「その」アプリケーションのディレクトリにあり、一部のアプリケーションではドライバーを内部に保存することもあります。 起動直後 (またはその他の時点)、ファイルを現在のディレクトリまたは一時ディレクトリのディスクに保存し、ドライバーをメモリにロードして、すぐにディスクから削除します。 これは悪意のあるウイルスだけでなく、有名な Windows 地下研究者 Mark Russinovich のユーティリティなど、非常に立派なプログラムによっても行われます。

したがって、実験を純粋に行うために、現在メモリ内にあるドライバーのリストを取得し、それらをディスク上にあるドライバーと比較しても問題はありません。 ドライバーはオペレーティング システムを再起動せずに無料でダウンロード/アンロードできるため、「現在」という言葉が重要です。 この操作は、Microsoft サーバーからダウンロードできる DDK の一部であるコマンド ライン ユーティリティ drivers.exe を実行して、数回実行することをお勧めします。 スイッチなしで行コマンドを使用してユーティリティを起動します。 ドライブ.exeすべての情報を画面にダンプしますが、通常はシステム内に多数のドライバーがあり、画面に収まらないため、これは良くありません。 ただし、宗教により、出力ストリームをテキスト ファイル (drivers.exe >file-name.txt) にリダイレクトできます。このファイルは、Word やメモ帳など、任意のテキスト エディタで開くことができます。 あとは、垂直ブロック (メモ帳では許可されていません) を選択し、ドライバーのリストを取得するだけです。 オペレーティング システム カーネルから直接!

これらのドライバーの少なくとも 1 つが C:\WINNT\ ディレクトリにない場合、そのデジタル署名は検証されません。 当然のことながら、そのようなドライバーはすぐに注目を集めますが、それはどこから来たのかという当然の疑問が生じます。 まず、ディスク上のすべてのディレクトリをスキャンします。 存在しない場合は、Soft-Ice の CreateFileW 関数にブレークポイントを設定し、それに渡された引数を確認します。 遅かれ早かれ、バグのあるドライバーに遭遇することになります。その後は、ドライバーを生成したプロセスの名前が表示されている Soft-Ice 画面の右下隅を見ることしかできません。 詳細については、「ソース テキストを使用しないプログラムのデバッグ技術」という書籍を参照してください。この書籍の電子コピーは、ftp または http サーバー nezumi.org.ru および当社のディスクにあります。 そして私たちは公益事業を苦しめ続けています sigverif.exe.

「OK」、「開始」をクリックすると、画面に「温度計」が表示され、進行状況が表示され、ハードドライブがすべてのヘッドでカサカサ音を立て始めます。 作業が完了すると、デジタル署名のないドライバーのリストが作成され、画面に表示されます。

熱狂的な人の中には、システムから異端を一掃するために、署名されていないドライバーをすべて削除することを提案する人もいます。そうすれば、すべての問題がなくなると彼らは言います。 これはどうすればできるのでしょうか? 最も大雑把な解決策は、FAR またはエクスプローラー (もちろん管理者権限が必要です!) を介してディスクからそれらを削除することです。 ただし、そのような操作の結果は非常に悲惨な結果になる可能性があるため、エクスプローラーでドライバーのアイコンを右クリックし、「プロパティ」で製造元の名前を見つけ、インストールされているアプリケーション/ハードウェアの種類を確認することをお勧めします。このドライバーを適切な方法でアンインストールしてください。 確かに、ここには「しかし」が 1 つあります。

以下の図ではドライバーが強調表示されています。 g400m.sysこれは Matrox G450 カードに付属しており、Matrox はまったく弱い会社ではありませんが、デジタル署名を受け取りませんでした (Microsoft が署名しなかったか、Matrox 自体が手間をかけたくなかったかのどちらかです)。 当然のことながら、システムから削除した後は、SVGA モードのことを忘れる必要があります。 ただし、Matrox Web サイトにアクセスして、ドライバーの最新バージョンをダウンロードすることはできます (ドライバーはすでにデジタル署名されています)。 ここだけ...署名付きバージョンと署名なしバージョンの両方に多くの致命的なエラーが含まれており、特に特定の状況の結果として、オーバーレイ モードに切り替えようとすると、ドライバーがすでに解放されているメモリを解放しようとするため、システムが BSOD でクラッシュします。

したがって、デジタル署名の有無自体は何の意味も持たず、署名付きドライバーのみを使用したとしても、安定性は保証されません。

ここから記事の 2 番目の部分、つまり戦闘に近い状況でのドライバーのテストに進みます。

私たちは薪に本当のテストをします

DDK には素晴らしいユーティリティが含まれています 運転者 検証者ドライバーにとっては極限状態と自殺に近い最も過酷な条件を作り出し、失敗の確率が最大となり、欠陥ドライバーの名前が最高の精度で決定されます（たとえ開発欠陥によって被害を受けなかったとしても、ただし、他の人のドライバーのデータ構造は破壊されます)。

注意することが重要です 運転者 検証者- これは薬ではなく、単なる診断ツールです。 それでも失敗からあなたを救うことはできませんが（それどころか、失敗の激しさは数桁増加します）、十分な信頼性で「卑劣な」ドライバーを特定するのに役立ちます。

そこで、verifier.exe を起動すると、ウィンドウが表示されます。 運転者 検証者 マネージャー、[設定] タブに移動し、ラジオ ボタンを [すべてのドライバーを確認する] 位置に移動し、[優先設定] ボタンを押します。これにより、次の確認タイプが設定されます。

  • 特別 プール– テスト対象のドライバーには、割り当て用の特別なメモリ領域が割り当てられます。これは、あまり高速には機能しませんが、自分自身や他のユーザーのデータのほとんどの種類の破壊を検出できます。
  • 力 IRQLチェック中。 IRQL は割り込み要求レベルです。 ドライバー開発者が犯す最も一般的な間違いは、ページング マネージャーが機能しない IRQL レベルでメモリにアクセスしようとすることです。 また、必要なページが突然ディスクに追い出された場合、システムはブルー スクリーンに変わり、「IRQL_LESS_OR_EQULAR」という文字が表示されます。 このモードを強制すると、ドライバー ページが強制的にディスクにフラッシュされるため、設計上の欠陥が 100% 発生します。
  • 低い リソース シミュレーションシステム リソースが壊滅的に不足した場合にドライバーがどのように動作するかを確認するためにインストールすると便利ですが、これを実行する必要はありません。ただし、[プール追跡] チェックボックスは残しておくことをお勧めします (メモリの正しい処理を監視する)プール）。 入出力エラー (I/O 検証) はすべてのエラーのうち重要ではない部分を占めるため、このチェックボックスの位置は通常、まったく重要ではありません。

設定の選択が完了したら、「適用」ボタンをクリックし、提案に従って再起動します。

ブートが開始された直後、カーネルが通常よりも多くのチェックを実行するため、システムの速度が著しく低下しますが、これは当然のことです。 エラーが検出されると、死のブルー スクリーンが点滅し、ドライバー名やその他の情報が表示されます。これらの情報は、開発者にとっては役に立ちますが、私たちにとっては役に立ちません。 私たちにできることは、ドライバーを最新バージョンに更新するか、それを使用するプログラム（ハードウェア）の使用を拒否することだけです。 実際には、濡れた木材に着火するためのオプションがもう少しありますが、それについては後ほど説明します。

verifier.exe を実行すると、いつでも検証ステータスを確認できます。 [ドライバー ステータス] タブには、検出されたすべてのドライバーのステータスが現在の状況の説明とともに一覧表示されます。 「ロード済み」ステータスは、このドライバーが少なくとも 1 回ロードされ、テストされていることを意味します (ただし、完全にはテストされていない可能性があります。つまり、ドライバーのすべての部分がテストされていない可能性があります)。 アンロード済みステータスは、ドライバーが、それを使用するシステム/プログラムまたは独自の要求によって、ドライバーがロード、検証 (おそらく部分的に) され、アンロードされたことを意味します。 後者は、拡張カードをスロットから野蛮に引き抜いて、つまりアンインストールを実行せずに取り外された機器から残ったドライバに特に典型的です。 生き残ったドライバーはバスをスキャンして「その」ハードウェアを見つけようとしますが、検索に失敗し、メモリから自らをアンロードします。その結果、システムの起動が (場合によっては大幅に) 遅くなり、他のドライバーと競合します。 道徳: 機器はすべてのルールに従ってシステムから削除する必要があります。 ただし、すべての Unloaded ステータスが異常な状況の兆候であるわけではありません。そのようなステータスのドライバーを削除する前に、これがどのような種類のトナカイなのか、そもそもどこから来たのかを把握する必要があります。

「Never Loaded」ステータスは、このドライバーがまだロードされておらず、検証されていないことを示します。したがって、このドライバーに関連するさまざまなプログラムを起動するまで待つ必要があります。 ただし、一部のドライバー (特に誤ってアンインストールされたドライバー) はロードされず、したがって決してチェックされません。

しばらく (数時間から数日) ハード チェック モードでシステムを操作した後、以前に被害を受けたほとんどすべての欠陥ドライバを特定し、その名前を紙に書き留めます。

同じベリファイアを使用して、システムを通常モード (つまり、パフォーマンスを消費する追加のチェックなし) に戻すことができます。 [設定] タブに戻り、ラジオ ボタンを [選択したドライバーを確認] の位置に移動し (ドライバーを選択しないでください)、[すべてリセット] をクリックし、次に [適用] をクリックして再起動します。 全て！ システムは通常の速度で動作しますが、チェックは行われません。

湿った薪はどうすればいいですか？

しかし実際のところ、ドライバーに欠陥があると何ができるのでしょうか? デバッガーを手に持つ方法を知っているハッカーは、十分な自由時間があれば、デバッガーを逆アセンブルし (幸いなことに、ドライバーのサイズは通常小さい)、エラーを見つけて、それを修正する方法を考え出すことができます。これは時間がかかりすぎます。

ドライバーを (それを使用するハードウェア/プログラムとともに) 捨てるという選択肢もありません。 ただし、馴染みのない中国メーカーの 20 ドルのサウンド カードが死のブルー スクリーンの原因であるとわかっていれば、それをより価値のあるものに交換するという非常に強い動機が生まれます。 しかし、厳密に言えば、これは誰にとっても明らかであり、追加のコメントを必要としません。

しかし、シングル プロセッサ環境で開発 (およびテスト) されたドライバーがデュアル プロセッサ マシンにインストールされていることが原因で、膨大な数のクラッシュやブルー スクリーンが発生していることを誰もが知っているわけではありません。 ここでの「デュアルプロセッサ」とは、2 つの石を備えた実際のプラットフォームと、ハイパー スレッディング/マルチコア プロセッサの両方を意味します。 大多数のアプリケーションでは実質的にパフォーマンスが向上しないため、家庭用コンピュータには 2 つのプロセッサがまったく必要ないことが知られています (そして多数のテストによって確認されています)。

したがって、システムが不安定で、何らかの理由で欠陥のあるドライバーを取り除くことができない場合は、BIOS セットアップを試して、「仮想デュアルプロセッサ」マシンをシングルプロセッサのマシンに変えることができます。 。 boot.ini ファイルを開くことによっても同様の効果を得ることができます (コンピュータ上で Windows NT/2000/XPこれは、システムがインストールされている論理ドライブのルート ディレクトリにあります)、それに /ONECPU スイッチを追加して、エラーが消えることを期待して再起動します。

リスト 1

一般的な boot.ini ファイルの例


タイムアウト=30

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Pro" /fastdetect /SOS

リスト 2

利用可能なプロセッサのうち 1 つだけを使用するようにシステムを構成します


タイムアウト=30
デフォルト=マルチ(0)ディスク(0)rディスク(0)パーティション(1)\WINNT
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Pro" /fastdetect /SOS /ONECPU

しかし、オン ウィンドウズ ビスタ boot.ini ファイルはなく、特別なユーティリティを使用してブート設定を構成することは (一時的に) 可能ですが、Microsoft はこの抜け穴を完全に排除し、BIOS セットアップのみを残すことを計画しています。 ただし、 ビスタそして、それに切り替える頃には、ドライバー開発者はおそらくマルチプロセッサ マシンを入手し (他に売りに出されるマシンが残っていないため)、作成したマシンをマルチプロセッサ環境でテストすることになるでしょう。

もう一つ微妙な点。 ドライバー開発者が犯す最も一般的な間違いは、ページング マネージャーが機能しない IRQL レベルでプリエンプティブル メモリにアクセスすることであり、要求されたページがメモリ内にない場合はクラッシュが発生することであると上で述べたことを覚えていますか? ここでの明白な解決策は、事実上ディスクにページが追い出されないボリュームまで RAM を増やすことです。 現在のメモリの価格では、ほとんどの人が新しいメモリ スティックを 2 ～ 3 枚購入する余裕があります。 しかし、この問題には、よりアクセスしやすい (そしてより洗練された) 解決策があります。 パラメータの場合 DisablePagingExecutive、次のレジストリ ブランチにあります HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagementが 1 (デフォルトでは 0) に等しい場合、核コンポーネントはプリエンプトされません。 したがって、「レジストリ エディタ」を起動し、この重要なパラメータを変更して再起動するだけです (変更は再起動後にのみ有効になります)。これが失敗の問題の解決に役立つことを期待しています。

このような場合、Windows XP でドライバがどの程度正しく動作するかを確認するための特別なユーティリティがあります。 検証者.exe。 ユーティリティ 運転者 検証者は、ドライバーにとって最も厳しい条件を作り出し、失敗する可能性が非常に高く、失敗したドライバーの名前が最高の精度で決定されます。 したがって、非系統的な障害が発生した場合は、ユーティリティを実行すると便利です。 運転者 検証者。EXE。 Verifier は Windows に含まれており、次のディレクトリにあるため、ダウンロードする必要はありません。 Windows\システム32


1 との作業 検証者。EXE

1.1. 起動しましょう Verifier.exe。スタート - 実行 - 検証ツール。EXE:

1.3. ユーティリティ 運転者 検証者。EXE再起動を要求されます:



1.4. 2 つの新しいパラメータがレジストリに表示されます。


-- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
関連するレジストリ設定 運転者 検証者。EXE

2 試験結果

2.1. ユーティリティの最初のウィンドウの場合 運転者 検証者。EXE選ぶ "現在テストされているドライバーに関する情報を表示する",するとこのようなウィンドウが表示されます。 どのドライバーがチェックされ、どのドライバーがチェックされていないかが表示されます。 押すことで "さらに遠く"では、テストされたドライバーに関するその他の情報を確認できます。

2.2. ユーティリティでドライバを確認した結果 運転者 検証者。EXEシステムが落下する可能性があります。 ドライバー、システムエラー、および のチェック中にエラーが発生した場合。 代表的なエラーコードとその説明を以下に示します。

0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
· 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
· 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
· 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
· 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
· 0xE6: DRIVER_VERIFIER_DMA_VIOLATION


2.3. プログラムによるダンプ復号化の例 :


3. 役立つリンク

Driver Verifier ユーティリティ (verifier.exe) は、BSOD 後のメモリ ダンプの分析では問題のあるドライバーが見つからない場合に、問題のあるドライバーを分析するように設計されています。 Driver Verifier は、最も問題のある状況における「救世主」です。

Driver Verifier を使用すると、次のことが可能になります。

    ドライバーのストレステスト（リソース不足の状況がシミュレートされます）。

    バッファオーバーフロー制御。

    特定の IRQL での不正な操作によって発生するエラーを制御します。

    I/O エラー分析。

    デッドロック状況の検出など

Driver Verifier ユーティリティは、次の場合に非常に役立ちます。

    管理者 (ユーザー) は、この特定のドライバーがシステムのクラッシュを引き起こしているのではないかと疑っており、これが実際に当てはまるかどうかをさらに確認したいと考えています。

    ドライバー開発者はドライバーをテストしたいと考えています。

    BSOD の後にダンプを分析する場合、問題のあるドライバーを見つけることはできません。

メモリ ダンプの分析で最も困難なケースの 1 つは、ドライバーが割り当てたバッファの終了前後のデータを誤って上書きしてしまう場合です。 このような場合、OS カーネルでエラーが発生します (たとえば、BSOD 後のダンプ分析により、ntoskrnl.exe でエラーが発生したことがわかります)。

具体的な例を使って同様のケースを見てみましょう。 NotMyfault ユーティリティを使用すると、BSOD (「バッファ オーバーフロー」) が発生します。

Windbg を使用したダンプ解析の結果を以下に添付します。

ダンプ分析によると、次のことがわかります。

1. Arg1: 00000007、すでに解放されているプールを解放しようとします (すでに解放されたプールを解放しようとしました)

2.イメージ名: ntkrpamp.exe (システム自体のコアがこれに関係しています)

このようなエラーの場合、検証者が助けになります。

ベリファイアを起動します。

「非標準パラメータの作成」を選択します。 次に「リストからパラメータを選択」を選択します。

「リソース不足をシミュレートする」以外をすべて選択します。

次に、「このリストのアンロードされたドライバーを選択する」を選択し、NotMyfault.exe プログラムと同じディレクトリにある myfault.sys ドライバーへのパスを指定します。

次にドライバーをマークし、「完了」をクリックします。 この後、コンピュータを再起動する必要があります。

最初と同じアクションをすべて実行します。 NotMyfault.exe を実行し、「バッファ オーバーフロー」を選択して「クラッシュ」をクリックします。 お気づきのとおり、いつ誰がこのメモリを操作しようとするかは事前に不明であるため、クラッシュはすぐには発生しない可能性があります。 以下の画像からわかるように、ベリファイアのおかげで、システムは問題のあるドライバーを特定できます。

BSOD 後のメモリ ダンプの Windbg.exe で!analyze –v を使用して分析してみます。

検証プログラムは、テスト対象のドライバーが、カーネルで使用可能な通常のメモリの代わりに、そのようなエラーを検出するように設計された特別なプールを使用するようにします。 このおかげで、BSOD の原因となるドライバーを見つけることができます。

分析結果を見てみると以下のことがわかります。

1. DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) – これは検証者によって生成されるエラーの 1 つです

2.IMAGE_NAME: myfault.sys – 問題の原因となったドライバー。

したがって、BSOD 発生後にメモリ ダンプを分析しても「犯人ドライバ」を見つけることができない場合は、verifier.exe プログラムを使用します (メモリ不足を除くすべてのチェックをインストールします)。

Driver Verifier (verifier.exe) を使用する最も簡単な方法は、次のパラメーターを指定して実行することです。

verifier /standard /driver ドライバ ファイル名

投稿閲覧数: 1,042

ユーティリティ 運転者 検証者 Windows XP 以降のすべてのバージョンの Windows に含まれており、ドライバーを確認し、原因となっている問題のあるドライバーを特定できます。 死のブルースクリーン (BSOD- 死のブルー スクリーン) を検出し、さらなる分析のために問題のあるドライバーに関する詳細情報をメモリ ダンプに記録します。 ユーティリティは、チェックされたドライバーにさまざまな「 ストレステスト"、メモリ不足、I/O 制御、IRQL、デッドロック、DMA チェック、IRP などのさまざまな極限状態をシミュレートします。 実稼働システムではめったに発生しない状況がシミュレートされ、そこでのドライバーの動作が監視されます。 このユーティリティの目的は、ドライバーが BSOD によるシステムクラッシュを引き起こす可能性がある状況を特定することです。

Driver Verifier ユーティリティの実行可能ファイルは次のように呼ばれます。 検証者。EXEこれは %windir%\system32 ディレクトリにあります。 このユーティリティを使用するには、コマンド ラインから使用する方法と、グラフィカル インターフェイスを使用する方法の 2 つのオプションがあります。

Windows 8 でドライバー検証モードを有効にするには、次のように入力して Driver Verifier ユーティリティを起動します。

検証者

タスクリストから、 カスタム設定の作成 (コード開発者向け)そして押します 次.

オプションが選択されていることを確認してください 標準設定, 保留中の I/O リクエストを強制するそして IRP ロギング。 クリック 次.

次に を選択します。

「プロバイダー」列ヘッダーをクリックして表の内容を並べ替え、ドライバーのリストからテストするものを選択します。 この例では、によって開発されていないすべてのドライバーのチェックを実行します。 マイクロソフト株式会社。 ドライバーとして e1g6032e.sys (Intel) と lsi_sas.sys (LSI) を選択しました。

注記。 ドライバーに Microsoft デジタル署名が存在するということは、ドライバーが安定性について特定の方法でテストされており、その後コードが変更されていないことを示しています。 そのため、推奨または使用されません。

クリックするだけです 仕上げる変更を有効にするにはシステムを再起動する必要があることを示す情報ウィンドウが表示されます。

アドバイス。 ドライバー検証モードはコマンド ラインから有効にすることもできます。 たとえば、myPCDriver.sys ドライバーの標準設定で Driver Verifier を実行するには、コマンドは次のようになります。

検証者 /standard /driver myPCDriver.sys

再起動後、システムはドライバー検証モードで起動します。 Driver Verifier はバックグラウンドで動作し、選択したドライバーに対してさまざまな種類のテストを実行してエラーを特定します。 通常どおりコンピュータを使用し、BSOD が表示されるまで待ちます。 以前にどのような操作がシステムクラッシュの原因となったかがわかっている場合は、それを繰り返してください。 BSOD が発生した場合は、メモリ ダンプ ファイル (デフォルトでは C:\Windows\Minidump\*.dmp ディレクトリに保存されます) などをコピーする必要があります。

重要！ Driver Verifier を使用してドライバー デバッグ モードを有効にすると、このモードは強制的に無効になるまで機能します。

1 ～ 2 日以内に問題が再発しない場合は、テスト対象のドライバーがシステムクラッシュの原因ではないとある程度の確信を持って結論付けることができ、ドライバーのスキャン モードを無効にすることができます。

アドバイス。 Windows Driver Verifier を使用すると Windows の速度が大幅に低下するため、常にこのモードで実行することはお勧めできません。

コマンド ラインから Driver Verifier を無効にできます。

ベリファイア/リセット

または、グラフィカル インターフェイスから選択して、 既存の設定を削除する.

通常モードでシステムにログインできない場合は、セーフ モードからデバッグ モードを無効にすることができます。

システムがセーフ モードで起動しない場合は、ブート ディスクから起動して次のレジストリ キーを削除してみてください。

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel

次のようにして、Driver Verifier ユーティリティの現在のステータスを確認できます。


ハードウェア関連の DRIVER_VERIFIER_DETECTED_VIOLATION ブルー スクリーン エラーは、ランダム アクセス メモリ (RAM) の破損が原因で発生することがあります。 (BSOD 0xC4 エラーに加えて) コンピュータがランダムに再起動したり、起動ビープ音やその他のコンピュータの問題が発生した場合は、メモリが破損している可能性が高くなります。 実際、Windows OS でのアプリケーションのクラッシュのほぼ 10% はメモリ破損が原因です。

最近コンピュータに新しいメモリを追加した場合は、それが DRIVER_VERIFIER_DETECTED_VIOLATION エラーの原因になっていないことを確認するために、一時的にメモリを削除することをお勧めします。 この操作で BSOD が解決した場合は、これが問題の原因であるため、新しいメモリが一部のハードウェアと互換性がないか、破損しているかのいずれかです。 この場合、新しいメモリモジュールを交換する必要があります。

新しいメモリを追加しなかった場合、次のステップは、コンピュータの既存のメモリに対して診断テストを実行することです。 メモリ テストは、0xC4 ブルー スクリーン オブ デスの原因となる可能性のあるハード メモリ障害や断続的なエラーをスキャンします。

Windows の最近のバージョンには RAM テスト ユーティリティが含まれていますが、代わりに Memtest86 を使用することを強くお勧めします。 Memtest86 は、Windows 上で実行される他のテスト プログラムとは異なり、BIOS ベースのテスト ソフトウェアです。 このアプローチの利点は、このユーティリティを使用すると、すべてのオペレーティング メモリで DRIVER_VERIFIER_DETECTED_VIOLATION エラーがないかチェックできるのに対し、他のプログラムでは、プログラム自体、オペレーティング システム、および他の実行中のプログラムが占有するメモリ領域をチェックできないことです。



読むことをお勧めします