問題タブ [windbg]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
windbg - WinDbg で共有メモリ セクションの内容を表示しますか?
名前付きメモリ セクションを使用して通信するプログラムがいくつかあります。ユーザー モードまたはカーネル モードのいずれかで、WinDBG からこの共有メモリ セクションの内容を表示する方法はありますか? 私はそれへのポインターを持っていませんが、名前は知っています。
windbg - windbg を使用してハング ダンプからハンドルの所有者を見つけるにはどうすればよいですか?
どのスレッドが windbg のイベント ハンドルの所有者であるかを調べるにはどうすればよいですか。
私は走っています
そして得る
名前がないので、スレッドが待機しているスレッドを証明するために所有者を取得する方法がわかりません
[編集] 元のプロセスをユーザーのマシンで再起動する必要があるため、ダンプに対して作業する必要があるため、ライブ セッションをデバッグできません
私がこれまでに見つけた主題に関する最良の議論はこのブログにありますが、残念ながら私たちは異なるロック方法を使用することになり (私は WaitForMultipleObjectsEx を使用し、説明は WaitForSingleObject に関するものです)、彼はライブプロセスにアクセスできるようです
私のスレッドのスタックトレース(何かでブロックされていて、現在の所有者を探している場所)は次のとおりです。
debugging - WinDbg シンボルの解決
WinDbg を使用する場合、プライベート シンボル ファイル (pdb?) はどこに配置する必要がありますか?
私の状況は次のとおりです。デバッグしたい DLL があります。この DLL のソース コードとシンボル ファイルがあります。この DLL は別の DLL (シンボルもソースもありません) によって呼び出され、次に EXE (シンボルもソースもありません) によって呼び出されます。
私の問題は、次のような警告が表示されることです
*** 警告: C:\TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dllのチェックサムを確認できません
この警告が、コール スタックで次のタイプのメッセージを受け取る理由だと思います。
MyDll!AClass::AFunction+SomeHexAddress
私のファイル構造は次のようになります。
exe: C:\TheProgram\program.exe
呼び出し元の dll: C\TheProgram\SomeSubfolder\caller.???
デバッグしたい DLL: C:\TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll
注: シンボル ファイル パスとソース ファイル パスを、デバッグ DLL が生成された場所 (exe とは別のドライブのワークスペース) に設定しました。しかし、pdb + マップ ファイルをコピーして、必要な dll に配置しました。デバッグする..
debugging - IDebugSymbols::GetNameByOffset とオーバーロードされた関数
IDebugSymbols::GetNameByOffsetを使用していますが、同じ名前をオーバーロードするさまざまな関数に対して同じシンボル名を取得していることがわかります。
たとえば、シンボルを検索しているコードは次のようになります。
実行時に、これらの関数のそれぞれからの命令のアドレスを取得したら、使用GetNameByOffset
して 2 つをどうにかして区別したいと思います。ここに記載されているように、フラグとフラグを切り替える SetSymbolOptionsを呼び出して実験しましたが、うまくいきませんでした。SYMOPT_UNDNAME
SYMOPT_NO_CPP
デバッガーエンジンの世界でこれらをシンボルに区別する方法を知っている人はいますか?
編集:提案された解決策に対するマイナーな修正について、受け入れられた回答についてコメントしてください。
.net - コールスタックの RedirectedThreadFrame
windbg のコールスタックで RedirectedThreadFrame を見た人はいますか? これは、マネージ コールスタックからのものです。フレームワーク内で多くの例外がスローされているのを目にしていますが、それが私にバブルされたことは一度もありません。その理由を理解しようとしています。ネイティブ コールスタックには次のものがあります。
0526f6b0 79f63d27 KERNEL32!RaiseException+0x53 0526f718 79f64102 mscorwks!Thread::RedirectedHandledJITCase+0x198 0526f720 00000000 mscorwks!Thread::RedirectedHandledJITCaseForGCThreadControl+0x7
マネージ コールスタックには次のものがあります。
0526f6dc 7c812aeb [RedirectedThreadFrame: 0526f6dc] 0526f724 00c741b9 Library.Class.b__3(MyObject) 0526f7cc 00c73c85 ParallelProcessingLibrary.ActionController`1[[System.__Canon, mscorlib]].ExecutePartition(System.Object) 0526f840System. System.Object) 0526f84c 792e019f System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext、System.Threading.ContextCallback、System.Object) 0526f864 797db48a System.Threading.ThreadHelper.ThreadStart(System.Object) 0526fa8c 79e71b4c [GCFrame: 0526fa8c ]
これが何を意味するのかについての情報を見つけることができませんでした。説明をいただければ幸いです。
.net - WinDbg -- TraceListener と飽和した ThreadPool
断続的にハングアップするマルチスレッド .NET Windows サービスを使用しています。ハングが発生すると、カスタム tracelistener への呼び出しが何らかの理由でブロックを開始するため、スレッドプールは完全に飽和状態になります。問題のあるコードにロックはなく、windbg によるとブロックしているものはありませんが、どこかでブロックしていることは間違いありません。スタックにも例外はありません。BufferedStream.Write コードで時折ヒットする Thread.Sleep(1) がありますが、私の質問は、ReOpenMetaDataWithMemory、CreateApplicationContext、および DllCanUnloadNow の意味は何ですか?
ThreadPool 上のハングアップした 2000 のワーカー スレッド (通常の動作ではありません!) のほぼすべてに、次のようなスタックがあります。
windbg - !dumpheap (windbg) の出力を n 個のオブジェクトに制限する
windbg を使用して !dumpheap コマンドを実行してオブジェクトのアドレスを表示する場合、特定の数のオブジェクトに制限するにはどうすればよいですか。私が見つけた唯一の方法は、ブログhttp://dotnetdebug.net /2005/07/04/dumpheap-parameters-and-some-general-information-on-sos-help-system で CTRL+BREAK とコマンド ラインを使用することでした。 /
-l X - すべてのオブジェクトではなく、各ヒープから X 項目のみを出力します。
どうやら -l は SOS.dll に存在しなくなりました
debugging - .NET CLR アプリケーションをデバッグするときに、評価スタックのローカル変数を表示するにはどうすればよいですか?
Windbg (sos エクステンション付き) を使用しており、クラッシュしたアプリケーションをデバッグしようとしています。例外をスローした呼び出しの IL をダンプすることができ、コードを調べると、評価スタックの内容をダンプできれば必要な情報を取得できたようです。WinDbg & sos で何ができますか?
これが私がしたことです:
- WinDbgを開始しました
- クラッシュしたプロセスに接続
- loadby sos mscorwks (sos 拡張機能をロードするため)
!token2ee theModuleName 0600009a (ここで、theModuleNameはデバッグ中のアプリ (およびアセンブリ) の名前で、9aは Windows エラー報告ツールによって報告されたクラッシュしたメソッドのメソッド オフセットです。次の出力が得られました。
モジュール: 000e2c3c (theApplicationName.exe)
トークン: 0x0600009a
MethodDesc: 000e67c8
名前: MyNamespace.MyClassName.theCulpritFn(MyOtherClass)
JITTED コード アドレス: 0081b1d0!dumpil 00e67c8 (問題のメソッドの IL をダンプした) . これは出力です:
問題は、例外がスローされる前に何がスタックにプッシュされたかを確認する方法があるかどうかです。私が間違っていなければ、例外コンストラクターに渡される引数は、評価スタックのインデックス 0 にあるローカル変数でなければなりません。
PS !clrstack -aを呼び出そうとすると、次のメッセージが表示されました。現在のスレッドはマネージド スレッドではない可能性があります。!threads を実行して、プロセス内のマネージド スレッドの一覧を取得できます。
ありがとう!