I've been getting this crash for a few months now (first encountered July 23). Here's how I encounter it: In the morning, I connect to my desktop remotely, using RDP, and update Firefox to the latest nightly and leave Firefox running. When at home (in the afternoon), without restarting Firefox, I open the Alert Box extension inbox, select the alerts I want the check, and click "Check for Updates." If an update is found, Alert Box will show a notification and play a bell sound. It is at the point of playing the sound that Firefox crashes. However, if I restart Firefox, when I get home, before clicking "Check for Updates," Firefox will not crash when the notification sound plays. If you install the extension, and go to its settings, you will see that the sound file is an OGG audio file. I have attached it, for convenience. I suppose there is a different set of APIs Firefox interfaces to when launched in a Remote Desktop environment vs a normal desktop environment. However this bug occurs only when at the desktop using a Firefox session that was launched during a Remote Desktop session. I encounter this with Windows 8 -- not sure if it would be reproducible with other OSes. My motherboard has an onboard Realtek ALC 892 8-Channel High Definition Audio CODEC. I have attached a WinDbg log bp-ff2191b4-f42f-43d2-9d57-fbae92131003 Crash signature: [@ `anonymous namespace''::wasapi_stream_init(cubeb*, cubeb_stream**, char const*, cubeb_stream_params, unsigned int, long (*)(cubeb_stream*, void*, void*, long), void (*)(cubeb_stream*, void*, cubeb_state), void*) ] Crashing Thread Frame Module Signature Source 0 gkmedias.dll `anonymous namespace'::wasapi_stream_init(cubeb *,cubeb_stream * *,char const *,cubeb_stream_params,unsigned int,long (*)(cubeb_stream *,void *,void *,long),void (*)(cubeb_stream *,void *,cubeb_state),void *) media/libcubeb/src/cubeb_wasapi.cpp 1 gkmedias.dll cubeb_stream_init media/libcubeb/src/cubeb.c 2 xul.dll mozilla::BufferedAudioStream::Init(int,int,mozilla::dom::AudioChannelType) content/media/AudioStream.cpp 3 xul.dll mozilla::MediaDecoderStateMachine::AudioLoop() content/media/MediaDecoderStateMachine.cpp 4 xul.dll nsRunnableMethodImpl<void ( nsCacheService::*)(void),void,1>::Run() obj-firefox/dist/include/nsThreadUtils.h 5 xul.dll nsThread::ProcessNextEvent(bool,bool *) xpcom/threads/nsThread.cpp 6 xul.dll nsThread::ThreadFunc(void *) xpcom/threads/nsThread.cpp 7 nss3.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c 8 nss3.dll pr_root nsprpub/pr/src/md/windows/w95thred.c 9 msvcr100.dll _callthreadstartex f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c 10 msvcr100.dll _threadstartex f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c 11 kernel32.dll BaseThreadInitThunk 12 ntdll.dll __RtlUserThreadStart 13 ntdll.dll _RtlUserThreadStart

Bug 866675 seems a most likely culprit.

A quick guess is that GetMixFormat is returning AUDCLNT_E_DEVICE_INVALIDATED, but since we're not handling errors returned there we try to deref a null mix_format pointer. Simple fix is to return on error there. But to make audio actually work, we probably need to call GetDefaultAudioEndpoint and fetch the *current* default rather than the one we cached at the time wasapi_init was called. I don't see a downside to removing the cached device from the cubeb context and fetching it on each wasapi_stream_init.

Comment on attachment 8339026 [details] [diff] [review] bug923992_v0.patch Review of attachment 8339026 [details] [diff] [review]: ----------------------------------------------------------------- Makes sense.

(In reply to Matthew Gregan [:kinetik] from comment #6) > https://hg.mozilla.org/integration/mozilla-inbound/rev/de7d74796ced Hi Matthew, had to backout this change due to very frequent orange on windows xp with this https://tbpl.mozilla.org/php/getParsedLog.php?id=31207506&tree=Mozilla-Inbound failure

That's pretty strange, this code is only active on Vista upwards. Oh, except wasapi_init is probably so simple now that it succeeds on XP (thus making it the chosen audio backend) and then fails later on. Initialize IMMDevice in wasapi_init to make sure WASAPI is actually available: https://tbpl.mozilla.org/?tree=Try&rev=56b136862c64

Looks better: https://tbpl.mozilla.org/?tree=Try&rev=12ae63704dd0 https://hg.mozilla.org/integration/mozilla-inbound/rev/41c241079f25

I can confirm this is fixed. Tested with holly nightly cset: http://hg.mozilla.org/projects/holly/rev/3831bd01eb41 Thanks

Thanks for the confirmation!