Open Bug 1453050 Opened 4 years ago Updated 7 days ago
Crash in guard
_dispatch _icall _nop
This bug was filed from the Socorro interface and is report bp-c556234a-ca05-4735-b1dc-83dfa0180409. ============================================================= Came across this Windows plugin/content crash during Nightly (61) triage. Most of the reports are marked as potentially exploitable. There are also around 30 crashes in 59.0.2 and a few as far back as 55. Top 9 frames of crashing thread: 0 audioses.dll guard_dispatch_icall_nop 1 audioses.dll CLockedList<ATL::CComPtr<IAudioSessionEvents>, 0, 1>::ForEachEntry 2 audioses.dll CAudioSessionControl::OnAudioSessionEvent 3 audioses.dll CAudioSessionControl::CAudioSessionNotificationDelegator::OnMediaNotification 4 mmdevapi.dll CMediaNotifications::OnMediaNotificationWorkerHandler 5 ntdll.dll TppSimplepExecuteCallback 6 ntdll.dll TppWorkerThread 7 kernel32.dll BaseThreadInitThunk 8 ntdll.dll RtlUserThreadStart =============================================================
Tom: this kind of looks like a CFG check, except I thought that didn't report to crash-stats? In any case this is crashing wholly in someone else's modules, some kind of audio thing. Bad driver? The crashing function sounds like it's a safety check so probably not worrying?
So guard_dispatch_icall_nop is supposedly just 'jmp rax' and while it may be related to CFG, I am not certain this is actually a CFG failure. In theory CFG failures don't report to crash-stats and they supposedly look like > Unhandled exception at 0x77C46170 (ntdll.dll) in firefox.exe: RangeChecks instrumentation code detected an out of range array access.
Not crashing in our code. Not sure it needs tracking as a top crash but that's probably the best way to handle this.
Callstacks are all over the place here. May or may not be playback related.
Component: Audio/Video → Audio/Video: Playback
Crash Signature: [@ guard_dispatch_icall_nop]
You need to log in before you can comment on or make changes to this bug.