After updating to version 2.18 or 2.19 - not sure which one, when I access a drive on the corporate network, DOpus takes a long time to read and display the folders and sometimes it even locks up and I can't even close the app. It never did this before the last couple of updates. Microsoft File Explorer works fine. I use DOpus all day long and I love it - until now! Whatever you guys did in the last couple of revisions, please fix slow WAN connections to large corporate network drives!
If, before navigating to the drive, you turn off the folder tree (assuming it's on), does that make it faster again?
Yes, it does!! I guess this could be a work-around for now. Can I roll back to version 2.17?
You can roll back, but it'd be good if we could work out what's going wrong and fix it, else you'll be stuck on that version forever. (You may also find the old version is the same and it's something else that changed.)
Would it be possible to create some snapshots and send them to us, while the freeze is happening (i.e. with the tree turned back on)?
Also, how long did you wait for the folder to read? Was it still slow after the initial load?
I've noticed this too, for two times so far when navigating infolder tree to a network share (SMB protocol) assigned a drive letter and located on my Synology NAS.
I'm running DO 12.19.1. This is, however, not (always) reproduceable. The Windows Pro PC is member of a domain, precisely its a Samba domain.
The share DO tries to access contains only a few folder in its root and no files.
I will watch the behavior and try if I can reproduce it again.
1 Like
I've attached a screen shot. It did not lock up this time but did take a long time to display the folder list - around 1 minute. When it is having this issue, it will be slow even after the initial upload - ie., if I go to another folder and back to the first one it is still slow listing the folder. I'll turn on the Dump file and the next time it locks up I will send you the file.
1 Like
Hi Leo. DOpus has been working fine the rest of the day. Really weird! If it stops working again, I'll save the dump file and send it to you. I really appreciate your support. See, you fixed it and didn't even have to do anything. Man, you're good 
1 Like
Hi Leo,
So, today I thought it was locked up again when trying to access a network drive. I was going to send you a dump file but before I could go through that procedure, DOpus started responding again. So, it was "locked" up for almost 5 minutes!! It appears the app is trying to read way to much information when you click on a folder or folder tree. This appears to only be a problem when accessing slow WAN connections to network drives.
Please create some snapshots (instructions linked in my previous reply) during that 5 minute delay so we can see what's going on.
Hi Leo,
I've sent a link to a Dropbox folder with a crash dump file. What appears to be happening is if I wait long enough the network folder contents are finally displayed. In the Task Manager app the app says it is not responding. After this happens and the folder contents are finally displayed, if I try to go to another folder the delay is even worse, until I have to close DOpus and open it again. This is even true if I just try to read a USB external hard drive folder. After I close DOpus and open it again, I can read the USB drive quickly and the network folders slowly, but tolerable, until at some point it gets slow again.
The snapshot shows three threads which seem to be waiting for DropboxExt64.27.0.dll to return icon overlay information.
No other threads are active, except for a fourth thread which is waiting on one the other three to finish.
So this looks like an issue caused by Dropbox.
I would try using ShellExView to disable the Dropbox extension.
- Download the x64 ShellExView, extract it and run it.
- Sort by the Type column and scroll down to the Icon Handler and Icon Overlay Handler ones.
- Right-click the DropBox extension(s) and select the option to disable it/them.
- Reboot.
If it does still happen, please send further process dumps, so we can see if same thing is still happening, and it's not disabled somehow, or if it moves elsewhere.
Hi Leo. I've been testing this for the past few business days. Exiting the Dropbox app fixes the issue. Do you have any idea if you guys will tweak your code in a future release that can get around this issue? In the meantime, I'll just exit the app. I wonder if I would have the same issue if I used the "Box" cloud service or OneDrive? Thanks for your support!!
We can't fix bugs in Dropbox's code, so your best bet is to report the problems to Dropbox. If you send them the same dump files you sent us, they should be able to locate where in their code their shell extension is freezing or taking a long time when it is asked for icon information.
The best we could do would be to block the Dropbox shell extension entirely, similar to if you disabled it via ShellExView.
I am seeing the same issue. Disabling the shell extensions as mentioned does seem to solve it - thanks for that! Obviously, the dropbox shell extensions are eating up a ton of resources, but the confusing part to me is why is it that Windows Explorer is not seeing this same performance hit?
You'd need to ask Dropbox that as we have no way of knowing what their code is doing or why it's taking a long time and/or freezing.
It's presumably a bug in their code, since Dropbox's shell extension shouldn't be doing much, other than returning instantly, when asked if it wants to add icon overlays to files that aren't part of a Dropbox folder.