Dropbox occasionally freezes DOpus after files were changed

Since we updated to DOpus 11 (anything else was untouched) we see occasional freezes in DOpus on our systems (Win7; x64; DE).

If it happens it is very simple to reproduce. We just have to modify or create a file inside the dropbox folder and DOpus freezes for 5-10 seconds (hourglass is shown). If it happens for first time it can be reproduced each time (when files are changed). It can be easily fixed by restarting DOpus or closing Dropbox. After restarting DOpus the issue doesn't occur for around 10 minutes. Then it comes back. There are no freezes in other applications (e.g. Explorer). It's the same dropbox version as we have used for more than two years with DOpus 10 without seeing this issue. Updating the dropbox version doesn't help as well.

Is anybody affected by this issue too?

BTW: The freezes only occur if the changes are made by DOpus itself (e.g. copying, renaming, etc.). If the files are changed in the Explorer and the folder is opened in DOpus as well, there are no freezes at all.

I use Dropbox all the time and haven't noticed anything like this. As far as Opus is concerned it's just another folder.

If you disable the DropBox shell extensions using ShellExView, does the problem stop?

(You have not changed anything else on your computer since installing Opus 11 weeks ago? I find that hard to believe. :slight_smile:)

I will give that a try ...

I haven't changed anything by intention in the last 1-2 month. There were no changes in hardware or in deeply integrated software. But certainly there have been lots of auto-updates by various tools and Windows itself. Thus there are thousands of potential reasons for that behaviour.

I will disable the shell extension and I will manually step back to DOpus 10 to see if the freezes occur with the last version as well (then it must be any intermediate change).

Yes, disabling and enabling the Dropbox shell extension toggling the freezes.

I recorded a video (2 minutes) to demonstrate the effect, maybe you can see something (that I do not see) allowing further conclusions.

tinyurl.com/mskbzb4

For me it looks like a repaint / update problem since the overlays and the context menu are laggy and some parts are flickering (as there are hundreds of repaints). Unfortunately the flickering can't be seen in the video due to the encoding.

If DOpus doesn't respond anymore the processor usage is high (during the flickering?) and then low (0% as shown in task-manager's process list).

Here is the output of WhatIsHang:

Hang report for C:\Program Files\Directory Opus\dopus.exe
Generated by using WhatIsHang on 02.07.2014 12:01:15
Web site: http://www.nirsoft.net


Remarks:
* The program hangs in a single system call. You can look in the call stack and  stack data to find out which API function cause this hang.


Strings found in the stack:
D:\Applications\Dropbox\Test


Modules found in the stack:
C:\Windows\system32\KERNELBASE.dll , Microsoft Corporation , Betriebssystem Microsoft® Windows®, Client-DLL für Windows NT-Basis-API
C:\Users\Test\AppData\Roaming\Dropbox\bin\DropboxExt64.22.dll , Dropbox, Inc. , Dropbox, Dropbox Shell Extension

ThreadID: 5156


Execute Address:
00000000775F12FA  ntdll.dll!NtWaitForSingleObject+0xa

Call Stack:


Stack Data:
00000000075A8C68  000007FEFD7010DC  KERNELBASE.dll!WaitForSingleObjectEx+0x9c
00000000075A8C70  00000000075ACD80
00000000075A8C78  000007FE0011C017
00000000075A8C80  0000000002EDD850
00000000075A8C88  000000000000006C
00000000075A8C90  00000000075A8D70
00000000075A8C98  FFFFFFFFEE1E5D00
00000000075A8CA0  0000000000000048
00000000075A8CA8  0000000000000001
00000000075A8CB0  0000000000000000
00000000075A8CB8  0000000000000000
00000000075A8CC0  0000000000000000
00000000075A8CC8  0000000000000000
00000000075A8CD0  0000000000000000
00000000075A8CD8  0000000000000000
00000000075A8CE0  0000000000000000
00000000075A8CE8  00000000075A8D50
00000000075A8CF0  00000000075AE2F0
00000000075A8CF8  0000000000003FFE
00000000075A8D00  0000000000000000
00000000075A8D08  000007FEF3B814C0  DropboxExt64.22.dll+0x14c0
00000000075A8D10  000000000000006C
00000000075A8D18  000007FEF3B9A7D0  DropboxExt64.22.dll+0x1a7d0
00000000075A8D20  000007FE00000000
00000000075A8D28  0000000000000BCC
00000000075A8D30  0000000000003FFE
00000000075A8D38  00000000075A8D50
00000000075A8D40  00000000075ACD80
00000000075A8D48  0000000008554440
00000000075A8D50  0000000000004000
00000000075A8D58  000000000000001D
00000000075A8D60  0000000000000E5C
00000000075A8D68  FFFFFFFFDB0122DC
00000000075A8D70  0000000000000000
00000000075A8D78  0000000000000000
00000000075A8D80  0000000000000000
00000000075A8D88  0000000000000000
00000000075A8D90  0000000000000000
00000000075A8D98  0000000000000000
00000000075A8DA0  0000000000000000
00000000075A8DA8  0000000000000000
00000000075A8DB0  0000000000000000
00000000075A8DB8  0000000000000000
00000000075A8DC0  0000000000000000
00000000075A8DC8  0000000000000000
00000000075A8DD0  0000000000000000
00000000075A8DD8  0000000000000000
00000000075A8DE0  0000000000000000
00000000075A8DE8  0000000000000000
00000000075A8DF0  0000000000000000
00000000075A8DF8  0000000000000000
00000000075A8E00  0000000000000000
00000000075A8E08  0000000000000000
00000000075A8E10  0000000000000000
00000000075A8E18  0000000000000000
00000000075A8E20  0000000000000000
00000000075A8E28  0000000000000000
00000000075A8E30  0000000000000000
00000000075A8E38  0000000000000000
00000000075A8E40  0000000000000000
00000000075A8E48  0000000000000000
00000000075A8E50  0000000000000000
00000000075A8E58  0000000000000000
00000000075A8E60  0000000000000000


Processor Registers:
RAX: 000007FEFEF82340  SHELL32.dll+0x462340
RBX: 0000000000000000
RCX: 0000000000000001
RDX: 000007FEFEF822A0  SHELL32.dll+0x4622a0
RSI: 0000000000007530
RDI: 0000000000000BCC
RBP: 000000000044F148
RSP: 00000000075A8C68
RIP: 00000000775F12FA  ntdll.dll!NtWaitForSingleObject+0xa

That shows the hang is inside the Dropbox shell extension, which is waiting on something. It's not something we can debug. You should report it to Dropbox.

I will do so but as long as I can't reproduce this problem in Explorer, I'm not that optimistic that they will try to reproduce that.

Can you say if there is a chance that DOpus may "flood" the Dropbox API by repetitive calls?

Since I have some clearly visible flickering it looks as DOpus calls the Dropbox DLL multiple times in a sequence within the same second before the freeze occur. On the other hand the same operation performed in Explorer does not show this flickering and even does not freeze. Thus DOpus seems to use the Dropbox API something different.

Assuming that the Dropbox DLL initiates some asynchronous stuff (e.g. network traffic) on each DLL call, it would be an explanation for this behaviour ...

Opus doesn't know anything about the Dropbox DLL, we just ask the system for the icon overlay.

Yes I understand.

But could it be that DOpus asks the system for the icon overlay multiple times in a sequence within a short time period during a folder refresh operation?

It looks as DOpus incrementally updates the folder by first showing the items, than the file and folder labels are applied, than the folder sizes are shown, etc. Each time the file and folder icons need to be painted again. I can see that there happens many things at different stages before the folder is finally done refreshing. Assuming that the Dropbox DLL is called multiple times at each stage, it could be that the DLL simply blocks after some calls because it doesn't handle these kind of usage very well.

Dunno, as I said before I've never noticed any issues and I've used Dropbox for years.