Я пытаюсь проанализировать дамп памяти, полученный от одного из моих конечных пользователей после зависания моего приложения. Кажется, это связано с частью воспроизведения звука моего приложения. Я считаю, что задействованы два потока: основной поток, который вот-вот начнет воспроизводить звук, и поток обновления, который перебирает звуки в связанном списке, чтобы постоянно обновлять их состояние. Однако я не понимаю, в чем может быть причина зависания.
Мои знания WinDbg ограничены, но мне удалось выяснить, что зависание, похоже, происходит внутри метода SetLoop аудиобиблиотеки (в частности, в коде статического звука). Я использую DirectSound, и в этом случае приложение работает на 32-разрядной версии Windows 7 (я сам разрабатываю на XP, где у меня никогда не было такой проблемы). Класс статического звука блокирует критическую секцию, прежде чем проверять, воспроизводится ли звук, и, если нет, устанавливает флаг цикла в значение true или false. В этом случае основной поток вызывает SetLoop, чтобы установить для него значение false, потому что он хочет воспроизводить звук в незацикленном состоянии. Я вижу, что в момент зависания основной поток застрял в вызове EtwEventEnabled в ntdll.dll, который, по-видимому, сделан методом SetLoop класса статического звука. Интересно, застрял ли он в вызове EnterCriticalSection или где-то еще ниже, когда он вызывает метод DirectSound GetStatus для вторичного буфера? Вот где мои знания об анализе дампа памяти терпят неудачу, и я был бы очень признателен, если бы кто-нибудь нашел время, чтобы посмотреть на дамп.
Вот ссылка на дамп со специальными символами приложения: https://dl.dropbox.com/u/5121962/hangdump.zip
Большое спасибо заранее за любую помощь.
