1780465 - Crash in [@ Microsoft::WRL::Details::DefaultModule<T>::`scalar deleting destructor']

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect, P1)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/f625e8c1-8260-4ebb-bf19-d174f0220702

Reason: EXCEPTION_BREAKPOINT

No crashing thread identified; using thread 0.

Top 10 frames of crashing thread:

0 inputhost.dll virtual void* Microsoft::WRL::Details::DefaultModule<1>::`scalar deleting destructor' 
1 inputhost.dll Microsoft::WRL::Details::StaticStorage<class Microsoft::WRL::Details::DefaultModule<1>, 0, int>::~StaticStorage<class Microsoft::WRL::Details::DefaultModule<1>, 0, int> 
2 ucrtbase.dll <lambda_f03950bc5685219e0bcd2087efbe011e>::operator 
3 ucrtbase.dll __crt_seh_guarded_call<int>::operator<<lambda_7777bce6b2f8c936911f934f8298dc43>, <lambda_f03950bc5685219e0bcd2087efbe011e>&, <lambda_3883c3dff614d5e0c5f61bb1ac94921c> > 
4 ucrtbase.dll execute_onexit_table 
5 ucrtbase.dll int __crt_state_management::wrapped_invoke<int  
6 inputhost.dll dllmain_crt_process_detach 
7 inputhost.dll dllmain_dispatch 
8 ntdll.dll LdrpCallInitRoutine 
9 ntdll.dll LdrShutdownProcess 

This appears to be one more odd shutdown crash:

• All the reports were caught by WER so we already uninstalled the exception handler when it happens
• We're shutting down, unloading DLLs apparently (all the minidumps have a pretty long list of unloaded DLLs at this point)
• The DLLs being unloaded are different, but the top frames are the same possibly pointing to the same root cause
• There's only one thread left, the main thread apparently

Comment 1

[David Parks [:handyman]]

I can't prove it but I believe that most of these crashes are simply that some DLLs don't properly ignore cleanup during the shutdown process and therefore crash because Windows puts the app into an unstable state after main exits. For example, there is only one thread here because Windows has force-killed the others. It's sometimes the case that such DLLs will cleanly terminate if you clean up for them first by destroying any of their objects that might be live. A few DLLs consistently appear in these crashes:

twinapi.dll
windows.ui.dll
inputhost.dll
windows.ui.immersive.dll
windows.globalization.dll
bcp47langs.dll
windows.storage.dll
coreuicomponents.dll

This list looks weird but one code source that brings in all of these is IVirtualDesktopManager (there are others). This object is used in a couple of places but the one in widget that is used by session saver intentionally leaks a reference for no good reason. I'm adding a ClearOnShutdown for this that seems to bring e.g. twinapi.dll's reference count to 0 during XPCOM shutdown, although the DLL is still unloaded after main (when this happens is Windows' prerogative). The hope is that the lack of actual objects to destroy will mitigate the DLL's failure to shutdown without doing anything. OTOH, it still runs a list of scheduled routines during its unloading -- creating ClassFactorys and releasing reference counts on objects. We can't make that ok but maybe we can reduce the volume of crashes.

Another option is to ignore these crashes if they are really pointless. They should be unimportant for the same reason the DLL is supposed to not manage memory. The building is being demolished. Don’t bother sweeping the floor and emptying the trash cans and erasing the whiteboards.

Comment 2

[David Parks [:handyman]]

Attachment: Bug 1780465: Release IVirtualDesktopManager used by session saver r=cmartin!

Windows' widget keeps an IVirtualDesktopManager around as long as the browser is running in order to support fast profile serialization. After the browser is done saving in shutdown, the service is no longer needed. Keeping it around also keeps other DLLs resident, which shouldn't be an issue but some of them have trouble cleanly terminating during LdrShutdownProcess (after background thread killing, etc). This doesn't necessarily cause the DLLs to unload before the end of main but freeing DLL-owned objects is usually the first step to convincing a DLL with issues to cleanly shut down.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.