Windows ブルー スクリーン オブ デス (BSOD) は、特定のスクリーン セーバーまたはテスト ソフトウェアを使用していない限り、コンピューター モニターに表示したくないものです。しかし、時折、Windows ユーザーは最終的なソフトウェア障害、つまりカーネル自体の障害に遭遇し、システムが完全にフリーズし、最終的にクラッシュすることがあります。

Linux では、この種の状況はカーネル パニックとして知られています。 Windows では、BSOD と呼ばれます。しかし、それは同じことです。つまり、システムのコア、カーネル、および付随するドライバーにおける重大で回復不能な例外です。

マイクロイントロダクション

カーネル クラッシュ ダンプ ツールから始めて、openSUSE と CentOS でのセットアップを続行し、詳細な分析で最高潮に達する、Linux クラッシュに関する非常に長く非常にこっけいなシリーズを行った後、Windows ユーザーにやや短く、 BSOD分析のマニアックでないバージョン。これには 2 つの理由があります。 2 つ目は、私は Linux ほど Windows カーネルに手を出すのが得意ではありません。いずれにせよ、このチュートリアルは依然としてかなりオタク的であり、平均的なユーザーの要件、ニーズ、または欲求をはるかに超えています.ただし、Windows の内部構造についてもう少し学び、コア システムの問題を診断するのに役立つ新しいスキルを習得したい場合は、適切な場所に来ています。

それでは始めましょう。

目次

1. 質問
2. <オール>
3. ブルー スクリーン オブ デスが発生する原因は何ですか?

BSOD コレクションを有効にする

BSOD コレクション <オール>

ドライバー検証ツール

BSOD診断 <オール>

Windows シンボル パッケージ

BSOD 分析ツール 1:WhoCrashed

BSOD 分析ツール 2:Nirsoft

BSOD 分析ツール 3:Windows デバッガー (Windbg)

BSOD の例 <オール>

BSOD を開始します (StartBlueScreen を使用)

BSOD 分析 <オール>

WhoCrashed の結果

Nirsoft BlueScreenView の結果

Windows デバッガーの結果

オンラインで正しい記号を取得してください!

その他のデバッガ コマンドとオプション

次は？

分析のためにカーネル ダンプ情報を送信する

追加事項 <オール>

メモリ診断

参考文献 <オール>

オンライン記号の使い方

その他の役立つリソース

結論

質問

技術用語を掘り下げる前に、BSOD に関するいくつかの質問に答えましょう。

ブルー スクリーン オブ デスが発生する原因は何ですか?

簡単な答えはありません。長年の Windows ユーザーは、非常に頻繁に BSOD を経験する人もいれば、まったく見ない人もいれば、ほとんど同じ Windows を実行しているということを知っているでしょう。

幅広い経験は、通常、BSOD が Microsoft Windows コンポーネントによって引き起こされることは決してないという事実に由来しています。ほとんどの人はクラッシュの原因を Windows のせいにしたがりますが、オペレーティング システム自体が原因であることはめったにありません。

私の個人的な経験は次のとおりです:

合計稼働時間が 10 年の 2 台の Windows マシンで、BSOD に遭遇したのは 2 回だけで、各ホストで 1 回だけです。たまたま、2 つのクラッシュは 1 時間以内に発生しました。

これは、最近の Windows 更新プログラムまたは実行中のプログラムの 1 つが原因であると思われるかもしれません。確かに、特に 2 台のマシンのハードウェアとソフトウェアのセットアップがほぼ同じであることを考えると、これは良いリードのように思えます。しかし、これはソフトウェアのせいではありませんでした。

実際に起こったことは、グラフィック カードが過熱したことです。それと同じくらい簡単です。その日は非常に暑い日で、グラフィック カードは通常の温度範囲を超えていました。

私が他のマシンで遭遇したBSODの他のすべてのケースは、ワイヤレスカード、セキュリティプログラムなどを含む、ソフトウェアまたはハードウェアのいずれかによってインストールされた不良、誤動作、またはバグのあるドライバーに関連していました. Windows のコア コンポーネントの 1 つがきしむ音を見たことがありません。明確にするために、ここでは家庭での使用について話しています。

何について話しているのかがわかったので、科学的な話をしましょう。

BSOD コレクションを有効にする

組み込みのシステム ツールを有効に活用するには、Windows でミニダンプと呼ばれるクラッシュ ダンプを収集できるようにする必要があります。これは、Linux で LKCD または Kdump を有効にするのと似ています。デフォルトでは、Windows カーネル メモリ ダンプが有効になっているため、設定が正しいことを確認するだけで済みます。

エクスプローラー メニューの [コンピューター] を右クリックし、[プロパティ]、[システム]、[詳細設定]、[起動と回復] の順に選択して、BSOD コレクションを構成できます。下半分の [システム障害] の下で、パラメーターを構成する必要があります。

クラッシュをシステム ログに記録するか、システムを自動的に再起動するか、既存のファイルを上書きするかを選択できます。ファイルを上書きしないことをお勧めします。後で比較および分析するために情報を保持しておくことは、常に良いことです。

注意すべきもう 1 つの点は、[デバッグ情報を書き込む] ドロップダウン ボックスです。ここでは、マシンがクラッシュしたときに保存するメモリの部分を指定できます。これは、Kdump DUMPLEVEL と非常によく似ています。

次のオプションがあります:

小さなメモリ ダンプ - クラッシュ情報を含む基本的なファイルのみ。メモリにロードされた実行可能ファイルと DLL の痕跡がないため、これは限られた価値しかありません。 Windows XP では、このファイルのサイズは 64K です。 Windows 7 では 128K です。

カーネル メモリ ダンプ - カーネル クラッシュはカーネル バグまたはドライバーのいずれかによって引き起こされるため、ほとんどの場合、カーネルのみを含むメモリの一部をダンプします。

完全なメモリ ダンプ - RAM の内容全体をダンプします。

設定に満足したら、[OK] をクリックします。これで分析を開始できます。

BSOD コレクション

多くの場合、クラッシュの根本原因を見つけることは容易ではありません。ハードウェアの問題は、問題を特定することなく、さまざまな症状として現れる可能性がある、不規則で予期しない動作を引き起こす可能性があり、また発生する可能性があります。ソフトウェアの問題は、診断が容易でなければなりません。

BSOD が発生した場合、最初のタスクは、問題のあるコンポーネントを分離し、BSOD を再びトリガーするようにすることです。問題を再現できれば、問題を解決することができます。

ドライバー検証ツール

BSOD のトラブルシューティングを行う場合は、Driver Verifier を使用する必要があります。

Driver Verifier は強力なツールであり、他のコンポーネントとメモリを共有せずに分離されたメモリ プールでドライバーを実行したり、極度のメモリ負荷を提供したり、パラメーターを検証したり、チェックをアンロードしたりするなど、多くのことを行うことができます。

Verifier の使用を開始するには、実行可能ファイルを見つけて開始します。 Windows XP では、[スタート]> [ファイル名を指定して実行]> [Verifier] をクリックします。 Windows 7 では、インライン検索ボックスに Verifier と入力し、Enter キーを押します。

Verifier を起動したら、設定する必要があります。ほとんどの人に役立つ標準設定を作成するか、主にコード開発者に役立つカスタム設定を構成できます。タスクを表示したり、タスクを削除したり、現在検証済みのドライバーの情報を表示したりすることもできます。

次のメニュー画面で、チェックするドライバーを選択する必要があります:署名されていないドライバー、古いバージョンの Windows 用にビルドされたドライバー、またはすべてのドライバー。何が問題なのかまだわからないので、すべて選択してください。

次のステップは再起動です。 Verifier は大量の CPU を消費し、マシンの速度を大幅に低下させます。また、追加のクラッシュが発生する可能性があります。 Verifier は、最終的にデスクトップに到達するまで、BSOD と再起動の間で障害のあるドライバーを無効にします。また、少数のミニダンプを収集している可能性もあります。

Verifier を無効にできるようになりました。アプリケーションを起動し、既存の設定を削除します。

さらに、Verifier が原因でマシンをデスクトップで起動できない場合は、前回正常起​​動時の構成を起動するか、セーフ モードで起動することにより、ツールを無効にすることができます。

OK、ミニダンプが収集されました。分析しましょう。

BSOD 診断

ミニダンプを診断するには、いくつかのツールが必要です。 Linux のチュートリアルを思い出すと、crash を使用するための前提条件は、カーネルをデバッグ シンボルでコンパイルし、debuginfo パッケージをインストールすることでした。

Windows シンボル パッケージ

まあ、Windowsも例外ではありません。適切な分析を行うには、記号が必要です。 Windows カーネルのバージョンと正確に一致するシンボルをダウンロードしてインストールする必要があります。そうしないと、分析が正確になりません。繰り返しますが、この点では Linux と同じです。

これについては後で例を示します。

シンボルをインストールしたら、クラッシュ データを読み取って解釈するためのツールが必要になります。そのようなツールを 3 つ紹介します。まず、最も簡単でゆっくりとオタクの丘を登っていきます。

BSOD 分析ツール 1:WhoCrashed

WhoCrashed は、マシン クラッシュの原因となったドライバーを特定できるシンプルで効果的なツールです。使い方は非常に簡単で、専門知識は必要ありませんが、適切な分析が必要です。このツールを使用するには、Windows Debugger をインストールする必要があります。

BSOD 分析ツール 2:Nirsoft

Windows について少しでも真剣に考えているなら、Nir Softer ツールについて聞いたことがあるはずです。これは、Nir Sofer によって開発および管理されている非常に多用途な Windows ユーティリティのコレクションです。特に、Windows カーネル メモリ ダンプの分析に使用される BlueScreenView という診断ツールが必要です。何よりも、この便利な小さなツールは、Nir によって開発された 100 以上のアプリケーションのコレクションである Nirlauncher と呼ばれる超強力なスイス アーミー ナイフ スタイルのツールボックスに含まれています。 Nir の Web サイトが私の Greatest リストに掲載されているのには理由があります。

さらに、Nir Sofer には BSOD を開始するためのツールもあるため、クラッシュをシミュレートできます。このツールは StartBlueScreen と呼ばれ、Nirlauncher パッケージに含まれています。 Nirlauncher の詳細については、私のソフトウェアのレビューをお読みください。

これら両方のプログラムについては、すぐに説明します。

BSOD 分析ツール 3:Windows デバッガー (Windbg)

Windows デバッガーは、Windows システム上のドライバー、アプリケーション、サービスなど、あらゆる種類のもののトラブルシューティングに使用できる多目的ツールです。

Windows デバッガーは、Windows SDK に含まれています。

Windows 7 でデバッガーをインストールすると、.NET Framework 4 エラーが発生する場合があります。 .NET フレームワークで開発されたアプリケーションを使用しない限り、これは無視できます。私たちの場合、安全に進めることができます。

インストール メニューで、必要なコンポーネントを選択できます。 Common Utilities の下にある Debugging Tools for Windows が必要です。

Windows デバッガーは、起動するとあまり面白くありませんが、慣れて適切に操作するにはかなりの時間がかかる強力なツールです。ソースの調査、実行中のプロセスへのアタッチ、カーネル ダンプの調査などに使用できるため、Linux の GDB に似ています。

BSOD の例

BSOD を開始します (StartBlueScreen を使用)

これらのツールの動作を確認するには、BSOD が必要です。 Windows 7 マシンで Verifier を実行しても悪影響はありませんでした。そのため、前述の NirSoft StartBlueScreen ツールを試す必要があります。

StartBlueScreen はコマンド ライン ツールです。いくつかのパラメーターを指定して実行する必要があるため、BSOD がトリガーされます。 BSOD を実行するには、Windows ボックスで管理者アカウントを使用する必要があります。

Windows 7 では、非表示の管理者アカウントを有効にするのは少し難しいかもしれませんが、すぐに別のチュートリアルを用意する予定です。実際、Windows XP で同じことを行うのも簡単ではありません。繰り返しますが、これについては個別に説明します。

管理者としてログインしたら、コマンド ラインから StartBlueScreen を実行します。 Nir Sofer は彼の Web サイトに多くの例を挙げているので、そのうちの 1 つを使用します:

StartBlueScreen.exe 0x12 0 0 0 0

これは、システム リクエストを有効にして Linux で echo c> /proc/sysrq-trigger を実行する場合とよく似ています。実際、数秒後、悪名高い BSOD が表示されるはずです:

マシンにダンプを完了させます。発生したら、クラッシュを分析できます。マシンの再起動後に、メッセージ ポップアップが表示される場合があります。何が起こったのかについてはすでにヒントがあり、詳細は近日中に公開されます。

BSOD 分析

3 つのツールのそれぞれが提供するものを見てみましょう。

WhoCrashed の結果

何が起こったのかを非常に簡単にドリルダウンできます。ほとんどの人にとって、この情報は開始するのに十分です。問題のあるドライバーの名前を知っていると、問題を特定するのに役立ちます。

このエラーは、nirsoftbluescreendriver.sys ドライバーによって引き起こされた不明なカーネル トラップであることがわかります。まあ、これは想定内です。 Nir のコードは、私の null-pointer カーネル ドライバーの例に似ていると思います。

Nirsoft BlueScreenView の結果

BlueScreenView は、より詳細な情報を提供します。ルート フォルダーにあるミニダンプ ファイルを自動的に読み込みます。上部のビューには、Linux クラッシュ分析ファイルのパニック文字列と同じバグ チェック文字列や、カーネル ページ エラーに似たバグ チェック コードなど、クラッシュに関するいくつかの基本情報が表示されます。

一番下のペインには、メモリにロードされたすべてのドライバーのリストがあり、クラッシュに関連するものはサーモンでマークされています。これは色の名前だと思います。クラッシュ プロセスの呼び出しトレースのみを表示する場合は、[オプション] メニューでフィルターを変更できます。

元の BSOD 画面 (XP スタイル) をロードすることもできます:

これは便利な場合があります。たとえば、技術情報のセクションを見てください。不良ドライバーの名前とメモリ アドレスがわかりました。もう一度 Linux で例えると、これはタスク バックトレースの例外 RIP のようなものです。実際、スタックに注目しましょう:

実行可能ファイルの名前とメモリアドレスがあります。理論的には、ソースがあれば、カーネル クラッシュを引き起こしたコード内の正確な行を特定できます。私たちはそうしていないので、できる限り多くのデータを収集し、さらに分析するために Microsoft に情報を送信することをお勧めします。それについてはすぐに話しましょう。

一般に、Microsoft は Microsoft コンポーネントのクラッシュに対するパッチを発行します。そのため、問題は、nkrnlpa.exe が Microsoft コンポーネントであるかどうかをどのように判断するかということです。いずれかのエントリをダブルクリックするか、右クリックしてプロパティを選択すると、詳細情報が表示されます。

ご覧のとおり、Windows のクラッシュに対処することは、Linux に対処することとそれほど違いはありません。ただし、何が起こったのかを正確に知りたい場合は、情報源が必要になります。情報源は、常にすぐに利用できるとは限りません。繰り返しになりますが、これは Linux でも常に可能であるとは限りません。特に、Nvidia などの独自のドライバーがカーネルにロードされている場合はそうです。ファイルのバージョンに注意してください。これは、シンボルを使用する場合に重要です。これはすぐに動作します。

Windows デバッガーの結果

Windows Debugger は、前述の 3 つのツールの中で最も複雑で強力です。始める前に、デバッガーの操作には時間、忍耐、および知識が必要であることを認識しておく必要があります。実際、私は勇敢にも関わらず、このツールにはかなりの経験がありませんが、クラッシュ分析に関する常識と普遍的な知識はここでも十分に当てはまります。あるシステムのあいまいなコードの道筋をビジネスで知っていれば、他のすべてのシステムでもうまくいくでしょう。

権限

管理者として作業していない場合は、明らかにセキュリティ上の理由から、メモリ ダンプにアクセスする権限がありません。ファイルをコピーするか、正しい権限を設定する必要がある場合があります。

シンボルを読み込む

最初に行う必要があるのは、シンボルのロードです。パスが環境変数に格納されていない可能性があるため、ツールはディスクのシンボルの場所を認識しない場合があります。強調するために、シンボルを指定せずにクラッシュ ダンプを読み込みます。

エラー文字列に注意してください:ERROR:モジュールのロードが完了しましたが ... これは、シンボルがロードされていない場合に発生するものであり、分析が無駄になります。実際、分析を実行すると、クラッシュ時にドライバーがメモリ内でどのようにマップされたかをデバッガーが推測できないため、いくつかの疑問符が表示されます。

.sympath コマンドを実行すると、現在のシンボル パスを確認できます。シンボルをロードしていない限り、空になります。シンボルをロードします。

シンボルを読み込んだ後、ミニダンプ ファイルを再度開く必要はありません。リロードするだけです。これを行うには、Symbol Search Path ウィンドウの Reload ボックスをオンにするか、コマンド ウィンドウの下部にある kd> でマークされたデバッガ コマンド ラインで .reload を実行します。

別の出力が表示されます:

分析の実行

実行中の分析は、!analyze -v コマンドを実行することによって行われます。 -v フラグは詳細を表します。

!分析 -v

クラッシュ引数の詳細な文字列を含む、より多くの情報が表示されるようになりました。ほとんどの人にとって、これは基本的なニーズをはるかに超えていますが、システムを制御し、問題を解決し、さらには Microsoft がコア バグを修正するのを支援することに真剣に取り組んでいる場合は、数分かけて分析を実行し、クラッシュ レポートを送信します。 、 もし可能なら。

シンボルがカーネルと一致しません!

さて、これはあなたが注意を払うべきことです。間違ったシンボルをロードすると、クラッシュに関する情報が間違ったものになります。実際、カーネルのバージョンより古いか新しいシンボルをダウンロードした場合、問題が発生します。

これは Linux の例に似ており、カーネルの更新後に openSUSE 11.2 のリポジトリで利用可能な debuginfo パッケージがありません。実際、私はこの問題に遭遇しました。シンボルのインストールに戻りましょう:

シンボルはカーネル 7600.16385 のもので、私が間違っていなければ RTM です。タイムスタンプと正確なリビジョン - 090713-1255 に注意してください。一方、Windows 7 は新しいカーネルを実行しており、さらに多くの更新が行われているため、カーネルのバージョンにも影響が及ぶ可能性があります。

バージョンは 7600.16481 です。二人は合わない！このようなケースに遭遇し、カーネル シンボルの最新バージョンをダウンロードできない場合は、Microsoft にサポートを依頼してください。ほとんどの場合、サードパーティ ドライバーのシンボルはありません。サードパーティのベンダーに連絡することもできます。

オンラインで正しいシンボルを取得してください!

さて、Windows に関しては、オペレーティング システムの最新のシンボルを取得するために必要なことは次のとおりです。 Windows Debugger でクラッシュ ダンプを読み込んだ後、Symbol Search Path ウィンドウを再度開きます。ローカル パスに加えて、デバッガー内からのみアクセスできるオンライン シンボル リポジトリを指定します。詳細については、この Microsoft KB 記事を参照してください。

具体的には、次のものが必要です:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

c:\symbols をマシンの正しいシンボル パスに置き換えます。 Symbol Search Path を使用してパスを入力する必要はありません。 .sympath コマンドを使用して、コマンド ラインで指定することもできます。他のデバッガー コマンドとオプションについては、すぐに説明します。そして、もう一度分析を実行しましょう。もちろん、Nirsoft ドライバーのシンボルはありません。

より楽しくするために、コール スタックを次に示します (これについてはすぐに詳しく説明します):

そして、私たちは元気です！

その他のデバッガ コマンドとオプション

幸いなことに、Windows デバッガーには非常に豊富で詳細なヘルプが用意されており、この種のものが好きであれば、すぐに使用できるようになるはずです。また、Linux のクラッシュ解析に精通している場合は、ほとんどの内容に精通しています。

たとえば、非常に便利なコマンドは lm (モジュールの一覧表示) です。 lml を実行してモジュールの短いリストを取得するか、lmv を実行して完全で詳細なリストを取得できます。 u フラグを使用してユーザーランド モジュールをリストしたり、k フラグを使用してカーネル モジュールをリストしたりすることもできます。

以下は lvm の例です:

以下は lml の例です。 Windows カーネルはこれらのシンボルを使用してコンパイルされておらず、使用できないため、一部のドライバー、つまりサードパーティ製のドライバーにはシンボルがないことに注意してください。ベンダーから入手することができます。

[表示] メニューにはいくつかのコマンドが組み込まれているため、コマンド ラインでコマンドを探す必要はありません。少し前に見た、Watch、Locals、Registers、Memory、Call Stack などがあります。

たとえば、プロセスとスレッドを表示したい場合があります。

または登録:

使用したい他のコマンドには、!memusage と !address があります。今見たコマンドとオプションの組み合わせは、bt、ps、およびクラッシュ ユーティリティで使用されるその他のコマンドと非常によく似ています。全体的な考え方は同じです。

分解

ソースがなくても、バイナリ コードを逆アセンブルして見たいと思うかもしれません。コードで何が起こっているのか完全には理解できないかもしれませんが、何が問題なのかを示すことができます。

分解オプションや他の多くのオプションがメニューで利用できます。

それではどうぞ:

また、さまざまなウィンドウをメイン インターフェイスに埋め込むことができます。

これは、Windows Debugger でできることの氷山にほとんど触れていませんが、ほとんどの人にとってはこれで十分だと思います。

次は？

問題の原因を突き止めた場合は、いくつかのことを試すことができます:

悪いドライバをアンインストールまたは無効にする

重要な機能が失われる可能性があるため、これが違いを生むかどうか、つまりできるかどうかを確認してください。問題が解決しない場合は、ハードウェアに関連する複雑な問題が発生している可能性があります。

ドライバを更新してみてください

これはうまくいくかもしれません。ベンダー サイトまたは Microsoft の更新プログラムにアクセスして、ハードウェアとソフトウェアの最新のドライバーを入手してください。データをバックアップし、システムのイメージを作成することを忘れないでください。これにより、ベースラインを確保できます。

Google で情報を検索

常に賢明な動き。ドライバーの名前またはバグ チェック文字列を検索すると、問題の回避策などの有用な情報が得られる場合があります。一般に、誰かがあなたの問題に似たものを見たり、聞いたり、経験したりしているはずです。

いつものように、慎重かつ慎重にデータを除外してください。提案された解決策のいくつかを試してみることにした場合は、データが安全であり、適切な既知の構成にロールバックできることを確認してください。

その他

有用なクラッシュ情報がある場合は、分析のために開発者に送信してみてください。これは、Microsoft または Microsoft Windows 用のハードウェアまたはソフトウェア ドライバーを開発しているサード パーティである可能性があります。下記参照。

分析のためにカーネル ダンプ情報を送信する

ここには固いものは何もありません。提案がある場合は、送信してください。 Microsoft のリンクをいくつか試してみましたが、カジュアルなユーザーには限界があるようです。

最も関連性の高いページは oca.microsoft.com ですが、サーバー側のエラーが発生しているようです。私を修正したり、フィードバックやリンクを送信したりしてください。

注:クラッシュ ダンプの送信はデリケートな問題です。メモリ ダンプには、パスワードや、クラッシュ時にメモリにロードされたその他の情報など、個人情報が含まれている可能性があります。クラッシュ データをアップロードまたは郵送する前に、この点に注意してください。

追加事項

メモリ診断

断続的なハードウェアの問題に直面している場合は、マシンでメモリ テストを実行することをお勧めします。最も人気のあるオープンソース ツールは Memtest86+ です。このツールはスタンドアロン ISO として使用できます。また、大多数の Linux ディストリビューションに同梱されており、すべてライブ CD として起動できます。

Windows メモリ診断を使用することもできます。

さらに、Linux クラッシュに記載されている一般的なアドバイスもここに当てはまります。

そして、それですべてです、紳士！

参考文献

ドライバー検証ツール

Windows シンボル パッケージ

Windows 用のデバッグ ツール

Windows SDK

誰がクラッシュした

Nirsoft ウェブサイト

Nirsoft Nirlauncher (私のレビュー)

Nirsoft BlueScreenView

Nirsoft StartBlueScreen

Windows メモリ診断

Memtest86+

オンライン シンボルの使い方

Windows Debugger 内からライブでオンライン サーバーからシンボルを取得:

Microsoft Symbols Server を使用してデバッグ シンボル ファイルを取得する

その他の役立つリソース

カーネル メモリ ダンプ分析に関する Microsoft の記事:

レジストリの調整、システム リクエスト (SysRq) でのキーボードの使用、Windows デバッガーのコマンド ラインの使用、バッチ (スクリプト) の使用など、役立つ記事があります。

メモリ ダンプ ファイル オプションの概要

キーボード ダンプ トリガー

Mark Russinovich (Sysinternals、現在は Wininternals) による素晴らしい記事:

クラッシュした電話のケース

また、Windows Debugger に組み込まれているヘルプも忘れないでください。とても丁寧で詳しいです。最後になりましたが、すべての状況で無料の親友であるインターネット検索エンジンに戻ります。

結論

うわー、それは長かった - そして私が予想していたよりもはるかにマニアックだった.どうやら、カーネル関連のものを扱っているときは、超オタクから逃れることはできないようです。それでも、この記事を楽しんでいただければ幸いです。

カーネル メモリ ダンプのセットアップ、ドライバーの検証、カーネル クラッシュを調べるための 3 つのツール、WhoCrashed のような非常にシンプルなツールから強力な Windows Debugger まで、さまざまな機能があります。また、Nirsoft ツールを使用して、BSOD のトリガーと分析の両方を行いました。マシンにシンボルがインストールされていることを確認しました。 Windows デバッガーが提供するものをより深く調べ、いくつかのコマンドとオプションをカバーしました。最後に、いくつかの一般的なヒントと豊富なリンクがあります。

これほど親しみやすい記事は多くないと思います。特に、Windows ユーザーの利益と喜びのために Linux の専門家が書いた記事はそうではありません。そして、そこに秘密があります。構文は異なりますが、基本原則は同じです。 Linux または Windows のカーネル クラッシュ解析のコツをつかめば、もう一方を使用する作業がはるかに快適になります。そして、それがすべてです。私は過ごしました。またね！

乾杯。