Crash report: https://crash-stats.mozilla.org/report/index/5484586d-8ac6-4929-a7a5-79a830210422

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp:3759
1 xul.dll IdleRequestExecutor::Release dom/base/nsGlobalWindowInner.cpp:497
2 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend comm/mailnews/compose/src/nsMsgSend.cpp:304
3 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend comm/mailnews/compose/src/nsMsgSend.cpp:283
4 xul.dll nsMsgComposeAndSend::Release comm/mailnews/compose/src/nsMsgSend.cpp:244
5 xul.dll CopyListener::~CopyListener comm/mailnews/compose/src/nsMsgCopy.cpp:41
6 xul.dll ArrayBufferInputStream::Release netwerk/base/BackgroundFileSaver.cpp:1077
7 xul.dll nsImapMailCopyState::~nsImapMailCopyState comm/mailnews/imap/src/nsImapMailFolder.cpp:7611
8 xul.dll nsImapMailCopyState::~nsImapMailCopyState comm/mailnews/imap/src/nsImapMailFolder.cpp:7608
9 xul.dll mozilla::dom::`anonymous namespace'::FileCreationHandler::Release dom/base/BodyConsumer.cpp:436

Similar to bug 1707004, this is being caused by a cycle collected object getting destroyed off the main threaad.

One of this bugs is the following.
https://searchfox.org/comm-central/rev/7dc9ab8a012750252902a311da4e0244285c39b8/mailnews/imap/src/nsImapProtocol.cpp#1150-1160

NS_IMETHODIMP nsImapProtocol::Run() {
  ..
  // shutdown this thread, but do it from the main thread
  nsCOMPtr<nsIRunnable> ev = new nsImapThreadShutdownEvent(m_iThread);
  if (NS_FAILED(NS_DispatchToMainThread(ev)))
    NS_WARNING("Failed to dispatch nsImapThreadShutdownEvent");
  m_iThread = nullptr;

  // Release protocol object on the main thread to avoid destruction of 'this'
  // on the IMAP thread, which causes grief for weak references.
  nsCOMPtr<nsIImapProtocol> releaseOnMain(this);
  NS_ReleaseOnMainThread("nsImapProtocol::this", releaseOnMain.forget());
  return NS_OK;

I guess this is race condition between main thread and IMAP thread.

IMAP thread is running Runnable by nsImapProtocol. But it is possible to run releaseOnMain for nsIImapProtocol before decrementting reference count of Runnable by nsImapProtocol on IMAP thread. So then the destructor of nsImapProtocol may run on IMAP thread that is shutting down.

So I think that nsImapThreadShutdownEvent should be dispatched to IMAP thread, not main thread, then it should dispatch other new Runnable to main thread for shutdown. nsImapThreadShutdownEvent and nsIImapProtocol->Release() shouldn't run until nsImapProtocol::Run is finished.

This is surely not a Windows only issue. A couple candidates for Mac

• NS_CycleCollectorSuspect3 | <name omitted> | nsMsgComposeAndSend::~nsMsgComposeAndSend bp-21232eda-d4dd-46ab-8992-9cbac0210729
• NS_CycleCollectorSuspect3 | nsArrayCC::Release bp-c650522d-a9d5-4cc0-b5f4-368db0210731

This is fixed by smtp-js bug 1661694. See bug 1517464 comment 69 for details