開発マシンでは正常に実行されますが、他の2台のテストマシンではクラッシュするWindowsフォームアプリケーション（.NET 4）があります。VS2010で作成したミニダンプをロードできます。
「混合でデバッグ」を選択すると、Visual StudioによるCPUの悪用が明らかに無限になります（約20分後にdevenvを強制終了しました）。
「ネイティブのみでデバッグ」すると、ソースが見つかりません（テストマシンと同じフォルダーにソースをミラーリングしたにもかかわらず）。それは単に言う：
YourWinApp .exe.hdmp：0xC0000409：0xc0000409の0x793f5b8cで未処理の例外 。
そして私に見せて
呼び出しスタックの場所：clr.dll！793f5b8c（）
アプリケーションがクラッシュする原因をどのように見つけることができますか？[Microsoftに通知]ダイアログが表示されているときに完全なクラッシュダンプを取得できますか？それは役に立ちますか？
ミニダンプのデバッグは、VS2010で大幅に改善される予定でした。私自身はまだ多くの証拠を見ていませんが、混合モードのデバッグは、いくつかの簡単なテストを行ったときと同じように厄介に見えます。しかし、私の言葉を信じないでください。ただし、ネイティブのみでは、マネージドコールスタックが表示されることはありません。
ソースでこれに取り組みます。AppDomain.CurrentDomain.UnhandledExceptionのイベントハンドラーを作成し、Main（）メソッドに登録します。たとえば、メッセージボックスにe.ExceptionObject.ToString（）の値を表示します。これにより、例外の管理されたスタックトレースが取得されます。そのメッセージボックスが表示されている間、ミニダンプをスナップすることもできますが、クラッシュの場所に近づく必要があります。
ただし、発生している特定の例外は、ネイティブC /C++コードを確実に指していることです。スタックを破壊しているバッファオーバーフロー。アプリが使用するネイティブコードの.pdbファイルがあることを確認してください。また、ミニダンプから適切なネイティブスタックトレースを取得できるように、Microsoftシンボルサーバーをセットアップします。
編集：UnhandledExceptionが発生しないという事実は、CRTでのスタック整合性チェックを明確に示しています。例外を発生させず、プログラムをすぐに終了するように設計されています。スタックが危険にさらされているために必要な動作であるため、コードはスタックが安全に巻き戻されると想定できません。クラッシュの場所を考えると、このチェックは実際にはCLRコードで行われる可能性があります。これは以前のCLRバージョンでは行われていなかったことは知っていますが、.NET4.0に含まれているCLRバージョンでは異なる可能性があります。
これにより、管理されたスタックトレースを取得することが非常に困難になります。CLRスタックフレームから識別子名を取得するようにシンボルサーバーを設定する限り、アンマネージスタックトレースからリバースエンジニアリングできるものはたくさんあります。スタックトレースの解釈についてサポートが必要な場合は、そのスタックトレースを質問に投稿してください。CLRコードのバグは、ありそうもないことではありません。Microsoftサポートへの連絡を検討することをお勧めします。ただし、一貫した再現が必要になります。再現が難しい場合は、すべての重要なスタックトレースを処理することができます。シンボルサーバーをセットアップして、適切なアンマネージスタックトレースを取得します。VS2010で簡単：ツール+オプション、デバッグ、シンボル、[Microsoftシンボルサーバー]にチェックマークを付けます。
アプリケーションに未処理の例外がある場合にフルメモリダンプを取得 するようにprocdumpを構成します。これは、VSまたはWindbgでデバッグできます。
そして、ミニダンプにはワトソンバケットとしてのコールスタック情報があります。これはCLRチームからのもので、私は同じことについて書きました
未処理の例外についてイベントビューアに表示されるワトソンバケット情報の簡単な説明