アプリケーションでハングが発生した後にエンドユーザーの1人から受け取ったメモリダンプを分析しようとしています。私のアプリケーションのオーディオ再生部分に関連しているようです。サウンドの再生を開始しようとしているメインスレッドと、リンクリスト内のサウンドを繰り返して状態を継続的に更新するアップデータスレッドの2つのスレッドが関係していると思います。ただし、ハングの原因が何であるかはわかりません。
私のWinDbgの知識は限られていますが、ハングはオーディオライブラリのSetLoopメソッド内(具体的には静的サウンドコード)で発生しているように見えることがわかりました。私はDirectSoundを使用しており、この場合、アプリケーションはWindows 7 32ビットで実行されています(このような問題が発生したことのないXPで自分で開発しています)。静的サウンドクラスは、サウンドが再生されているかどうかを確認する前にクリティカルセクションをロックし、再生されていない場合は、ループフラグをtrueまたはfalseに設定します。この場合、メインスレッドはSetLoopを呼び出して、サウンドをループしていない状態で再生するため、falseに設定します。ハングしたときに、静的サウンドクラスのSetLoopメソッドによって作成されたと思われるntdll.dllのEtwEventEnabledの呼び出しでメインスレッドがスタックしていることがわかります。EnterCriticalSection呼び出しでスタックしているのでしょうか、それとも、DirectSoundのセカンダリバッファーのGetStatusメソッドを呼び出したときに少し下の場所でスタックしているのでしょうか。ここで、メモリダンプ分析の知識が不足しているので、誰かが時間をかけてダンプを確認していただければ幸いです。
アプリケーション固有の記号が付いたダンプへのリンクは次のとおりです: https ://dl.dropbox.com/u/5121962/hangdump.zip
助けてくれてありがとう。