I've just installed the latest x64 11.3, but I've had this issue for about a month now on 11.2 and previous. I've not changed anything myself other than adding a (perfectly normal) partition on one HD. Previous to about a month ago there was no problem.
When starting DO, either from the pinned shortcut or by double clicking the desktop, the lister loads up looking normal but is completely frozen. This lasts about a full minute or longer. All I get is the swirly 'waiting' cursor if I move over the lister. I can't close it or do anything with it.
If I try opening more listers, mostly they will freeze like the first, but occasionally one will work normally even though the others remain frozen for a while.
Is there anything I can do to find out what is causing this, a debug setting or something? I'm wildly guessing that DO is trying to access something on my system that is not responding in a timely fashion, but I have no idea what that could be or how to tell.
Turn on everything under Preferences / Folders / Auto-Loading, so all the types of folders are prevented from auto-loading..
Remove any collections that you no longer need. (If you delete the collections themselves, it will not delete any data. But be careful not to delete the files or folders inside the collections.)
If you might have anything on your toolbars pointing to an unreachable network drive, that could be causing the delay.
If neither of those help, it may be worth running Process Monitor to see what dopus.exe is accessing during the delay. The delay could be caused by many things, including 3rd party components, so sometimes this is the best way to get a handle on what's going on. Please try the other two ideas first, though, as they are a lot easier to try.
Thanks Leo. I got called away earlier but I've just started the first suggestions and I'll see how it goes tomorrow. My DO installation is almost stock apart from just moving some of the buttons around; that makes life easier.
I finally got chance to get back to this; sorry but some really nasty RL stuff went on.
The issue is still happening with the v11.5.1 beta x64. At the moment it seems worse, with failure to respond for a minute almost every time I start DO.
That meant that it was easy get procmon to capture a failure, but I don't really know what to look for. I filtered everything except dopus.exe and there are still 11,000+ entries in the failure-to-respond period of about a minute.
I do see a lot of "Invalid Device Request" in the Result column, with the partitions that were open in DO at the time in the Path column. Detail column is "Control: FSCTL_LMR_QUERY_DEBUG_INFO". Is that significant?
If not then I don't have a clue. Nothing looks obvious. It's not easy to tell the exact point in the log that DO starts to respond again, or where it stops for that matter.
The partitions that give the above entries are absolutely fine, by the way. I ran a disk check on them just in case. I have DO set not to scan anything that I can turn off as per your instructions and have no collections (don't know what they are yet, lol). I have no customisation apart from moving some of buttons around to where I prefer them. The installation is stock apart from that.
If you save the procmon data to a PML log file (File / Save in procmon), then zip and email it to me at leo@gpsoft.com.au I will take a look at it when I get a chance.
I can't find anything definite, but one thing which stands out is the Box Sync shell extension. Activity from it is appearing throughout the log file, so it may be involved.
That shell extension is also written in .Net, which is more or less against the rules for Windows shell extensions (Microsoft's rules, not ours) and a very bad idea in general. That makes me suspect it even more, although it is still only suspicion and could turn out to be completely innocent.
If it is still there, it may be worth doing the same with other shell extensions, in case they are involved. (You can usually ignore the Microsoft ones, which normally only leaves a handful that need to be checked.)
I've uninstalled Box and a couple of other file sync programs completely, and checked with ShellExView that they didn't leave anything behind.
So far so good... DO hasn't frozen in the last hour or so, about a dozen starts. It's too early to tell though because sometimes that's the way it goes anyway. If it freezes again I'll have another look at the shell extensions.
Looks like this has solved the issue. DO has not frozen since I uninstalled Box and the others. Box was on my PC long before the issue started, but perhaps a quiet update broke something.