This bug is for crash report bp-5d6da799-4b47-4187-acda-f810c0200703.

Top 10 frames of crashing thread:

0 ntdll.dll NtWaitForAlertByThreadId 
1 ntdll.dll RtlSleepConditionVariableSRW 
2 kernelbase.dll SleepConditionVariableSRW 
3 mozglue.dll mozilla::detail::ConditionVariableImpl::wait mozglue/misc/ConditionVariable_windows.cpp:50
4 xul.dll mozilla::TaskController::GetRunnableForMTTask xpcom/threads/TaskController.cpp:242
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1148
6 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:327
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309
9 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

This seems to have started with landing https://phabricator.services.mozilla.com/D74673, nightly build id 20200701093012.

Set release status flags based on info from the regressing bug 1606706

This is not a new crash but just because the intermediate stack frame changed, not sure what the 'old equivalent bug' is, having a hard time figuring out how to search for it in crash stats :).

content shutdown hang reports.

I was able to reproduce this crash with NVDA using the steps in this Github issue. My crash report is:
bp-1e9221ac-bcac-415a-b4bb-129a10200708

Jamie, this may or may not be related to bug 1650590. It also is a content process crash, but unlike the other, it generates crash reports.

Here is another potential example for the bug in the ARIA Authoring practices example for a combobox date picker ARIA APG issue 1440:

My patch for bug 1650590 does appear to fix this.

This is fixed by bug 1650590, confirmed in Firefox Nightly 80.0a1 (20200709213735).

Bug 1650590 has landed on beta and will be in 79.0b6.

Verified that the fix landed properly on 79.0b6. The above mentioned test case no longer crashes in 79.0b6 with both NVDA and JAWS.

I am not seeing a decrease of crashes with this signature since the patch landed on Nightly 6 days ago, it is on the contrary increasing with +200 crashes per day.

Yes, this still happens on recent Nightly builds. Maybe there are different root causes for this?

Possibly. The situation that caused crashes with this signature for me, are definitely fixed by bug 1650590. But perhaps there are other areas of the Windows IPC code that AccessibleHandler doesn't touch, that uses the wrong MemAlloc/MemFree combination in some circumstances. Feel free to take some leads from the patch and comment in bug 1650590.

I don't think this crash necessarily relates to memory corruption at all or even Windows IPC. I'm not familiar with the task scheduler code, but I'm guessing this is a generic signature for a content process hang where the main thread was last waiting for a task; i.e. the hang occurred for some reason other than the main thread getting stuck. The fix discussed in comment 4, comment 6, etc. deals with an a11y specific instance of this. Clearly, there are other instances.