ハードウェアまたはソフトウェアの例外が発生すると、プロセッサは例外が発生した時点で実行を停止し、制御をシステムに転送します。 最初に、システムは、現在のスレッドのマシンの状態と、例外を記述する情報の両方を保存します。 その後、システムは例外を処理する例外ハンドラーを見つけようとします。
例外が発生したスレッドのマシンの状態は、CONTEXT 構造体に保存されます。 この情報 (コンテキスト レコードと呼ばれます) を使用すると、例外が正常に処理された場合に、システムは例外の時点で実行を続行できます。 例外の説明 (例外レコードと呼ばれます) は、EXCEPTION_RECORD 構造体に保存されます。 コンピューターに依存するコンテキスト レコードの情報は、例外レコードのコンピューターに依存しない情報とは別に格納されるため、例外処理メカニズムはさまざまなプラットフォームに移植できます。
コンテキスト レコードと例外レコードの両方の情報は、GetExceptionInformation 関数を使用して使用でき、例外の結果として実行されるすべての例外ハンドラーで使用できます。 例外レコードには、次の情報が含まれます。
- 例外の種類を識別する例外コード。
- 例外が継続可能かどうかを示すフラグ。 コンティニュアブルでない例外の後に実行を続行しようとすると、別の例外が生成されます。
- 別の例外レコードへのポインター。 これにより、入れ子になった例外が発生した場合に、リンクされた例外リストの作成が容易になります。
- 例外が発生したアドレス。
- 例外に関する追加情報を提供する引数の配列。
ユーザー モード コードで例外が発生すると、システムは次の検索順序を使用して例外ハンドラーを検索します。
- プロセスがデバッグ中の場合、システムはデバッガーに通知します。 詳細については、「デバッガーの例外処理 」を参照してください。
- プロセスがデバッグされていない場合、または関連付けられているデバッガーが例外を処理しない場合、システムは、例外が発生したスレッドのスタック フレームを検索して、フレーム ベースの例外ハンドラーの検索を試みます。 システムは、最初に現在のスタック フレームを検索し、その後、前のスタック フレームを逆の順序で検索します。
- フレーム ベースのハンドラーが見つからない場合、またはフレーム ベースのハンドラーが例外を処理していないが、プロセスがデバッグされている場合、システムはデバッガーに 2 回目の通知を行います。
- プロセスがデバッグされていない場合、または関連付けられているデバッガーが例外を処理しない場合、システムは例外の種類に基づいて既定の処理を提供します。 ほとんどの例外では、既定のアクションは、ExitProcess 関数を呼び出します。
カーネル モード コードで例外が発生すると、システムは、例外ハンドラーを見つけようとしてカーネル スタックのスタック フレームを検索します。 ハンドラーが見つからないか、ハンドラーが例外を処理しない場合、システムは、ExitWindows 関数が呼び出されたかのようにシャットダウンされます。