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:

• <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
• <System>
  <Provider Name="Application Error" />
  <EventID Qualifiers="0">1000</EventID>
  <Level>2</Level>
  <Task>100</Task>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2020-10-24T13:08:22.372506800Z" />
  <EventRecordID>19589</EventRecordID>
  <Channel>Application</Channel>
  <Computer>DESKTOP-FQ35S98</Computer>
  <Security />
  </System>
• <EventData>
  <Data>firefox.exe</Data>
  <Data>84.0.0.7602</Data>
  <Data>5f940f9b</Data>
  <Data>ntdll.dll</Data>
  <Data>10.0.14393.3986</Data>
  <Data>5f77fd0d</Data>
  <Data>c0000005</Data>
  <Data>000000000003469c</Data>
  <Data>824</Data>
  <Data>01d6aa06c00a6e80</Data>
  <Data>C:\Program Files\Firefox Nightly\firefox.exe</Data>
  <Data>C:\WINDOWS\SYSTEM32\ntdll.dll</Data>
  <Data>9f952e82-7c06-430e-acb3-db4ea80f36b3</Data>
  <Data />
  <Data />
  </EventData>
  </Event>
  I try to use windbg and mozregression.
  Tested autoland build: 2a46f29c (verdict: g)
  app_name: firefox
  build_date: 2020-10-21 00:08:25.137000
  build_file: C:\Users\amix.mozilla\mozregression\persist\2a46f29c8cdd--autoland--target.zip
  build_type: integration
  build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/cMjDIhv6QXumrBVi86wxhQ/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
  changeset: 2a46f29c8cdd6f6269483e86c6e21e649ffa7127
  pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=e88986658685538d5ab62d66c31e183b43e813ce
  repo_name: autoland
  repo_url: https://hg.mozilla.org/integration/autoland
  task_id: cMjDIhv6QXumrBVi86wxhQ
  Tested autoland build: 4c3e6fb9 (verdict: b)
  app_name: firefox
  build_date: 2020-10-21 00:24:50.430000
  build_file: C:\Users\amix.mozilla\mozregression\persist\4c3e6fb95aa6-pgo--autoland--target.zip
  build_type: integration
  build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Okfv9Gf6T-GgBvUhGNEU1g/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
  changeset: 4c3e6fb95aa6184651f215d466e702ff7d1660d3
  pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3
  repo_name: autoland
  repo_url: https://hg.mozilla.org/integration/autoland
  task_id: Okfv9Gf6T-GgBvUhGNEU1g

Differential Revision: https://phabricator.services.mozilla.com/D93709

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.

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
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3

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.

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.

https://hg.mozilla.org/mozilla-central/rev/4dfedfe6d65c