1

誤って kd を実行したところ、興味深い出力が得られました。モジュール内のコード行への参照であり、どのスレッドのコール スタックにも表示されません。行はメソッドの始まりではなかったので、参照が関数ポインタへのものではないと思いますが、メモリに格納されている例外の結果である可能性があります??? もちろん、それはたまたま私が探しているものです...

アップデート：

例外のスタック トレースは次のとおりです。

0:000> kb
   *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  Args to Child              
0174f168 734ea84f 2cb9e950 00000000 2cb9e950 kernel32!LoadTimeZoneInformation+0x2b
0174f1c4 734ead92 00000022 00000001 000685d0 msvbvm60!    RUN_INSTMGR::ExecuteInitTerm+0x178
0174f1f8 734ea9ee 00000000 0000002f 2dbc2abc msvbvm60!    RUN_INSTMGR::CreateObjInstanceWithParts+0x1e4
0174f278 7350414e 2cb9e96c 00000000 0174f2f0 msvbvm60!    RUN_INSTMGR::CreateObjInstance+0x14d
0174f2e4 734fa071 00000000 2cb9e96c 0174f2fc msvbvm60!RcmConstructObjectInstance+0x75
0174f31c 00976ef1 2cb9e950 00591bc0 0174fddc msvbvm60!__vbaNew+0x21

コードに (新しい Form 派生クラスを作成します)

dds 出力:

0:000> dds esp-0x40 esp+0x100
0174f05c  00000000
0174f060  00000000
0174f064  00000000
0174f068  00000000
0174f06c  00000000
0174f070  00000000
0174f074  00000000
0174f078  00000000
0174f07c  00000000
0174f080  00000000
0174f084  00000000
0174f088  00000000
0174f08c  00000000
0174f090  00000000
0174f094  00000000
0174f098  00000000
0174f09c  007f4f9b ourDll!formDerivedClass::Form_Initialize+0x10b [C:\Buildbox\formDerivedClass.frm @ 1452]

等

これは、この例外またはいずれかのスレッドのスタック トレースにないにもかかわらず、Initialize が呼び出されていることを示しているようです。示唆されているように、すべて pdb と dll の間の不一致である可能性がありますが、適切なクラスとメソッドにたどり着いたのは偶然のようです

4

2 に答える 2

1

Kd は「スタック ダンプ」の略です。ドキュメントから：

kd コマンドは生のスタック データを表示します。各 DWORD 値は、個別の行に表示されます。これらのラインのシンボル情報が、関連するシンボルとともに表示されます。この形式は、他の k* コマンドよりも詳細なリストを作成します。kd コマンドは、スタック アドレスをパラメーターとして使用する dds (Display Memory) コマンドと同等です。

.hh を試して、ntsd / windbg 内からデバッガーのヘルプを取得してください。

「dds esp-0x40 esp+0x80」も参照

于 2009-05-06T15:12:56.460 に答える
0

すみませんが、実際に "kb" コマンドを実行したように見えますが、"D" ではなく "B" を使用しています。それが上記のセッションに表示されるものであり、http: //www.debuginfo.com/articles/easywindbg.html の例は確かに同様の出力を生成するようです...

于 2010-03-19T21:39:53.163 に答える