Crash in shutdownhang | CDeviceEnumerator::DestroyHWndNotificationThread
Categories
(Core :: Audio/Video, defect, P3)
Tracking
()
People
(Reporter: worcester12345, Unassigned)
References
Details
(Whiteboard: [tbird crash] [media-crash] [AudioNotification])
Crash Data
This bug was filed from the Socorro interface and is report bp-e5bfd614-6ebc-4b6a-a33e-0290a0181114. ============================================================= Top 10 frames of crashing thread: 0 ntdll.dll NtWaitForSingleObject 1 kernelbase.dll WaitForSingleObjectEx 2 kernel32.dll WaitForSingleObjectExImplementation 3 kernel32.dll WaitForSingleObject 4 mmdevapi.dll CDeviceEnumerator::DestroyHWndNotificationThread 5 mmdevapi.dll CDeviceEnumerator::SubEnumeratorUnregisterEndpointNotificationCallback 6 audioses.dll CCrossProcessServerOutputEndpoint::AddTimestampMessage 7 audioses.dll CAudioSessionControl::FinalRelease 8 audioses.dll ATL::CComObject<CAudioSessionControl>::~CComObject<CAudioSessionControl> 9 audioses.dll ATL::CComObject<CAudioSessionControl>::`vector deleting destructor' =============================================================
Comment 1•5 years ago
|
||
Nils, would you be able to look?
Comment 2•5 years ago
|
||
Looking at a 64 report [1] I see the stack: 0 ntdll.dll KiFastSystemCallRet 1 ntdll.dll ZwWaitForSingleObject 2 kernelbase.dll WaitForSingleObjectEx 3 kernel32.dll WaitForSingleObjectExImplementation 4 kernel32.dll WaitForSingleObject 5 mmdevapi.dll CDeviceEnumerator::DestroyHWndNotificationThread() 6 mmdevapi.dll CDeviceEnumerator::ReleaseHWndNotification() 7 mmdevapi.dll _chkstk 8 xul.dll void mozilla::audio::AudioNotification::~AudioNotification() 9 xul.dll void mozilla::StaticAutoPtr<mozilla::audio::AudioNotification>::Assign(class mozilla::audio::AudioNotification*) 10 xul.dll mozilla::KillClearOnShutdown(mozilla::ShutdownPhase) 11 xul.dll static nsresult mozilla::ShutdownXPCOM(class nsIServiceManager*) AudioNotification seems to be from bug 1361336. Chun-Min, could you take a look? [1] https://crash-stats.mozilla.com/report/index/6313fe10-fd59-4e02-931f-181e20181119
Comment 4•5 years ago
|
||
(In reply to C.M.Chang[:chunmin] from comment #3)
Sure. I'll take a look. Thanks!
reporter has a fair number of graphics crashes - https://mzl.la/31WSJoQ
Comment 5•5 years ago
|
||
The whole AudioNotification
things should be removed once the AudioIPC is enabled on Windows. The AudioNotification
is used to pass the device-change event over IPC.
Comment 6•4 years ago
|
||
Matthew, should the AudioNotification{Sender, Receiver}
be disabled in Nightly on Windows, given that the AudioIPC
is enabled in Nightly on Windows? IIRC, AudioNotification{Sender, Receiver}
is introduced when the content process has no way to receive the device-change event (bug 1361336) at the time it was implemented. Is it still needed after AudioIPC
is enabled? If there is no need, AudioNotificationReceiver
and AudioNotificationSender
should be disabled. The whole workflow is illustrated here.
Comment 7•4 years ago
|
||
Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().
Updated•4 years ago
|
Reporter | ||
Comment 8•3 years ago
|
||
(In reply to C.M.Chang[:chunmin] (PTO) from comment #5)
The whole
AudioNotification
things should be removed once the AudioIPC is enabled on Windows. TheAudioNotification
is used to pass the device-change event over IPC.
Was this enabled? Did it fix anything?
(In reply to Matthew Gregan [:kinetik] from comment #7)
Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().
Also, were these done?
Reporter | ||
Updated•3 years ago
|
Comment 9•3 years ago
|
||
(In reply to Worcester12345 from comment #8)
(In reply to C.M.Chang[:chunmin] (PTO) from comment #5)
The whole
AudioNotification
things should be removed once the AudioIPC is enabled on Windows. TheAudioNotification
is used to pass the device-change event over IPC.Was this enabled? Did it fix anything?
(In reply to Matthew Gregan [:kinetik] from comment #7)
Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().
Also, were these done?
Bug 1689516 tracks these changes.
Reporter | ||
Comment 10•3 years ago
|
||
(In reply to C.M.Chang[:chunmin] from comment #5)
The whole
AudioNotification
things should be removed once the AudioIPC is enabled on Windows. TheAudioNotification
is used to pass the device-change event over IPC.
(In reply to Matthew Gregan [:kinetik] from comment #7)
Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().
Has this been done?
Comment 11•2 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•