Crash report: https://crash-stats.mozilla.org/report/index/ed4cbc47-a71c-4513-b7ae-ebd460240706

Reason: STATUS_FATAL_USER_CALLBACK_EXCEPTION

Top 10 frames:

0  shell32.dll  CDefFolderMenu::GetCommandString(uint64_t, unsigned int, unsigned int*, char*...
1  explorerframe.dll  ContextMenu_GetCommandStringVerb(IContextMenu*, unsigned int, unsigned short*...
2  explorerframe.dll  CContextMenuOnContextMenuArrayNoDuplicateVerbs::QueryContextMenu(HMENU__*, un...
3  explorerframe.dll  CNscTree::_CreateContextMenu(IContextMenu*, _TREEITEM*)
4  explorerframe.dll  CNscTree::_OnContextMenu(short, short)
5  explorerframe.dll  CNscTree::_OnNotify(tagNMHDR*)
6  explorerframe.dll  CNscTree::v_WndProc(HWND__*, unsigned int, uint64_t, int64_t)
7  explorerframe.dll  CImpWndProc::s_WndProc(HWND__*, unsigned int, uint64_t, int64_t)
8  user32.dll  UserCallWinProcCheckWow(_ACTIVATION_CONTEXT*, int64_t (*)(tagWND*, unsigned i...
9  user32.dll  CallWindowProcW

This looks like an issue with the file picker but we've got two different crashes under the same signature and they might not be the same. The crash for the stack above happens only on nightly, was first seen with buildid 20240523205926 and has STATUS_FATAL_USER_CALLBACK_EXCEPTION as a reason. Crucially the last value returned by GetLastError() is present in the crashes and set to ERROR_MENU_ITEM_NOT_FOUND. This crash affects the utility process alone.

The second type of crash has a much higher volume, happens on release, involves the main process and has the following stack:

0  shell32.dll  CDefFolderMenu::GetCommandString(uint64_t, unsigned int, unsigned int*, char*...
1  explorerframe.dll  ContextMenu_GetCommandStringVerb(IContextMenu*, unsigned int, unsigned short*...
2  explorerframe.dll  CContextMenuOnContextMenuArrayNoDuplicateVerbs::QueryContextMenu(HMENU__*, un...
3  explorerframe.dll  CNscTree::_CreateContextMenu(IContextMenu*, _TREEITEM*)
4  explorerframe.dll  CNscTree::_OnContextMenu(short, short)
5  explorerframe.dll  CNscTree::_OnNotify(tagNMHDR*)
6  explorerframe.dll  CNscTree::v_WndProc(HWND__*, unsigned int, uint64_t, int64_t)
7  explorerframe.dll  CImpWndProc::s_WndProc(HWND__*, unsigned int, uint64_t, int64_t)
8  user32.dll  UserCallWinProcCheckWow(_ACTIVATION_CONTEXT*, int64_t (*)(tagWND*, unsigned i...
9  user32.dll  CallWindowProcW

In this case the crash has a plain EXCEPTION_ACCESS_VIOLATION_READ reason. Here's a few relevant comments from people experiencing the crash in the latter stack:

Friefox is crashing and is Windows file explorer (mostly when I try to open the right click menu) is also. Both crashed at the same time this time. If you google the Windows file explorer right click error/issue, this appears to have something to with browers alerts.

I right clicked on the "Google Drive" folder while trying to save a file.

I'm pretty sure this is a Windows problem because this has happened before with Explorer. I right clicked on a folder when saving a video and that caused the crash.

The File Explorer made it crash when I had it open in Firefox to upload a file. It's been crashing outside of Firefox too.

There are many more like this.

The crash for the stack above happens only on nightly [...] This crash affects the utility process alone.

The second type of crash has a much higher volume, happens on release, involves the main process [...]

For the record, this part is explained by the fact that, by default, the file-picker currently opens in utility processes in Nightly and in the main process in release.

This looks like an issue with the file picker

More accurately, this looks like an issue with one or more third-party DLLs that's causing a crash in the file picker. In particular, every such crash has nvshext.dll 1.2.0.1 loaded alongside multiple other DLLs — winrar's RarExt.dll being frequent but not universal. Given the details on the utility process crash, I suspect that nvshext.dll is adding (and/or checking for) a new right-click menu item in a way that isn't compatible with any other DLL also adding a right-click menu item.

(In reply to Ray Kraesig [:rkraesig] from comment #1)

For the record, this part is explained by the fact that, by default, the file-picker currently opens in utility processes in Nightly and in the main process in release.

I should have guessed that much.

More accurately, this looks like an issue with one or more third-party DLLs that's causing a crash in the file picker. In particular, every such crash has nvshext.dll 1.2.0.1 loaded alongside multiple other DLLs — winrar's RarExt.dll being frequent but not universal. Given the details on the utility process crash, I suspect that nvshext.dll is adding (and/or checking for) a new right-click menu item in a way that isn't compatible with any other DLL also adding a right-click menu item.

An NVidia shell extension!? 🤦

FYI we have crashes all the way to driver version 32.0.15.5585 which corresponds to this very recent WHQL driver. Chances are that all versions are affected.

(In reply to Gabriele Svelto [:gsvelto] from comment #2)

An NVidia shell extension!? 🤦

Yes, sadly. In fact, if you google nvidia shell extension, most of the top dozen hits are about it causing crashes.

(In reply to Gabriele Svelto [:gsvelto] from comment #3)

FYI we have crashes all the way to driver version 32.0.15.5585 which corresponds to this very recent WHQL driver. Chances are that all versions are affected.

I expect the shell extension and driver version are at least mostly independent. The only DLL version I saw was 1.2.0.1, even in the oldest crashes.

My wife's machine has an Nvidia graphics cards so I checked it. It has the file, it's version 1.2.0.1 and it's from 2022 even though the driver is more recent. This is probably some half-unmaintained bit of Nvidia's machinery, I wonder if we have a contact we can reach out to.

I don't see a contact there on our third-party outreach doc, I'll try to find a good one and send an email. Thanks!

known NVIDIA issue that hasn't been fixed for years?
https://answers.microsoft.com/en-us/windows/forum/all/right-clicking-a-drive-in-windows-explorer-causes/f407b0f2-f874-421d-a857-16e377da556b is from 2015.

Emailed our NVIDIA contact about this issue.