最近、お客様から64ビットのクラッシュダンプを受け取りました。
プロセスはすべて32ビットですが、お客様のマシンはx64Server2008を実行しています。
Visual Studio（2008と2010 Expressの両方）から、64ビットバージョンを使用する必要があると言われましたMSVSMON.EXEが、64ビットマシンがないため使用できません。
WinDbgでこれを行う方法があると確信していますが、WinDbgは敵対的であることがわかりました。
できればVisualStudioを使用して、32ビットマシンで64ビットダンプをデバッグする方法はありますか？
顧客が32ビットツール（adplusまたはDebugDiag）を使用して、32ビットプロセスのクラッシュダンプをキャプチャしていることを確認する必要があります。次に、32ビットマシンを使用してダンプをデバッグできます。
Isalamonのコメントは技術的には正しいですが、スタックトレースがひどいので、誰もそれを実行したくありません。
これが必要であることを顧客に知らせ、彼/彼女が協力することを望みます。
ダンプ分析に精通していない場合は、Microsoftがいつでもご利用いただけます。http：//support.microsoft.com
32ビットのタスクマネージャー（C：\ Windows \ SysWOW64 \ Taskmgr.exe）を使用してダンプをキャプチャすることで、この問題を回避しました。
ここでアドバイスされているように、！wow64exts.swを使用してx86モードに切り替えるためのアドバイスを使用して、優れた結果が得られました。
http://blogs.msdn.com/b/ntdebugging/archive/2008/06/03/how-to-debug-wow64-applications.aspx
ここに同じアドバイスの数字：
そして、ここにある背景と関連コマンド：
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384163(v=vs.85).aspx
これが、このスレッドにすでに存在するものに加えて、このトピックに関する適切な入力の編集として役立つことを願っています。ありがとう。
ユーザーダンプですか、それともカーネルダンプですか？システムダンプを取得したようです。その場合は、windbgの！wow64exts拡張機能を利用して、問題の原因となる可能性があります。
私はあなたがdmpファイルを正しくキャプチャする必要があるという答えに同意しますが、最近、このタイプの誤ってキャプチャされたdmpファイルでいくつかの実験を行いました。WinDbgを使用してSOS.dllにパッチを適用し、アーチチェックを削除しました。取得したものが有効かどうかは100％わかりませんが、少なくとも一部は有効であるように見えます... https://chentiangemalc.wordpress.com/2015/04/17/experimental-use-of-64- bit-dump-of-32-bit-net-process-in-windbg /