This happens when I set DO as my default explorer. No trouble with the original one.
1 Like
We’ve had one similar report but can’t reproduce this ourselves, and Chrome actually runs Explorer* and goes out of its way to block our DLLs (and anyone else’s) from being loaded into their process, so none of our code should be involved unless things have changed on the Chrome side.
It’s possible the problem happens when a third component is also installed, which might explain why we’ve had only one other report and don’t see the same thing ourselves. Or it might depend on Chrome versions.
Reporting the crash to the Chrome team may be worthwhile as they should be able to analyse the crash dumps (which we don’t have access to), and it’s likely happening due to something they’ve changed.
(*Edit: That seems to have changed and now depends on the action. Opening the downloads folder for a particular file will open it in Opus, while opening the downloads folder itself opens it in File Explorer. Chrome used to block third party DLLs from their process but may have changed things again. I am not sure.)
Well, maybe what I should do is just to re-install my system. Too many software make it difficult to figure out why..... 
Thanks !!
I have this same problem with the latest DOpus. I've had it on Windows 8.1, Windows 10, and Windows 11, and on two machines. I thought maybe it was Chrome, but it's been that way for years and recently some research turned up other people with the same issue when DOpus is installed.
https://www.reddit.com/r/chrome/comments/umzvde/chrome_crashes_when_opening_a_downloaded_file/
I also saw this thread about Chinese input methods: Chrome Crashes with DOpus and Chinese Input Methods on Windows 11 - #7 by Cesaryuan
I have Japanese input methods installed, but they don't have to be active to crash Chrome. The crashes are random it seems, it doesn't always happen.
I'll see if 13.7 fixes it when that comes out.
Can confirm that 13.7 does not fix it.
If you haven't already, try rebooting after installing 13.7, in case the old DLL is still loaded in some processes.
After a reboot it so far has not crashed again, but then again it did go for long stretches without doing that so I'm hesitant to call it fixed just yet. Looking promising though.