This morning Opus crashed several times with all listers disappearing instantly. The last time Opus was able to generate a crash dump before vanishing. It's really odd: all I did was opening a folder in the file display.
I am sending the dump via mail.
The crashes are reproducible. The folder contains some .url files with long names, some with funny characters. Even File Explorer crashes in an instant when I try to rename them. Wow!
A while ago I temporarily moved my system SSD to my new PC to clone it. The gap in tech between the two PCs is quite wide, a jump from Intel 4570 to AMD 5600G. The system drivers Win10 had to install might be involved in the crashes, although the SSD has been back for about three weeks.
It looks like something has corrupted the memory heap, but I can't tell if it's Opus itself or a shell extension or similar from the dmp file.
If it has started happening recently, I might suspect the PowerToys Image Resizer shell extension, as that DLL is loaded into the process and has a very recent date (2nd Feb). But it could also be innocent and a coincidence.
It's possible the DLL responsible was unloaded before the crash/dmp happened, but here is a list of other DLLs in the process (ignoring the Opus and Windows ones), in case any are recent installs/updates and worth checking/eliminating:
C:\Program Files (x86)\Common Files\AWS\2.7.2.738\ASUSWSContextMenu.dll
C:\Program Files (x86)\Common Files\AWS\2.7.2.738\ASUSWSShellExt64.dll
C:\Program Files (x86)\Common Files\AWS\2.7.2.738\eCaremeDLL.dll
C:\Program Files (x86)\Common Files\AWS\2.7.2.738\log4net.dll
C:\Program Files (x86)\Common Files\AWS\2.7.2.738\LogicNP.EZShellExtensions.dll
C:\Program Files\Bonjour\mdnsNSP.dll
C:\Program Files\Box\Box\BoxShellExt-2.23.422.dll
C:\Program Files\Box\Box\BoxShellExtShim-2.23.422.dll
C:\Program Files\Microsoft OneDrive\22.002.0103.0004\FileSyncShell64.dll
C:\Program Files\PowerToys\modules\ImageResizer\PowerToys.ImageResizerExt.dll
C:\Program Files\WinMerge\ShellExtensionX64.dll
C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2111.5-0\MpOAV.dll
C:\Windows\System32\cbfsconnectNetRdr2017.dll
C:\Windows\System32\cbfsShellHelper20.dll
The last two are in System32 dir don't seem to be part of Windows. I think they are related to CBFS Connect 2020 Java Edition Reference which creates virtual filesystems for something else. (Maybe Box uses that, since it's also in the process? But that's just a guess based on what it does.)
Something has also loaded the VisualBasic.Net runtime into the process, FWIW. (Possibly the ASUS stuff, as it's also using log4net.) Not that unusual to have .net stuff in the process these days, but maybe worth mentioning, and VB.Net itself is more rare.
You may be able to get a DMP that pinpoints the problem by turning on Page Heap debugging, which makes Windows test the integrity of the memory heap more often. With that on, anything corrupting memory will often crash at the moment of the corruption (so the problem code is in the dmp file) rather than later on (when random code trips over the mess that was left by something else). Hopefully, with PageHeap turned on you'll get a DMP file every time and it'll point to the code causing the corruption.
If you want to try that, you need GFlags.exe from the Debugging Tools for Windows:
I have a couple of Opus buttons which turn it on and off for dopus.exe:
@admin
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" -p /enable dopus.exe /full /protect
@admin
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" -p /disable dopus.exe
(Of course, use an admin Command Prompt to run the commands instead if Opus isn't stable enough to run the commands.)
Opus needs to be exited (File > Exit Directory Opus) and restarted for the Page Heap change to take effect.
When pageheap is enabled, it will slow the process down a lot, so turn it off and restart Opus when you're done.
You might also want to run this in a button just before restarting Opus:
@admin: Rundll32.exe fthsvc.dll,FthSysprepSpecialize
That will tell Windows to clear any flags that make processes use the Fault Tolerant Heap, which can kick in if something in a process corrupts memory. The Fault Tolerant Heap makes crashes less likely, but it can also hide problems and make them harder to track down.