ESP レジスタのシングルビット エラーが原因で停止 7F、0x00000008 (ダブル フォールト) エラーが発生する


概要


このドキュメントでは、特定のプロセッサ エラーが原因で、コンピュータに "STOP 0x0000007F,0x00000008" エラー メッセージが表示される理由について説明します。 このエラー メッセージは、コンピュータで実行されているプロセッサの ESP レジスタでシングルビット エラーが発生した場合に表示されることがあります。 この資料では、このエラーのトラブルシューティングに役立つ方法について説明します。

現象


1 つ以上の Intel Xeon プロセッサを実行しているコンピュータ、または他のプロセッサを実行しているコンピュータでは、次のような Stop エラー メッセージが表示されることがあります。

STOP 0x0000007F (0x00000008, 0x00000000, 0x00000000, 0x00000000) UNEXPECTED_KERNEL_MODE_TRAP


この問題が発生するのは、以下の条件に該当する場合です。
  • Stop エラーの最初のパラメータは "0x0000008" です。 (このエラーは二重フォールト例外です)
  • ESP レジスタの上半分にシングルビット エラーがあるため、ESP レジスタの値は現在のスレッドのスタック範囲外です。

原因


この問題は、次のいずれかまたは複数の条件に該当する場合に発生します。
  • コンピュータの基本入出力システム (BIOS) で適用されないマイクロコード更新が必要です。

  • 破損または欠陥がある。
  • 温度、電力、またはその他の条件のために、指定された範囲外で動作しています。

解決方法


この問題を解決するには、以下のいずれかのトラブルシューティングの方法を使用します。

方法 1: プロセッサがマイクロコード更新の生産リビジョンを実行しているかどうかを確認する

マイクロコード更新プログラムは、プロセッサの内部的に実装されたロジックのエラータ (バグ) を修正します。 マイクロコードの更新は、プロセッサ自体に永続的に格納することはできず、コンピューターが起動するたびにプロセッサに読み込む必要があります。 マイクロコードの更新プログラムは、コンピューターの BIOS または Update.sys ドライバーによって適用できます。

コンピューターにインストールされている Intel プロセッサに現在適用されているマイクロコード更新プログラムのリビジョンを確認するには、次の手順を実行します。
  1. 次の Intel Web サイトから Intel Processor Frequency ID Utility をダウンロードします。
  2. 現象が発生しているコンピューターにインテル プロセッサ周波数 ID ユーティリティをインストールして実行します。

  3. 各プロセッサの次の CPU 情報を書き留めます。
    • CPU ファミリ
    • CPU モデル
    • CPU ステッピング
    • CPU リビジョン
    CPU ファミリ、CPU モデル、および CPU ステッピングの値は、特定の種類のプロセッサを識別します。 CPU リビジョン値は、適用されるマイクロコード更新のリビジョンを識別します。
  4. マイクロコード更新プログラムの改訂が、特定のプロセッサで利用可能な最新の改訂であるかどうかを確認するには、コンピュータの製造元に問い合わせてください。 改訂が最新版でない場合は、最新のマイクロコード更新プログラムの改訂を適用する更新された BIOS をコンピューターの製造元に問い合わせてください。
この資料に記載されている現象は、CPU ファミリ、CPU モデル、および CPU ステッピング値がそれぞれ 15、2 および 9 で、ServerWorks チップセットを使用するマザーボードにインストールされている Intel Xeon プロセッサで最も頻繁に発生しています。 (CPU ファミリ、CPU モデル、および CPU ステッピングの 16 進値は、それぞれ F、2 および 9 です。 これらのプロセッサが正しく機能するには、0x18 以降の改訂値が必要です。 (0x18 は 10 進値 24 に相当します。)

リビジョン値 0 は、コンピューター BIOS に、コンピューターにインストールされているプロセッサの正しいマイクロコード更新プログラムがインストールされていないことを示します。 使用しているプロセッサをサポートするマイクロコード更新リビジョンを使用して BIOS を更新する必要があります。



インテルでは、既知の問題を回避するために、最新のマイクロコード更新リビジョンを適用することをお勧めします。

方法 2: プロセッサが破損しているか、欠陥があるかを確認する

影響を受けるコンピューターにインストールされているプロセッサに本番マイクロコードの更新リビジョンが適用されており、この資料に記載されている現象が、同じプロセッサを実行している同じモデルのすべてのコンピューターで発生しない場合、プロセッサに欠陥がある可能性があります。


プロセッサが破損しているか、欠陥があるかどうかを確認するには、現象が発生していないコンピューターにプロセッサを移動します。


警告 プロセッサを変更する場合は、コンピューターの製造元から提供された指示に従うか、適切な資格を持つハードウェア技術者に連絡してプロセッサを変更してください。


交換用プロセッサを搭載した元のコンピューターで引き続き現象が発生するが、元のプロセッサを搭載した他のコンピューターでは発生しない場合は、プロセッサの破損または不良が原因ではない可能性があります。

交換用プロセッサを搭載した元のコンピューターで現象が引き続き発生するが、元のプロセッサを搭載した他のコンピューターで発生する場合は、プロセッサの破損または不良が原因である可能性があります。 この場合は、コンピューターの製造元に問い合わせて、元のプロセッサを交換してください。

この資料に記載されている現象が発生しているコンピューターに複数のプロセッサがある場合は、すべてのプロセッサを他のコンピューターに移動します。 結果から、これらのプロセッサの 1 つ以上に欠陥がある可能性がある場合は、プロセッサを 1 つずつ移動して、欠陥のあるプロセッサを特定します。

方法 3: プロセッサが指定された環境条件の範囲外で動作しているかどうかを確認する

過度の室温、換気不良、またはほこりの蓄積により、プロセッサなどの電子部品が不規則に動作する可能性があります。 ファンの故障や空気の通路の遮断は、換気の問題を引き起こす可能性があります。 コンピュータの内部または空気の通路がほこりっぽい場合、またはコンピュータが特定の場所にのみ設置されている場合に症状が現れると、システムの過熱が要因となる可能性があります。 コンポーネントが清潔で、ファンが正しく機能していること、および空気の通路が妨げられていないことを確認します。 さらに、コンピュータが配置されている部屋が十分に換気されていることを確認します。 部屋の温度は、コンピュータの製造元が指定した動作範囲内である必要があります。


電圧が指定よりも高いか低いか、または変動する電圧が原因で、プロセッサやその他の電子部品が不規則に動作する可能性があります。 主電源電圧が正しくないか、一貫性がないか、コンピュータの電源が過負荷または不適切に機能しているか、マザーボード回路が正しく機能していない場合、プロセッサに正しくない電圧や一貫性のない電圧が供給される可能性があります。 適切な技術者に問い合わせて、これらの問題のいずれかが症状の原因であるかどうかを確認します。

ベンダーに問い合わる方法の詳細については、次のマイクロソフト ウェブサイトを参照してください。

詳細情報


"STOP 0x0000007F" エラーの詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を参照してください。

137539 "STOP 0x0000007F" エラーの一般的な原因

ESP レジスタは、スタック ポインタ レジスタとも呼ばれます。 スタックは、スレッドの実行の現在の状態に関する情報を格納するために使用されるメモリ内のデータ構造です。 スレッドのスタックは、進行中の関数呼び出し、それらの関数に渡されるパラメーター、およびそれらの関数によって使用される変数を追跡するために使用されます。 ESP レジスタの値は、スタックの現在の最上位を指す必要があります。 ESP の値が正しくない場合は、誤った情報または無効なアドレスを指している可能性があります。 ESP の値が無効なアドレスを指している場合、二重フォールト例外が発生する可能性があります。

Stop エラーが ESP レジスタのシングルビット エラーの結果であるかどうかを確認するには、次の手順を実行します。
  1. Microsoft Debugging Tools for Windows をインストールする このツールをダウンロードするには、以下のマイクロソフト ウェブサイトにアクセスしてください。

  2. WinDbg ツールを実行し、[ファイル]をクリックし、 [クラッシュ ダンプを開ける] をクリックし、 Stop エラー情報を含むメモリ ダンプ ファイルを検索し、 [OK] をクリックします。

    通常、最初のバグチェック分析は次のようになります。
    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 7F, {8, 0, 0, 0}

    Probably caused by : ntkrnlmp.exe ( nt!KiUnlockDispatcherDatabase+1c )

    Followup: MachineOwner
  3. !analyze -v コマンドを実行して、ダンプ ファイルの自動分析を取得します。 !analyze -v のコマンドの出力例は次のとおりです。


    0: kd> !analyze -v
    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************

    UNEXPECTED_KERNEL_MODE_TRAP (7f)
    This means a trap occurred in kernel mode, and it is a trap of a kind
    that the kernel isn't permitted to have/catch (bound trap) or that
    is always instant death (double fault). The first number in the
    bugcheck params is the number of the trap (8 = double fault, etc)
    Consult an Intel x86 family manual to learn more about what these
    traps are. Here is a *portion* of those codes:
    If kv shows a taskGate
    use .tss on the part before the colon, then kv.
    Else if kv shows a trapframe
    use .trap on that value
    Else
    .trap on the appropriate frame will show where the trap was taken
    (on x86, this will be the ebp that goes with the procedure KiTrap)
    Endif
    kb will then show the corrected stack.
    Arguments:
    Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
    Arg2: 00000000
    Arg3: 00000000
    Arg4: 00000000

    Debugging Details:
    ------------------


    BUGCHECK_STR: 0x7f_8

    TSS: 00000028 -- (.tss 28)
    eax=ffdff4dc ebx=f5d299dc ecx=8046f1c0 edx=00000000 esi=853e7a60 edi=00000102
    eip=8046a86c esp=f5da9948 ebp=f5d2997c iopl=0 nv up ei pl zr na po nc
    cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
    nt!KiUnlockDispatcherDatabase+0x1c:
    8046a86c 59 pop ecx
    Resetting default scope

    DEFAULT_BUCKET_ID: DRIVER_FAULT

    LAST_CONTROL_TRANSFER: from 80450bb3 to 8046a86c

    STACK_TEXT:
    f5d2997c 80450bb3 00000003 f5d299f8 00000001 nt!KiUnlockDispatcherDatabase+0x1c
    f5d29d48 80466389 00000003 0076fe84 00000001 nt!NtWaitForMultipleObjects+0x385
    f5d29d48 77f9323e 00000003 0076fe84 00000001 nt!KiSystemService+0xc9
    0076fe5c 77e7a059 00000003 0076fe84 00000001 ntdll!ZwWaitForMultipleObjects+0xb
    0076feac 77dee9fb 0076fe84 00000001 00000000 KERNEL32!WaitForMultipleObjectsEx+0xea
    0076ff08 77deea48 0076fed4 0076ff5c 00000000 USER32!MsgWaitForMultipleObjectsEx+0x153
    0076ff24 6d095a7c 00000002 0076ff5c 00000000 USER32!MsgWaitForMultipleObjects+0x1d
    0076ff7c 780085bc 00283a90 0062f5ac 0062ffdc IisRTL!SchedulerWorkerThread+0xa7
    0076ff90 8042fa31 85400680 0076ff88 ffffffff MSVCRT!_endthreadex+0xc1
    00283ab8 ffffffff 00000000 00000000 00000000 nt!KiDeliverApc+0x1a1
    00283ab8 ffffffff 00000000 00000000 00000000 0xffffffff
    0000096c 00000000 00000000 00000000 00000000 0xffffffff


    FOLLOWUP_IP:
    nt!KiUnlockDispatcherDatabase+1c
    8046a86c 59 pop ecx

    SYMBOL_STACK_INDEX: 0

    FOLLOWUP_NAME: MachineOwner

    SYMBOL_NAME: nt!KiUnlockDispatcherDatabase+1c

    MODULE_NAME: nt

    IMAGE_NAME: ntkrnlmp.exe

    DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650b3

    STACK_COMMAND: .tss 28 ; kb

    BUCKET_ID: 0x7f_8_nt!KiUnlockDispatcherDatabase+1c

    Followup: MachineOwner
  4. !analyze -v コマンドの出力を調べて、出力に二重障害状態が示されているかどうかを確認します。 二重障害状態が存在する場合は、.tss 28 コマンドを実行して、ダブル フォールト時のシステム状態を表示します。 たとえば、次の出力は、二重フォールト例外が発生した時点のプロセッサのレジスタの値を示しています。
    0: kd> .tss 28
    eax=ffdff4dc ebx=f5d299dc ecx=8046f1c0 edx=00000000 esi=853e7a60 edi=00000102
    eip=8046a86c esp=f5da9948 ebp=f5d2997c iopl=0 nv up ei pl zr na po nc
    cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
    nt!KiUnlockDispatcherDatabase+0x1c:
    8046a86c 59 pop ecx


    前の例では、ESP レジスタの値は f5da9948 です。 一般に、この値は EBP レジスタの値に比較的近いです。 前の例では、EBP レジスタの値は f5d2997c です。

  5. !thread コマンドを実行して、現在のスレッドのスタック範囲を表示します。 二重フォールト例外は通常、ESP レジスタの値が現在のスレッドのスタック用に予約されているアドレスの範囲外にある場合に発生します。 !thread コマンドの出力例は次のとおりです。


    0: kd> !thread
    THREAD 853e7a60 Cid 904.96c Teb: 7ffdc000 Win32Thread: a21a5c48 RUNNING
    Not impersonating
    Owning Process 85400680
    Wait Start TickCount 578275 Elapsed Ticks: 0
    Context Switch Count 38423 LargeStack
    UserTime 0:00:02.0031
    KernelTime 0:00:06.0640
    Start Address KERNEL32!BaseThreadStartThunk (0x77e5b700)
    Win32 Start Address MSVCRT!_threadstartex (0x78008532)
    Stack Init f5d2a000 Current f5d29c9c Base f5d2a000 Limit f5d27000 Call 0
    Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0

    ChildEBP RetAddr Args to Child
    00000000 8046a86c 00000000 00000000 00000000 nt!_KiTrap08+0x41
    f5d2997c 80450bb3 00000003 f5d299f8 00000001 nt!KiUnlockDispatcherDatabase+0x1c
    f5d29d48 80466389 00000003 0076fe84 00000001 nt!NtWaitForMultipleObjects+0x385
    f5d29d48 77f9323e 00000003 0076fe84 00000001 nt!_KiSystemService+0xc9
    0076fe5c 77e7a059 00000003 0076fe84 00000001 ntdll!ZwWaitForMultipleObjects+0xb
    0076feac 77dee9fb 0076fe84 00000001 00000000 KERNEL32!WaitForMultipleObjectsEx+0xea
    0076ff08 77deea48 0076fed4 0076ff5c 00000000 USER32!MsgWaitForMultipleObjectsEx+0x153
    0076ff24 6d095a7c 00000002 0076ff5c 00000000 USER32!MsgWaitForMultipleObjects+0x1d
    0076ff7c 780085bc 00283a90 0062f5ac 0062ffdc IisRTL!SchedulerWorkerThread+0xa7
    0076ffb4 77e5b382 00283ab8 0062f5ac 0062ffdc MSVCRT!_threadstartex+0x8f
    0076ffec 00000000 78008532 00283ab8 00000000 KERNEL32!BaseThreadStart+0x52


    前の出力では、次の情報がスタック範囲の値を示しています。

    Stack Init f5d2a000 Current f5d29c9c Base f5d2a000 Limit f5d27000 Call 0
    この特定のスレッドが実行されている場合、ESP レジスタ値は常にスタック ベース値 (f5d2a000) と制限値 (f5d27000) の間である必要があります。 一般に、ESP レジスタの値は電流値 (f5d29c9c) に比較的近いです。 (現在の値は、スタックベース値と限界値の間でもあります。) 前の例では、ESP レジスタの値は f5da9948 です。 この値は、必要な範囲外です。



    !pcr コマンドを実行して、スタック範囲の値を確認することもできます。 !pcr コマンドの出力例は次のとおりです。
    0: kd> !pcr
    PCR Processor 0 @ffdff000
    NtTib.ExceptionList: f5d29d38
    NtTib.StackBase: f5d29df0
    NtTib.StackLimit: f5d27000
    NtTib.SubSystemTib: 00000000
    NtTib.Version: 00000000
    NtTib.UserPointer: 00000000
    NtTib.SelfTib: 7ffdc000

    SelfPcr: ffdff000
    Prcb: ffdff120
    Irql: 00000000
    IRR: 00000000
    IDR: ffffffff
    InterruptMode: 00000000
    IDT: 80036400
    GDT: 80036000
    TSS: 80474850

    CurrentThread: 853e7a60
    NextThread: 00000000
    IdleThread: 80470600

    DpcQueue:


    NtTib.StackLimit 値は、スタック範囲の下限を表します。 NtTib.StackBase 値は、ESP の最近の値を表します。 NtTib.StackBase 値を ESP レジスタの現在の値と比較して、現在の ESP レジスタ値にシングルビット エラーがあるかどうかを識別できます。
  6. .formats esp ^ ebp コマンドを実行して、ESP レジスタと EBP レジスタの値の違いを表示します。 EBP レジスタのスタック ポインタ値は、シングルビット エラーを除き、ESP レジスタのスタック ポインタ値に近い値になります。 このコマンドは、特に以下のような例でエラーが2進数形式で表示される場合、エラーを含む単一の上位ビットを頻繁に明らかにします。

    0: kd> .formats esp ^ ebp
    Evaluate expression:
    Hex: 00080034
    Decimal: 524340
    Octal: 00002000064
    Binary: 00000000 00001000 00000000 00110100
    Chars: ...4
    Time: Tue Jan 06 17:39:00 1970
    Float: low 7.34757e-040 high 0
    Double: 2.59058e-318
    下位の有効桁数の最も低い桁を無視すると、ESP レジスタと EBP レジスタ間のシングルビット差を2進数形式で表記すると 00000000 00001000 00000000 00000000 です。 違いを 16 進数形式で表現すると、 00080000 です。

    このシングルビット エラーにより、ESP レジスタに誤った値が含まれます。 値が正しくないと、二重フォールト例外、バグチェック、およびシステム クラッシュが発生します。
特定のハードウェアに関する詳細情報を取得するには、次の手順を実行します。
  1. !cpuinfo コマンドを使用して、CPU バージョン情報を取得します。 以下は、

    !cpuinfo コマンドのアウトプットの例です。

    0: kd> !cpuinfo
    TargetInfo::ReadMsr is not available in the current debug session
    CP F/M/S Manufacturer MHz Update Signature Features
    0 15,2,9 GenuineIntel 2790>0000000000000000<00002fff
    1 15,2,9 GenuineIntel 2790 0000000000000000 00002fff
    クラッシュ ダンプ ファイルを分析するときに[更新署名]の値が常に正確に報告されるとは限りませんが、 [更新署名] フィールドは通常、CPU に適用されるマイクロコード更新リビジョンを示します。 前の例では、この値は 0 (0000000000000000)です。 現在サポートされているリビジョンは、以下の出力例に示されている通り 0x18 (0000001800000000) です。

    0: kd> !cpuinfo
    CP F/M/S Manufacturer MHz Update Signature Features
    TargetInfo::ReadMsr is not available in the current debug session
    0 15,2,9 GenuineIntel 2994>0000001800000000<00033fff
    1 15,2,9 GenuineIntel 2994 0000001800000000 00033fff
    2 15,2,9 GenuineIntel 2994 0000001800000000 00033fff
    3 15,2,9 GenuineIntel 2994 0000001800000000 00033fff
  2. 既存のペリフェラル接続インターフェイス (PCI) デバイスのベンダーとデバイス識別子 (VenDev ID)を検索するには、 !pcitree コマンドを使用します。 以下は、 !pcitree のコマンドで作成される出力ファイルの一例です。



    0: kd> !pcitree
    Bus 0x0 (FDO Ext 85dceed8)
    0600 00141166 (d=0, f=0) devext 85dcf348 Bridge/HOST to PCI
    0600 00141166 (d=0, f=1) devext 85e110e8 Bridge/HOST to PCI
    0600 00141166 (d=0, f=2) devext 85e11ee8 Bridge/HOST to PCI
    0100 00c09005 (d=2, f=0) devext 85e11ce8 Mass Storage Controller/SCSI
    0100 00c09005 (d=2, f=1) devext 85e11ae8 Mass Storage Controller/SCSI
    0300 47521002 (d=3, f=0) devext 85e11788 Display Controller/VGA
    0200 16a614e4 (d=4, f=0) devext 85e11428 Network Controller/Ethernet
    0880 a0f00e11 (d=5, f=0) devext 85dcdee8 Base System Device/'Other' base system device
    0601 02011166 (d=f, f=0) devext 85dcdb88 Bridge/PCI to ISA
    0101 02121166 (d=f, f=1) devext 85dcd988 Mass Storage Controller/IDE
    0c03 02201166 (d=f, f=2) devext 85dcd628 Serial Bus Controller/USB
    0600 02251166 (d=f, f=3) devext 85dcd2c8 Bridge/HOST to PCI
    0600 01011166 (d=11, f=0) devext 85e100e8 Bridge/HOST to PCI
    0600 01011166 (d=11, f=2) devext 85e10ee8 Bridge/HOST to PCI
    Bus 0x2 (FDO Ext 85dcecd8)
    0104 00460e11 (d=2, f=0) devext 85e0f9a8 Mass Storage Controller/RAID
    Bus 0x5 (FDO Ext 85dce9d8)
    No devices have been enumerated on this bus.
    Total PCI Root busses processed = 3

    リストされている PCI デバイスごとに、各行の最初の 8 桁の 16 進値 (DWORD) が VenDev ID です。 ベンダー ID は、実際にはこの値の 2 番目の 4 桁です。 たとえば、前の例に記載されている最初のデバイスの VenDev ID は 0x00141166 です。 デバイス ID は 0x0014 で、ベンダー ID は 0x1166 です。 ServerWorks のベンダー ID は 0x1166 です。 したがって、この出力は、ServerWorks チップセットを使用するマザーボードにインストールされているプロセッサからのものです。
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示または黙示にかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。