Memory.dmpのスタックについて

Question

STOPエラーが発生し、Memory.dmpが出力されていてスタックは以下の通りでした。
NMIなのでハードエラーだと思うのですが、各スタックの意味を教えて頂けないでしょうか。

Child-SP RetAddr : Args to Child : Call Site
fffff88001ff2cb8 fffff8000182b9b8 : 0000000000000080 00000000004f4454 0000000000000000 0000000000000000 : nt!KeBugCheckEx
fffff88001ff2cc0 fffff800019f01a3 : 0000000000000001 fffff800018422b0 0000000000000000 000000000000005c : hal!HalBugCheckSystem+0x160
fffff88001ff2d00 fffff800018257a1 : 00000000000006c0 fffff88001ff2f2c fffff88001ff2df0 fffff800018422b0 : nt!WheaReportHwError+0x263
fffff88001ff2d60 fffff80001991ee1 : fffff88001ff2f30 0000000000000001 0000000000000001 0000000306c48058 : hal!HalHandleNMI+0x149
fffff88001ff2d90 fffff800018d2f82 : 00000001c7f08260 0000000000000000 0000000000000000 0000000000000006 : nt!KiProcessNMI+0x131
fffff88001ff2df0 fffff800018d2de3 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KxNmiInterrupt+0x82
fffff88001ff2f30 00000001406cbcf2 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiNmiInterruptStart+0x163 (TrapFrame @ fffff88001ff2f30) 0000000022998cd0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00000001406cbcf2

Answer 1

ダンプ解析を行う場合、まず Bug Check Code を確認する必要があります。
Bug Check Code は "!analyze -v" で、確認できます。
このコマンドで Bug Check Code と共に表示される Parameter 値も、ダンプ解析において重要な意味を持ちます。

ただ。。。
Bug Check Code からは、ブルースクリーンが発生した直接的な原因しかわかりません。
つまり、「直接的な原因」が「根本的な原因」とは限らない。。。ということです。

例えば。。。
ドライバＡがドライバＢが管理してい何かのオブジェクトを破壊したとします。
でもこのタイミングでは、大抵の場合ブルースクリーンは起きません。
このようなケースでブルースクリーンが発生するのは、ドライバＢが（ドライバＡによって破壊された）オブジェクトにアクセスしたタイミングです。
この場合 Bug Check Code は、PAGE_FAULT_IN_NONPAGED_AREA (0x50) や IRQL_NOT_LESS_OR_EQUAL (0x0A)、BAD_POOL_HEADER (0x19) といった、メモリ破壊に関連して起きやすい問題の値になりますが、ダンプ上には壊された後の状態しか残りません。
つまり、そのダンプにはドライバＡがドライバＢのオブジェクトを破壊した証拠は残っていないので、その１つだけのダンプを調べても原因究明は難しい。。。ということです。
この場合複数のダンプを採取して、それぞれのプール メモリの使用状況や、現在処理中の IRP、さらには LPC (Local Procedure Call) の関係がどうなっているかなど、様々な観点からの解析が必要になります。
（もっとも例に挙げたケースの場合、"Driver Verifier" ツールを使えば、サクッっと解決できますけど。）

つまり何が言いたかったというと。。
ダンプ解析で最も陥りやすい間違いは、コール スタックの状況だけで判断してしまうことです。
上記で説明したように、ブルースクリーンで生成されたダンプ ファイルが問題の「根本的な原因」を示していることは、むしろ稀です。
ほとんどの場合、ダンプは「直接的な原因」しか示してくれません。
なので、ダンプ解析でまず一番初めに行うべきは、Bug Check Code 等から、そのダンプがどのような状況を示しているのか、きちんと把握することです。
もちろんコール スタックの確認も重要ですが、確認すべきはそれだけではない、ということです。

Answer 2

このスタックからだけだと、NMI割込みが発生したので KeBugCheckEx が実行されメモリダンプが取得されたという事しか分かりませんね。

（以下、スタックに意味が知りたいという質問からはズレますが）

NMI割込みが発生する要因は、ハード（PC,サーバー）の種類によって様々で、強制的にNMI割込みを発生させてメモリダンプを取得するためのNMIスイッチ（物理的なスイッチ）があるハードもありますし。

ハード異常を知らせるためにハードがNMI割込みを発生させているのであれば、
windbg の !whea コマンドで何か情報が入手できる可能性があります。

試してみてください。

Comments

[mats]

そんな便利コマンドがあったんですね。早速試してみました。
kd> !whea
Error Source Table @ fffff80001a6b818
0 Error Sources

u fffff80001a6b818
nt!WheapErrorSourceTable:
fffff800`01a6b818 54 push rsp
fffff800`01a6b819 41 ???
fffff800`01a6b81a 42 ???
fffff800`01a6b81b 4c0500000010 add rax,10000000h
fffff800`01a6b821 b027 mov al,27h
fffff800`01a6b823 0d80faffff or eax,0FFFFFA80h
fffff800`01a6b828 d0fb sar bl,1
fffff800`01a6b82a 27

所々文字化けしているのでやっぱりハードで決まりですかね。
気になっているのが!threadコマンドのImageがoracle.exeに
なっているところです。

[mats]

補足ですが本事象はNMIスイッチを押して出したわけではなく
勝手にリブートして出力されています。
STOPコードが0x80の時点でH/Wと回答してしまおうと
思ったのですがImageの部分が気になり回答を保留しています。