Descrizione
Percorso dell'applicazione che ha generato l'errore: C:\Windows\explorer.exe
Firma del problema
Nome evento problema: APPCRASH
Nome applicazione: Explorer.EXE
Versione applicazione: 10.0.19041.2311
Timestamp applicazione: 5d5a42f5
Nome modulo con errori: dopuslib.dll
Versione modulo con errori: 12.30.0.0
Timestamp modulo con errori: 630d6eb3
Codice eccezione: c0000005
Offset eccezione: 0000000000034930
Versione SO: 10.0.19045.2.0.0.256.48
ID impostazioni locali: 1040
Informazioni aggiuntive 1: e472
Ulteriori informazioni 2: e4725fe007a5f2d540f077b09444a135
Ulteriori informazioni 3: c96c
Ulteriori informazioni 4: c96c00b7fdbaf075a6437f76541eb114
Seems to happen randomly just browsing the HD (I have links, dir-junctions, Amiga ADFs, lha files etc.). Repeating the same identical actions won't always cause the random crash.
Not exactly this old case I myself started, but maybe they have the same origin... It seems there is a conflict with Everything (Voidtools). The other day I found a reproducible issue when DOpus 12.30 + Everything are installed.
There's an Explorer.exe crash on Windows 10, trying to drag'n'drop with RMB (to copy) a font file like C:\Windows\Fonts\ariali.ttf to the desktop from Everything listview (try searching "arial ttf").
The author of Everything opened also a thread on his forum: Explorer crash when right-click-moving a font from C:\Windows\Fonts - voidtools forum
Was the issue this thread was about solved? We never heard back from you.
This other issue is unrelated and should be in a separate thread, but from a quick test I cannot reproduce it (testing with Everything 1.4.1.1022 x64). The copy succeeds without problem. As far as I know, the ShellExecute hook would not normally be involved in a file copy, since it only gets involved when something calls ShellExecute or ShellExecuteEx and those aren't normally used to copy or move files.
Was a random issue... didn't find a reproducible pattern.
About this other issue... I just completely uninstalled my DOpus Light and reinstalled from scratch (adding just opusADF.dll extra lib for Amiga ADFs), and indeed I can't reproduce it anymore (!???).
That's strange since I did nothing special to DOpus installation before nor added exotic functions to it, just auto-upgraded 5-6 times in the past up to the current version (Light license)... and the proof (I thought was definitive) was that after disabling (just) DOpus ShellExes it prevented the Explorer.exe 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).
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.
Descrizione
Percorso dell'applicazione che ha generato l'errore: C:\Windows\explorer.exe
Firma 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.
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'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.
