Crash in [@ CDeviceEnumerator::OnPropertyValueChanged]

NEW
Unassigned

Status

()

defect
P3
critical
2 months ago
2 months ago

People

(Reporter: gsvelto, Unassigned)

Tracking

({crash})

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Reporter

Description

2 months ago

This bug is for crash report bp-d15e9dc2-d955-469f-ac4b-c34e80190331.

Top 8 frames of crashing thread:

0 mmdevapi.dll CDeviceEnumerator::OnPropertyValueChanged 
1 mmdevapi.dll CLocalEndpointEnumerator::OnMediaNotification 
2 mmdevapi.dll CMediaNotifications::OnMediaNotificationWorkerHandler 
3 ntdll.dll TppSimplepExecuteCallback 
4 ntdll.dll TppWorkerThread 
5 kernel32.dll BaseThreadInitThunk 
6 mozglue.dll static void patched_BaseThreadInitThunk mozglue/build/WindowsDllBlocklist.cpp:712
7 ntdll.dll RtlUserThreadStart 

Relatively low-volume crash, but many comments mention this happening when (un)plugging headphones or when using Bluetooth headsets so the relatively low rate might be because it's a corner-case that can be hit only when doing that. The code on the stack seems to be outside of our codebase though so I'm unsure if it's a problem we're causing or if it's a Windows/driver issue.

kinetik, can you make anything of this?

I saw no interesting other threads in the crash report in comment 0. My only interesting observation is that the crash rate was higher in 62 and then saw a drop in 63. Since then it's been steady.

I'll also note bug 1332789 which is similarly crashing in CDeviceEnumerator, though in a plugins process.

Flags: needinfo?(kinetik)
See Also: → 1332789

There's also bug 1507182 with CDeviceEnumerator related crashes, but in DestroyHWndNotificationThread and with more useful stacks.

Of the 20 or so crash stacks I looked at, only one seemed to have any media/playback related threads around. Quite a few had a PlayEventSound thread from the widget code, but that code looks fairly simple and may not be implicated. Possibly crashing during audio init/deinit, maybe racy?

The crashes seem to be a mix of content process and unclassified ("process type" field blank, non-e10s?).

We can register an IMMNotificationClient (which has a OnPropertyValueChanged callback) from dom/media/AudioNotificationSender.cpp, dom/plugins/ipc/PluginUtilsWin.cpp, and two places in cubeb: wasapi_collection_notification_client which only landed in 67 via bug 1527659, and wasapi_endpoint_notification_client which we stopped registering in content processes back in 61 via bug 1427011 to avoid mystery crashes in CAudioSessionControl::QueueStreamSwitch.

Not much to go on here, but based on the above perhaps we should focus on the two AudioNotification cases in Gecko...

Flags: needinfo?(kinetik)
See Also: → 1507182
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.