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!
We've uploaded a new beta version if you want to give it a try. You'll need to reboot after installing the update.
Please let us know if it still happens after that.
Please let us know if it still happens after that.
Solved. Can't reproduce it anymore! 