問題タブ [crash-dumps]
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.
debugging - 例外をスローする別のプロセスのスレッドIDを知る方法はありますか?
MiniDumpWriteDump()APIを使用して、クラッシュしたプロセスBを別のプロセスAからダンプしようとしています。MSDNが次のように言っているため、これを実行しています。
MiniDumpWriteDumpは、ダンプされるターゲットプロセス内からではなく、可能であれば別のプロセスから呼び出す必要があります。
MiniDumpWriteDump()は次のように定義されます。
特に、ExceptionParamのタイプはPMINIDUMP_EXCEPTION_INFORMATIONであり、次のように定義されています。
今、私は次の2つのパラメータをどのように準備するのか疑問に思っています。
ThreadId 例外をスローするスレッドの識別子。
ExceptionPointers コンピューターに依存しない例外の説明と例外時のプロセッサーコンテキストを指定するEXCEPTION_POINTERS構造体へのポインター。
プロセスAで実行しているときに、プロセスBで障害のあるスレッドIDと例外ポインターを取得するにはどうすればよいですか?
ありがとう。
iphone - iOS アプリケーションが再開できませんでした。修正方法は?
この問題を修正する方法がわかりません。
asp.net - Asp.net アプリケーションは遅いが、CPU は最大 40% です
本番サーバーで奇妙な状況が発生しています。asp.net の接続はキューに入れられますが、CPU は 40% しかありません。また、データベースは 30% の CPU で正常に動作します。
コメントで要求されたその他の履歴:
- ピーク時には、サイトには 1 時間あたり約 20,000 人の訪問者が訪れます。
- このサイトは、多くの AJAX/POST を使用する asp.net Web フォーム アプリケーションです。
- サイトは多くのユーザー生成コンテンツを使用しています
- サイトで使用されるデータベースと Web サービスにヒットするテストページを使用して、サイトのパフォーマンスを測定します。このページは、通常の読み込みで 1 秒以内に提供されます。リクエストに 4 秒以上かかる場合、アプリケーションが遅いと定義します。
- 測定から、接続時間は高速ですが、処理時間は長いことがわかります。
- 単一のリクエストに対する遅い応答を特定することはできません。サイトは通常の時間帯には正常に動作しますが、ピーク時には遅くなります
- サイトが CPU バウンド (別名 100% で実行中) であるという問題がありましたが、これを修正しました。
- アプリドメインを再起動する例外の問題もありましたが、修正しました。
- ピーク時には、asp.net パフォーマンス カウンターを調べます。現在の接続が 600 あり、キューに入れられた接続が 500 あるという動作を確認できます。
- ピーク時には、CPU は約 40% です (CPU バウンドではないと思います)。
- 物理メモリは約 60% 使用されています
- ピーク時には、DatabaseServer の CPU は約 30% です (データベースに依存していないと思われます)。
私の結論は、他の何かがサーバーがリクエストをより速く処理するのを妨げているということです。容疑者の可能性
- デッドロック (!syncblk は 1 つのロックのみを与える)
- ディスク I/O (sysinternals procesexplorer で確認: 3.5 mB/s)
- ガベージ コレクション (ピーク時に 10 ~ 15%)
- ネットワーク I/O (接続時間はまだ短い)
プロセスが何をしているかを調べるために、ミニダンプを作成しました。
20 秒間隔で 2 つの MemoryDumps を作成することができました。これは最初の出力です:
そして2番目の出力:
ご覧のとおり、多くの Request in Queue があります。
質問 1:キューに 1589 件のリクエストがあるとはどういう意味ですか? 何かがブロックされているということですか?
!threadpool リストには、主に次のエントリが含まれています。
AsyncTimerCallbackCompletion について深く掘り下げた場合
次に、TimerCallback 内のオブジェクトを調べます。それらのほとんどは型です。
質問 2:それらのオブジェクトがタイマーなどを持っていることは意味がありますか? これは防げばいいのに。そしてどうやって?
主な質問接続をキューに入れているのに CPU を使い果たしていない明らかな問題を見逃すことはありますか?
ピーク時のクラッシュダンプの作成に成功しました。debugdiag で分析すると、次の警告が表示されました。
簡単なグーグル検索では結果が得られません。誰かが手がかりを持っていますか?
arm - プログラムカウンタのゼロ値
プログラム カウンター (PC) は、現在実行中の命令または次の命令のアドレスを保持します。ARMV5 の場合は、前者のケースです。
PC (R15) 値がゼロのクラッシュに遭遇しました。誰かがその意味を教えてくれるだろうかと思っていました。そして、現在の命令のアドレスを見つける方法(他のレジスタ)はありますか。
どんな助けでも大歓迎です。
crash - DrWatsonなどのすべてのWindowsクラッシュハンドラーを無効にするにはどうすればよいですか?
単体テストの自動実行アプリケーションを開発していますが、1つのアプリケーションがクラッシュしてもダイアログが表示されないようにする必要があります。クラッシュダンプは素晴らしいですが、主な要件は、実行を自動化しており、それらのダイアログを自動化しないため、ダイアログが表示されないことです。
Windowsエラー報告を無効にしましたが、唯一の変更点は、送信オプションのない別のダイアログです。
何か案は?
ありがとう。
c++ - 呼び出し命令での C++ プログラムのクラッシュ (C0000005 アクセス違反)
不可解なクラッシュがあり、これまでのところ、一貫して再現することは不可能であることがわかりました。コードは Visual Studio 2008 でコンパイルされています。
(もちろん簡略化された) ソースコードは次のようになります。
クラッシュ ダンプからの逆アセンブルは次のようになります。
逆アセンブリに対して func() のソースをマッピングすると、次のようになります。
正常に実行された場合 (別のマシン、同じマシンでも、クラッシュは確実に再現できません)、逆アセンブリの唯一の違いは call 命令です。これ:
好きではなく:
そのため、クラッシュ実行では、呼び出し命令のパラメーターとして機能する a06cff10 アドレスは、誰がどこから来たのかを知っているようで、特に何にもマップされていません。そのため、予想どおり、そのアドレスに (ChildClass の既定のコンストラクターに到達するために) アクセスしようとすると、アクセス違反が発生します。
クラッシュ ダンプでそのアドレスを調べようとすると、アドレスがプロセスの範囲外にあることが示されます。
更新: 以下の zvrba からの応答を読んでさらに詳しく調べたところ、問題のある呼び出しは、静的ライブラリ (DLL によって読み込まれる) 内の 12 ほどの関数呼び出しの最初の呼び出しであると思われます。関数オフセット。それらはすべて同じクラスの関数ではありません。すべてのクラス (呼び出し元と呼び出し先の両方) が同じ静的ライブラリに存在しますが、関数が影響を受ける 3 つまたは 4 つの異なるクラスがあります。クラッシュしたこの最初の呼び出しでは、命令は e8e053403f であり、その命令の 3F4053E0 オフセットはちょうど 53E0 のオフセットでした。他のすべてのインスタンスには、同じオフセットの問題があります。命令のオフセットは 3F40XXXX ですが、XXXX だけである必要があります。余分な 3F400000 はもちろん、ネバー ネバー ランドに物を送り込んでいます。これまでのところ、逆アセンブリ内のどの関数アドレスが有効で、どれが有効かどうかに関するパターンを見つけていません。ライブラリ内の DifferentClass の 1 つのメンバー関数では、ChildClass へのすべての呼び出しが不適切であると見なされますが、別のメンバー関数 DifferentClass では、ChildClass への別の呼び出しが適切に表示されます。
誰かがこのようなものを見たことがありますか/その考えられる原因について何か考えがありますか?
ios - iOSアドホッククラッシュレポートのデバッグ:
私のユーザーの1人が私にたくさんのクラッシュログを送ってくれました。それらの大多数はこのように読んでいます-
これは私には本当に意味がありません、私は本当に明白な何かを逃していますか?
ありがとう、
テジャ。
c++ - クラッシュの原因を反映するWin32C++を報告するクラッシュの文字列を作成する良い方法は何ですか?
問題の追跡にFogbugzを使用しており、FogbugzのXMLAPIの周りにC++ラッパーを作成している最中です。
ベストプラクティスは、「スカウト」フィールドを使用して、類似/同じクラッシュがカウントされるだけで、再度報告されないようにすることです。そのためには、クラッシュの特定の原因に対する一意の文字列が必要です。
Win32の場合-dmpファイルまたは他のクラッシュハンドラーを取得した後、クラッシュの一意の文字列を作成するための良い方法は何ですか?(dmpファイルを作成してfogbugzサーバーに送信します)
以前の投稿/記事などで、Joelはさまざまな提案をしましたが、それらの多くは、リフレクションを使用し、取得が難しいか取得できない多くの情報を持っているC#のような言語に頼っています。
他の人は、スタックトレースや、fogbugzにスカウトエントリを作成するための他のものなどを入手しましたか?
編集明確にするために-すべてのインシデントに一意のIDは必要ありません-同じコードパスを持つクラッシュが発生する可能性があります。それを捉えたい。コードに含まれる最後の数個のスタック呼び出し(win32 DLLからの呼び出しではない)を取得することを考えていましたが、これを実行する方法がわかりません。
すべてのクラッシュを一意として報告するのは正しくありません。同じケースですべてのクラッシュを報告するのは正しくありません。クラッシュの原因となるシナリオを繰り返すさまざまなユーザーは、同じインシデントにマッピングする必要があります。
編集
私たちが望んでいるのは、スタックにあるものに基づいた、クラッシュの一般的な「シグネチャ」です。同様のスタックは同じ署名を持つ必要があります。たとえば、アプリにある上位5つのメソッドを取得してから、最初の呼び出し(存在する場合)をMSDLLにします。これはおそらく署名には十分であり、「同じ」クラッシュを相関させる可能性があります。
では、スタック上のメソッドのリストをどのように取得するのでしょうか。そして、それらが自分のアプリからのものか、別のDLLからのものかをどのように判断できますか?
編集-注ミニダンプを作成し、スカウトの説明としてfogbugzに送信できるように、例外ハンドラーで「バケットID」/署名を作成します。または、アプリの次の起動時にダンプをロードし、生成した署名を付けて送信することもできます。
.net-4.0 - w3wp.exeクラッシュ-ThreadAbortException
再現できない問題があります。ASP.NET4を実行しているWebサーバー(Windows Server 2008 Datacenter 64ビット、Amazon EC2でホスト)でランダムに発生します。
これは、エラーログのASP.NET警告(非常に長いURLを持つ奇妙なGETリクエスト)で始まります。
例外情報:
例外タイプ:HttpException
例外メッセージ:この要求のURLの長さが、構成されたmaxUrlLength値を超えています。
System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
次にエラー:
アプリケーションID:/ LM / W3SVC / 2 / ROOT
プロセスID:4604
例外:System.Threading.ThreadAbortException
メッセージ:スレッドは中止されていました。
StackTrace:System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr、HttpContext context) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper
(IntPtr managedHttpContext、IntPtr nativeRequestContext、IntPtr moduleData、Int32 flags)atSystem.Web.Hosting.PipelineRuntime。
(IntPtr managedHttpContext、IntPtr nativeRequestContext、IntPtr moduleData、Int32フラグ)
次に別のエラー:
アプリケーションID:DefaultDomain
プロセスID:4604
例外:System.Threading.ThreadAbortException
メッセージ:スレッドは中止されていました。
スタックトレース:
そして、アプリケーションエラー:
障害のあるアプリケーションw3wp.exe、バージョン7.0.6002.18005、タイムスタンプ0x49e03238、障害のあるモジュールkernel32.dll、バージョン6.0.6002.18005、タイムスタンプ0x49e041d1、例外コード0xe0434352、障害オフセット0x00000000000176fd、プロセスID 0x%9、アプリケーション開始時間0x%10 。
Windbg
adplusでクラッシュしたためにダンプを取得できましたが、何を探すべきか本当にわかりません。以前にWindbgでいくつかのスタックオーバーフローのトラブルシューティングを行いましたが、このエラーにどのアプローチを使用すればよいかわかりません。
!エラーのあるスレッドでpe:
例外オブジェクト:00000001c323d948
例外タイプ:System.Threading.ThreadAbortException
メッセージ:スレッドは中止されていました。
InnerException:
StackTrace(生成):
StackTraceString:
HResult:80131530
!clrstack
子SPIP呼び出しサイト
0000000015f7f0780000000076c176fd[GCFrame:0000000015f7f078]
0000000015f7f258 0000000076c176fd [GCFrame:0000000015f7f258]
k
Child-SPRetAddr呼び出しサイト
00000000f2826e39kernel3215f7edf0 000007fe
!RaiseException + 0x39
0000000015f7eec0 000007fe
f2bbbfb4 clr ! RaiseTheExceptionInternalOnly + 0x363
00000000 f2bbc906 clr!RaiseTheException + 0xa4 00000000 f2c3b99b clr! BStrFromString + 0x66 00000000 f2c3b9 clr!Thread :: RaiseCrossContextException + 0x2a7 00000000 f2830886 clr!?? :: FNODOBFM :: 15f7f4c0 000007fe 15f7f530 000007fe 15f7f5c0 000007fe 15f7f5f0 000007fe 15f7f620 000007fe 15f7f6d0 000007fe15f7eff0 000007fe
15f7f020 000007fe
15f7f050 000007fe
15f7f0c0 000007fe
15f7f0f0 000007fe
15f7f310 000007fe
string'+0xafb03
00000000f27fcce3 clr!UM2MDoADCallBack+0x9e
00000000f845ba59 clr!UMThunkStubAMD64+0x273
00000000f8458f02 webengine4!W3_MGD_HANDLER::ProcessNotification+0x79
00000000f27d4595 webengine4!ProcessNotificationCallback+0x43
00000000f27d3ac8 clr!UnManagedPerAppDomainTPCount::DispatchWorkItem+0x181
00000000f294658f clr!ThreadpoolMgr::NewWorkerThreadStart+0x2e5
15f7f770 000007fe 15f7f810 00000000 15f7fbd0 00000000 15f7fc00 00000000`00000000 ntdll!RtlUserThreadStart + 0x1d
00000000f29447c6 clr!ThreadpoolMgr::WorkerThreadStart+0x3b
0000000076c1be3d clr!Thread::intermediateThreadProc+0x7d
0000000076d56a51 kernel32!BaseThreadInitThunk+0xd
00000000
誰かがこれが何であるかについての手がかりを持っていますか?または、Windbgで分析するための正しい方向に私を向けることができますか?
編集:受信URLは通常、次のようになります。foo.bar.com/wEPDwULLTE1MTk5MzIzMTFkGAMFFmN0bDAwJGRiMSRkZGxEYXRhYmFzZXMPFCsAAmRkZAU7Y3RsMDAkU2VhcmNoQ2xvdWQxJF9SaWdodENvbHVtbiRfU2VhcmNoQ2xvdWQkbHN2U2VhcmNoVGVybXMPFCsADmRkZGRkZGQ8KwAUAAIUZGRkZgL/D2QFK2N0bDAwJHN1cnZleTEkX1JpZ2h0Q29sdW1uJF9JUiR1c2VyQ29tbWVudHMPFCsAA2VnZGQeuUcvQDsShDIp1k7YjJw70Ry 9 / Q1B9Sd1egrovYgkw == /
しかし、イベントログで、これは次のようなURLでも発生することがわかりました:foo.bar.com/&(.NET 4の「危険なリクエスト」)
c# - VisualStudioでのダンプファイルのデバッグ
Visual Studio 2010ProfessionalEditionとWindowsVistaを使用しています。
まず、私はこのコードを持っています。ご覧のとおり、プログラムがクラッシュします。
プログラムはifステートメントでクラッシュします。今、私はそれがそのifステートメントでクラッシュしたことを知りたいです。
Visual Studioから「デバッグせずに開始」すると、Crash.exeがクラッシュします。1,356kbのメモリを使用します。プログラム/デバッグを閉じるというVistaオプションが表示されます。デバッグを選択すると、Visual Studioの新しいインスタンスを開くことができ、ifステートメントでNullReferenceExceptionが示されます。これはいい。
ここで、別のコンピューターでクラッシュすると仮定します。タスクマネージャーを介してダンプファイルを提供してもらいます。54,567kbです。なんでこんなに大きい!広大です!とにかく、私はそれにあまり興味がありません(少し)
Windbgでそのダンプを開くと、訓練を受けていない目にはほとんど役に立たなくなります。
しかし、これは私にはあまり興味がありません。私の知る限り、有用な出力を得るにはコマンドを書き込む必要があり、VisualStudioの方が優れています。
そこで、VisualStudioで開きます。「ネイティブのみでデバッグ」を選択することもできますが、あなたのような賢い人にとって何か意味のあるものがたくさんあります。私は賢くありません。次の2つの画面が表示されます。
だから、私の質問:
Visual Studioをソースコードに表示するにはどうすればよいですか?
また、より小さなダンプファイルを取得する方法はありますか?圧縮した後でも、途方もなく大きいようです。プログラムのフットプリントよりもほんの少し大きいだけで、ソースコードを使用して優れたデバッグを行うことができない理由がわかりません。