Я пытаюсь проанализировать дамп памяти, полученный от одного из моих конечных пользователей после зависания в моем приложении. Кажется, это связано с частью воспроизведения моего приложения. Я считаю, что участвуют два потока: основной поток, который собирается начать воспроизведение звука, и поток обновления, который перебирает звуки в связанном списке, чтобы постоянно обновлять их состояние. Однако я не понимаю, каким может быть источник зависания.
Мои знания по WinDbg ограничены, но мне удалось выяснить, что зависание происходит внутри метода SetLoop звуковой библиотеки (особенно в статическом звуковом коде). Я использую DirectSound, и в этом случае приложение работает на 32-битной Windows 7 (я сам занимаюсь разработкой на XP, где у меня никогда не возникало подобных проблем). Класс static sound блокирует критическую секцию, прежде чем проверяет, воспроизводится ли звук, и, если это не так, устанавливает флаг петли либо в true, либо в false. В этом случае основной поток вызывает SetLoop, чтобы установить для него значение false, потому что он хочет воспроизвести звук в не зацикленном состоянии. Я вижу, что во время зависания основной поток застревает в вызове EtwEventEnabled в ntdll.dll, который, очевидно, выполняется методом SetLoop статического класса звука. Интересно, застрял ли он в вызове EnterCriticalSection или где-то немного дальше, когда он вызывает метод GetStatus DirectSound для вторичного буфера? Вот где мои знания об анализе дампов памяти заканчиваются, и я был бы очень признателен, если бы кто-то нашел время, чтобы посмотреть на дамп.
Вот ссылка на дамп с символами приложения:
https://dl.dropbox.com/u/5121962/hangdump.zip
Заранее большое спасибо за любую помощь.
Два потока (один WinMain
) ждут на том же критическом разделе 03cb6ffc
у которого нет владельца.
смотреть на StaticSound::Update
а также StaticSound::SetLoop
, Возможно, поток, который в данный момент завершается, все еще владеет критическим разделом. Попробуй использовать Проверка приложения with Locks Stop Details — проверяет правильность использования критических секций.
0:000> !analyze -hang -v
[...]
BUGCHECK_STR: HANG
[...]
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- --------------------------
0 768.d1c Critical Section (Self)
WAIT_CHAIN_COMMAND: ~0s;k;;
BLOCKING_THREAD: 00000d1c
DEFAULT_BUCKET_ID: APPLICATION_HANG_SELF_Unowned_CriticalSection
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_SELF_Unowned_CriticalSection
LAST_CONTROL_TRANSFER: from 77d56a24 to 77d57094
[...]
0:000> !locks
CritSec +13af7d0 at 013af7d0
WaiterWoken No
LockCount 0
RecursionCount 1
OwningThread 10a8
EntryCount 0
ContentionCount 2b7
*** Locked
CritSec +3cb6ffc at 03cb6ffc
WaiterWoken No
LockCount 2
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount d
*** Locked
0:000> ~*
. 0 Id: 768.d1c Suspend: 0 Teb: 7ffde000 Unfrozen
Start: pontefract_timer!WinMainCRTStartup (01299030)
Priority: 0 Priority class: 32 Affinity: f
[...]
4 Id: 768.10a8 Suspend: 0 Teb: 7ffdb000 Unfrozen
Start: pontefract_timer!_threadstartex (012ae09f)
Priority: 2 Priority class: 32 Affinity: f
[...]
0:004> kb
ChildEBP RetAddr Args to Child
021af9b4 77d56a24 77d42278 000002f0 00000000 ntdll!KiFastSystemCallRet
021af9b8 77d42278 000002f0 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
021afa1c 77d4215c 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0x13e
021afa44 012882c2 03cb6ffc 013af7cc 00326ee8 ntdll!RtlEnterCriticalSection+0x150
021afa60 0128a1ed 021afa8c 021afa80 013af810 pontefract_timer!StaticSound::Update+0x12
021afa84 012ae079 013af700 73a14e26 00000000 pontefract_timer!UpdaterTick+0x7d
021afabc 012ae103 00000000 021afad4 7750ed6c pontefract_timer!_callthreadstartex+0x1b
021afac8 7750ed6c 013af810 021afb14 77d7377b pontefract_timer!_threadstartex+0x64
021afad4 77d7377b 013af810 6b63b5bd 00000000 kernel32!BaseThreadInitThunk+0xe
021afb14 77d7374e 012ae09f 013af810 00000000 ntdll!__RtlUserThreadStart+0x70
021afb2c 00000000 012ae09f 013af810 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> kb
ChildEBP RetAddr Args to Child
0020c39c 77d56a24 77d42278 000002f0 00000000 ntdll!KiFastSystemCallRet
0020c3a0 77d42278 000002f0 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
0020c404 77d4215c 00000000 00000000 774f8e38 ntdll!RtlpWaitOnCriticalSection+0x13e
0020c42c 012881af 03cb6ffc 00000000 03cb6ff8 ntdll!RtlEnterCriticalSection+0x150
0020c440 0128682c 00000000 00000000 00000000 pontefract_timer!StaticSound::SetLoop+0xf
0020c460 012616ac 00000000 00000000 01765bac pontefract_timer!DeviceManager::SetLoop+0x6c
0020c474 0121a2ce 01a46ddc 00000000 0178ea9c pontefract_timer!BgtSound::play+0x6c
0020c61c 01219d02 0178ea9c 01765bf4 01a46ddc pontefract_timer!CallSystemFunctionNative+0x42e
0020c64c 0121d450 00000000 00000000 0178ea9c pontefract_timer!CallSystemFunction+0xd2
0020c6d4 0121c276 01a46dfc 77b6ea11 00000000 pontefract_timer!asCContext::ExecuteNext+0x930
0020c708 0127a293 719b431a 0020f780 00000000 pontefract_timer!asCContext::Execute+0x1d6
0020f780 0127a1d5 719b4c6a 77b1f2a9 0010000c pontefract_timer!execute+0x83
0020f8f0 0127acff 77b1f2a9 77b18d02 0020f958 pontefract_timer!RunApplication+0x805
0020f908 0127b085 0020f908 0127b339 00000000 pontefract_timer!run_script+0x9f
0020f910 0127b339 00000000 00000000 7ffdf000 pontefract_timer!main_game+0x35
0020f958 01298fdd 01210000 00000000 00361f32 pontefract_timer!WinMain+0x2a9
0020f9e8 7750ed6c 7ffdf000 0020fa34 77d7377b pontefract_timer!__tmainCRTStartup+0x11a
0020f9f4 77d7377b 7ffdf000 6959b49d 00000000 kernel32!BaseThreadInitThunk+0xe
0020fa34 77d7374e 01299030 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70
0020fa4c 00000000 01299030 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b
Вы можете попробовать проанализировать дамп с помощью Microsoft Инструмент диагностики отладки — Кажется, это подтверждает то, что вы подозреваете, но без вашего знания кода или PDB сборки Release для вашего exe, я не могу получить больше информации из стека вызовов.
В отчете (вы можете выполнить полный анализ самостоятельно с помощью инструмента) участвуют две темы — сводка следующая:
Стеки вызовов потоков 0 и 4 следующие:
.. а также …
Это может дать вам больше информации, чтобы вы снова переехали …
Надеюсь, это поможет,
Роджер