That kind of problem is usually caused by one of three things:
A shell extension something else has installed is locking up when asked to get information about certain files or folders.
Something in the configuration (usually toolbar buttons, or sometimes script add-ins) is causing something to be accessed which is very slow, or hanging.
A device that Opus is trying to read a folder (or icons, etc.) from is very slow or hanging.
If you've waited at least 30 seconds and the program is still hung, you can rule out the last possibility, and most cases of the second (unless there are two such problems, which could cause a 30 second delay per device; most likely with network drives that cannot be reached, if the delay is that long; shorter delays can occur due to drives that have spun-down to sleep).
This guide covers the first possibility, as well as some related possibilities:
We can also sometimes tell you what is causing a freeze if you make a manually-generated process dump using Task Manager and zip & email the dump to us:
That sounds like a hang I've been seeing from TortoiseSVN as well. In the end I had to disable its Icon Overlay shell extensions using ShellExView. (The context menu extension is fine.)
I did some investigation and it looks like TortoiseSVN is deadlocking itself when asked to do two thing at once, or something like that, but I didn't investigate in depth beyond checking that Opus did not seem to be involved. (Haven't gone to the TSVN source code or anything like that yet.)
Opus can show the same overlay icons in a separate Status column (if the option to do so is enabled), so for me there wasn't any disadvantage to disabling the Icon Overlay shell extensions, and I haven't had any issues since.
Yes I understand that I need to disable them in TSVN - however the option in DO only shows text status, no icons... and I dont think that disabling the icon overlay is going to make them appear in a column in DO?
We have what we hope is a fix for this coming in the next beta.
It's hard to test the fix because the problem, which was happening several times a day for me with the TSVN icon overlay extensions re-enabled, stopped happening as soon as I started investigating it again 3 days ago, and hasn't happened since, even after making changes which should have stressed the problem further.
I'm starting to suspect a third component was involved, or possibly changes to how Windows 10 loads DLLs, since the start of the problem did not coincide with an Opus or TSVN update. That could also explain why it seems to have spontaneously stopped happening. On the other hand, it could come down to a timing issue (which is what the potential fix we've made aims to address).
If you still see the problem after the next update, please let us know.