Closed Bug 1673194 Opened 8 months ago Closed 8 months ago

Startup crash on ntdll.dll


(Core :: Audio/Video: Playback, defect, P1)




84 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- unaffected
firefox82 --- unaffected
firefox83 --- unaffected
firefox84 + fixed


(Reporter: zeigpcim, Assigned: bobowen, NeedInfo)


(Depends on 1 open bug, Regression)


(Keywords: regression)


(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36

Steps to reproduce:

Differential Revision:

Actual results:

Windows event log full of app errors since 22.10.2020.

Assuming it's a duplicated of bug 1672523.

Are you using a software called Digital Guardian? If so, it should be fixed by installing the latest version of that software.

Closed: 8 months ago
Component: Untriaged → Other
Product: Firefox → External Software Affecting Firefox
Resolution: --- → DUPLICATE
Version: Firefox 84 → unspecified
Duplicate of bug: 1672523

No i do not. On VirtualBox with clean windows all the same. 82 release and 83 beta works just fine.

(In reply to zeigpcim from comment #2)

No i do not. On VirtualBox with clean windows all the same. 82 release and 83 beta works just fine.

Sorry, it wasn't exactly clear from the first comment, since all the text is packed together.

I guess it's a different bug then, given it started happening too late for you.

There's a pushlog pointing to bug 1595994, although I'm not exactly sure why it would cause a startup cache

Component: Other → Untriaged
Ever confirmed: true
Product: External Software Affecting Firefox → Firefox
Resolution: DUPLICATE → ---
Summary: unknown reason crush → Startup crash on ntdll.dll
Ever confirmed: false
Component: Untriaged → Audio/Video: Playback
Keywords: regression
Product: Firefox → Core
Regressed by: 1595994

It's crushes not only on startup, but on any site with media content (e.g. youtube, twitch, bandcamp).

Do you get any crashes showing in about:crashes?

Can you try navigating to about:config and setting media.rdd-wmf.enabled to false and confirm if that stops the crash or not?

For moz folks, looks like this is a result of moving WMF decoding into the RDD. At line 1315 of the log from comment 0 we can see the stack of a media thread that appears responsible. We're trying to create a decoder (mozilla::MFTDecoder::Create) which eventually calls into msmpeg2vdec which then crashes.

Flags: needinfo?(zeigpcim)

I looked at an issue on bdahl's machine that I'm pretty sure matches this bug.

msmpeg2vdec.dll creates JIT code, but the MITIGATION_DYNAMIC_CODE_DISABLE in the RDD process prevents their VirtualProtect from marking the code as executable, so we get an NX failure when trying to call it. Then that tries to call the exception handler that msmpeg2vdec registered for this region, but something goes wrong and throws nested exceptions forever until we exhaust the stack.

My understanding is that the dynamic code mitigation used to be on for all RDD processes, but bug 1595994 ran into issues on 32-bit and disabled the mitigation on that platform. The mitigation was left enabled for 64-bit processes because at first glance it seemed like those builds were OK, but the msmpeg issue suggests that we need to disable the mitigation on 64-bit too.

I'm going to remove the mitigation for now.

I think this pushes us even further towards the need for more than one RDD process, so that we can improve the sandbox for other decoders.

Assignee: nobody → bobowencode
Ever confirmed: true
Priority: -- → P1
Depends on: 1674070
Pushed by
Remove dynamic code disable for 64-bit RDD process. r=jya
Closed: 8 months ago8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch
See Also: → 1381050
You need to log in before you can comment on or make changes to this bug.