2017-01-26 8 views
0

私はWindowsでwindbgとmemory analizeの新機能です。 私はx64システムのメモリダンプ(クラッシュダンプ)をアナライズしようとしています。シンボル警告がある場合、windbg analyzeの結果を使用できますか?

すべてのシンボル(私とMicrosoft) をロードした後、私はこれは出力の一部です!analyze -v

を入力します。

...... 
FAULTING_SOURCE_CODE: <some code here> 

SYMBOL_STACK_INDEX: 6 

SYMBOL_NAME: rtplogic!CSRTPStack::Finalize+19d 

FOLLOWUP_NAME: MachineOwner 

MODULE_NAME: RTPLogic 

IMAGE_NAME: RTPLogic.dll 

DEBUG_FLR_IMAGE_TIMESTAMP: 58542837 

STACK_COMMAND: ~544s; .ecxr ; kb 

FAILURE_BUCKET_ID: WRONG_SYMBOLS_c0000374_RTPLogic.dll!CSRTPStack::Finalize 

BUCKET_ID: X64_APPLICATION_FAULT_WRONG_SYMBOLS_rtplogic!CSRTPStack::Finalize+19d 
...... 

このWRONG_SYMBOLSは私を心配しました。

私はFAULTING_SOURCE_CODEのコードは、クラッシュに関連するコードであることを確認できますか?

答えて

2

いいえ、残念ながら、あなたはそれを信頼できません。コールスタックの解析に少なくとも1つのポイントがあります。ここでは、デバッガがスタックを巻き戻しているかどうかを100%確信していませんでした。

~544s; .ecxr; kと入力すると、コールスタックが表示されます。そのコールスタックには、その時点で不確実な警告が表示されます。以前はすべてを信頼することができますが、警告の下のスタックフレームは信頼できません。

の出力をdps @ebpと比較して、デバッガが推測できる内容を確認するために出力が十分でない場合はL fffを追加してください。

dpsの出力では、スタック上の計算の1つが記号として解釈される可能性のある値になった場合、全く関係のないものも表示されることに注意してください。

2

c0000374は、STATUS_HEAP_CORRUPTIONです。通常のダンプを見ると、破損が発生した後のコードだけが表示されます。

あなたのexe

enter image description here

PageHeapためgflags.exeとPageheapを有効にするには、Windowsが割り当てを超えてメモリにアクセスしようとする試みを検出するために、各割り当ての境界でその予備のメモリを備えています。これはアプリケーションをより早くクラッシュさせ、ここでクラッシュの本当の原因を見ることができます。 dmpを開き、!analyze -vを実行して、何が壊れているかを確認します。

+0

音が聞こえます。私が理解しているように、 'gflags'はすでに実行されているプロセスのいくつかの設定を変更するツールです。しかし私の場合、メモリダンプは私のPCからではなく、私は問題のあるリモートPCに直接アクセスしていません。この機能を別の方法で有効にすることは可能ですか? Lコンパイル時のデバッグフラグのような例? –

+0

アプリがクラッシュするPCでこの設定を有効にする必要があります。 – magicandre1981

+0

@StepanLoginov:ヒープ上のすべての単一のintに対して、全ページヒープが8kBのメモリ(2ページ、データ用に1つのアクセス可能なページと1つのアクセスできないページでデバッガをトリガする)を割り当てることに注意してください。したがって、このアプローチでは4kBを超えるリークしか検出されません。実際の問題が発生する前にメモリ不足に悩まされているので、32ビットプログラムではほとんど機能しません。あなたの64ビットプログラムでうまくいくかもしれません。 –

関連する問題