So what made you think Opus was involved? If it's a crash that happens sometimes and not others, seeing it not happen after disabling something doesn't really prove that thing was involved (although it could be).
Is the post on the Everything forum based on your information or was that independently worked out? I've posted (pending moderation) a reply there asking for more information as well.
This was the error I repeated multiple times:
Descrizione
Percorso dell'applicazione che ha generato l'errore: C:\Windows\explorer.exeFirma del problema
Nome evento problema: APPCRASH
Nome applicazione: explorer.exe
Versione applicazione: 10.0.19041.2546
Timestamp applicazione: 265bf422
Nome modulo con errori: windows.storage.dll
Versione modulo con errori: 10.0.19041.2311
Timestamp modulo con errori: 02ad31cf
Codice eccezione: c0000005
Offset eccezione: 0000000000160abf
Versione SO: 10.0.19045.2.0.0.256.48
ID impostazioni locali: 1040
Informazioni aggiuntive 1: d7f5
Ulteriori informazioni 2: d7f572e53e17f2d5b17660baff4a516f
Ulteriori informazioni 3: 4c92
Ulteriori informazioni 4: 4c92e0f3e9c2e4b251603153b011e83b
No it was opened by Everything author as you can see, after I reported the issue i complete good faith of course.
Nothing in that points to Opus.
Windows.storage.dll is part of Windows. (I've seen crashes with that in the stack trace before myself, which didn't involve Opus. Those looked like a bug in Windows where Microsoft seemed to be passing a null pointer to their own API that doesn't check for nulls. I don't know if that's what is happening here, though, since seeing more requires a DMP of the crash.)
So what made you think Opus was involved? If it's a crash that happens sometimes and not others, seeing it not happen after disabling something doesn't really prove that thing was involved (although it could be).
We're talking about the original thread bug, right? Because it involved dopuslib.dll therefore it was highly suspect.
Yep, I'm sorry if I can't reproduce it anymore (2nd bug) after DOpus reinstall. If you want to move it to another thread "Conflict with Everything (Voidtools)?" or the like...
I'm talking about the crash involving Everything.
This is why a separate thread should be used for unrelated issues. It's confusing and hard to follow otherwise.
Ok. Feel free if you want to delete 2nd bug related msgs... In case I will reproduce it I'll open a new separate thread in the future.
I'll wait to see if the Everything author can give us some more detail on the other forum about the new issue. Can't easily split this thread because individual posts talk about both issues at once.
Here we go! I can reproduce the crash with Everything again! Tell me what should I do to submit a useful report... What did I change? Just added a bunch of favorite paths:
From the follow-ups on the Everything forum, it sounds like all the information came from you and they were just re-posting it to help other people?
In which case, I don't see anything that connects Opus to the File Explorer crash when dragging fonts out of Everything to the desktop.
It seem this crash (and at least some of the others) are happening on your system sometimes and not others, and nothing is tying most of the events to Opus so far, other than pure conjecture. If it only happens sometimes, it doesn't implicate Opus if you disable something in Opus and then it doesn't happen the next time you do that thing. It may just be chance, since it isn't happening every time with or without that part of Opus enabled. Especially if it involves things like the ShellExecute hook which shouldn't be in play when doing a file copy (unless something quite unusual is going on).
Only the very first crash in this thread has any connection to Opus (it mentions dopuslib.dll in the crash details), but that's the one you said hasn't happened again after a reboot.
The bug is ALWAYS reproducible now (again), not randomly but systematically when drag'n'dropping with right mouse button (RMB) font file from virtual path C:\Windows\Fonts after a simple "arial ttf" search in Everything. I reinstalled DOpus 1 hour ago, nothing has changed in the system (which is kept very clean, I can assure) except adding those Favorite paths.
.... Give me just more time: I'm setting up a totally clean VBox Windows 10 sandbox where I'll install DOpus 12.30 Light (evaluation) + Everything and set it up as it was on this system. This should be a definitive proof of some conflict either in DOpus or in Everything at least, even though this system is clean as well...
Just reproduced also in vbox on an almost totally clean Win 10 install.
I installed Everything (here is my %APPDATA%\Everything\Everything.ini ) and then DOpus 12.30 Light (evaluation). Then I just added 3 paths to DOpus favorites, and after a while here is the results in a short video capture reproducing the strange issue:
Desktop 2023 01 31 22 11 16 01 - YouTube
I use right mouse button (RMB) to drag'n'drop the font file, to just copy the file, not moving it with LMB.
Did you try the same thing without Opus installed first?
Why do you think that Opus favorites are a factor? It feels like you're blaming random things here.
Looking at the video, there are other programs (unrelated to Windows / Opus / Everything) adding items to the right-click menu which is crashing sometimes. Could be a factor, or not. Could also be that the problem only happens with a combination of software installed, which might be why I can't reproduce it so far.
(Coming over from the Everything forum)
Just trying to help, so forgive any stupid remarks ...
Opus Light does not have the 'Explorer replacement' feature, right?
So it doesn't use shellhooks, right?
How could that be the cause of it?
Also: If File Explorer is used as a drag source,instead of Everything, does that give different results?
That's correct, although I think the hook component still still be installed in both cases, so you can change from Light to Pro without requiring a reinstall.
I'd be surprised for it to be involved in a file copy though, unless the copy is being done via a separate process which is launched by ShellExecute(Ex).
Good idea to test that!
Of course, it never happens uninstalling DOpus, and happens only when DOpus is also installed with its Explorer hook. To be exact I don't even need to fully uninstall it to remove the issue, I can just disable temporarily all (and only) DOpus Explorer ShellEx with Autoruns. Everything points to a strange conflict when DOpus is installed which never happens if it's not there.
Please, can you test it for a while (keep Everything installed and configured as in the ini) and try in the next hours/days to use right mouse button to drag'n'drop the arial font from C:\Windows\Fonts? After all these tests I'm quite sure there's a problem there, even though it's hard to tell if it's Windows, DOpus, or Everything, even though just removing DOpus solves the problem... 
If you open Autoruns to examine installed ShellEx for explorer you'll find a list of them installed by DOpus Light too (zip and those two yellow shellex come also from DOpus):
(This is a pic from my main system machine, not vbox).
Disabling them without fully uninstalling DOpus the Explorer.exe crash never happens.
EDIT:
Ok, tested with Explorer in C:\Windows\Fonts path and using RMB for drag'n'drop on the desktop it copies a list of arialxx.ttf files without crashes. From Everything instead it shows a single file for ariali.ttf for example and dragging this out with RMB instead causes the Explorer.exe crash, but only with DOpus hooks installed as far as I can tell from my tests... Might be just a problem of this virtual path (?) with Everything even though is strange it never happens without DOpus.
About the Favorites I'm just speculating, since it never happened for an hour after I reinstalled DOpus... then I decided to reconfigure a few favorites and BOOM, a few minutes later I was able again to reproduce the strange crash... That's the only reason why I mentioned it, hoping it could help...
In your video above, made using the Virtual Machine, it happens once and then doesn't happen the next time, and you didn't uninstall Opus or disable the ShellExecute hook in between those two attempts.
All we can conclude is that it only happens sometimes and not others.
So the system was fine with Opus installed, and the ShellExecute hook active, for several hours, and then started crashing again later on. That doesn't really sound like the issue is in Opus or the ShellExecute hook.
It sounds more like there's a crash somewhere which is intermittent, maybe down to timing or memory layout which other components can influence just by being loaded at the same time. Sometimes the bug might not trigger a crash and other times it does, maybe due to factors that alter what's at the memory address the crashing code (in windows.storage.dll, loaded into explorer.exe) is incorrectly trying to read or similar.
Since you have AutoRuns there, have a look under the DragDropHandlers and CopyHookHandlers as well (still under the Explorer tab), as those can get involved in right-mouse drag & drop.
Trying some more, I think we have reproduced the problem now. Investigating in detail at the moment. Can't see any involvement from the ShellExecute hook, but there is a separate context menu object being queried.
We will have a fix you can try shortly.
The ShellExecute hook isn't involved, but a context menu object we install is being called in an unexpected way, and our code can crash as a result.
(The shell is initializing a context menu for zero files/folders, which may itself be a bug in Windows. I'm not sure. Maybe there is a valid reason for it. In any case, our code shouldn't crash when asked to do that, and we can fix it.)
The fix will require a reboot (or a log-out, at least) after the update is installed.
I just recorded a crazy 18min test before and after DOpus install in vbox (totally clean this time!) to prove it starts only after DOpus was installed but you were right: didn't happen "always" as I was convinced... just "often" after DOpus was installed.
Desktop 2023 02 01 00 27 43 04 - YouTube (18mins test!! LOL)
Trying some more, I think we have reproduced the problem now. Investigating in detail at the moment. Can't see any involvement from the ShellExecute hook, but there is a separate context menu object being queried.
Pheew... at least my stubborn effort led to something and I'm not crazy (well not entirely at least after a 18min crazy test 
)! Thanks for testing again!