Recently on multiple computers I'm getting the same bug. When I boot it brings up the windows that were previously open and they all say Reading Folder... with an abort button. Unfortunately, this never resolves. I've waited an hour and the only way to get it to clear is to kill dopus.exe and then re-run it, at which point it loads all the same windows and they all resolve. If I open a new Dopus window when I am in this situation it also shows Reading Folder... and does not load.
I'm not sure what I could have done to cause this.
Here is a screen shot. As you can see the folder list on the left isn't expanding or showing attached drives either.
Some of them might have been opened to network locations, but I didn't think so. Certainly most of them were to local drives.
I waited over an hour one day to see if they would eventually clear, they did not. And, I cannot reproduce it after the first time I kill the Dopus.exe process and restart it. I do not have to kill DopusRt.exe.
That definitely sounds wrong. You shouldn't have to wait that long ever.
Do you have Dropbox installed? I've seen a few process dumps with freezes during startup where ti looked like it might be involved, although it is not definite (and is even less definite that it is to blame, even if it was involved). If you do, could you try temporarily uninstalling it?
(You can also disable its shell extension(s) via ShellExView, if you want to avoid unisntalling it.)
If Dropbox isn't installed, or if it doesn't make a difference, could you please generate a process dump the next time you get a similar freeze, and send the result to us? We should then be able to look at it and get a better idea of what Opus is doing and waiting for, and if any 3rd party components might be in the mix.
The Manually generated dumps section of Crash dumps for bug reports explains how to make a process dump using Task Manager.
I don't have access to my other computer today, but at least this computer does have Dropbox installed. I'll try to find some time this weekend when I can reboot a bunch of times and see if it makes any difference.
Yes, I do have TortoiseSVN installed, version 1.10.0 build 28176, and I use it all the time.
I'll try disabling the Icon Overlay, but because the "Reading Folder..." failure occurs so infrequently, it'll be hard to know if it makes any difference.
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.
