それ以外は、VSデバッガーでアプリケーションを実行していると仮定すると、それが発生したときに再現できるかどうかはわかりません（この特定のアプリケーションを問題なく1〜2週間使用しています）。デッドロックが発生した後、デバッグに取り掛かる必要がありますか？プログラムを一時停止して、別のスレッドが発生したときの場所を確認すると、コールスタックに到達できる可能性があると思いましたが、[一時停止]をクリックすると、アプリケーションを強制終了するまでVisualStudioもデッドロックに陥りました。
ソースツリーを参照して潜在的な問題を見つける以外の方法はありますか？問題が発生した後、コールスタックにアクセスして、問題がどこにあるかを確認する方法はありますか？役立つかもしれない他のツール/ヒント/トリックはありますか？
あなたがしたことは正しい方法でした。Visual Studioもデッドロックする場合、それは時々起こります。他に問題がない限り、それは運が悪いだけです。
アプリケーションをデバッグするために、デバッガーでアプリケーションを実行する必要はありません。アプリケーションを正常に実行し、デッドロックが発生した場合は、後でVSを接続できます。Ctrl + Alt + Pでプロセスを選択し、デバッガーの種類を選択して[添付]をクリックします。異なるデバッガタイプのセットを使用すると、VSがクラッシュするリスクを減らすことができます（特にネイティブコードをデバッグしない場合）
デッドロックには2つ以上のスレッドが含まれます。アプリケーションのデッドロックに気付いたので、おそらく最初のスレッド（おそらくUIスレッド）を知っているでしょう。今、あなたは他のものを見つける必要があるだけです。アーキテクチャの知識があれば、簡単に見つけることができます（たとえば、他のスレッドが同じロックを使用している、UIと対話しているなど）
VSがまったく機能しない場合は、いつでもwindbgを使用できます。ここからダウンロード：http：//www.microsoft.com/whdc/devtools/debugging/default.mspx
次の順序でさまざまなアプローチを試してみます。
まず、コードを調べてスレッドセーフ違反を探し、クリティカル領域がクリティカル領域をロックしようとする他の関数を呼び出さないことを確認します。
スレッドのアクティビティを視覚化するために手に入るツールを使用してください。私は社内のperlスクリプトを使用して、作成したOSログを解析し、すべてのコンテキストスイッチをグラフ化して、スレッドがプリエンプトされたときに表示します。
適切なツールが見つからない場合は、ログを記録して、デッドロックが発生する前に実行されていた最後のスレッドを確認してください。これにより、問題が発生する可能性のある場所に関する手がかりが得られます。オブジェクトに独自のスレッドがある場合など、ロックメカニズムに一意の名前がある場合は、そのスレッドを管理するためだけに専用のセマフォまたはミューテックスを作成すると役立ちます。
これがお役に立てば幸いです。幸運を！
他の場所と同じように、すべてのデッドロックをキャッチする「特効薬」ツールはありません。さまざまなスレッドがリソースを取得する順序がすべてなので、順序に違反した場所を見つけることが仕事です。通常、Visual Studioまたは他のデバッガーはスタックトレースを提供し、不一致がどこにあるかを見つけることができます。DevPartner Studioはデッドロック分析を提供しますが、前回チェックしたときに誤検知が多すぎました。一部の静的分析ツールでは、潜在的なデッドロックも検出されます。
それ以外は、アーキテクチャをまっすぐにしてリソース取得順序を適用するのに役立ちます。たとえば、階層化は、下位レベルのロックの前に上位レベルのロックが取得されるようにするのに役立ちますが、コールバックには注意してください。
Intel（R）Parallel Inspectorなどのさまざまなプログラムを使用できます：
http ：//software.intel.com/en-us/intel-parallel-inspector/
このようなプログラムは、潜在的なデッドロックのあるコード内の場所を表示する可能性があります。ただし、料金を支払うか、評価期間のみを使用する必要があります。このような無料のツールがあるかどうかわからない。