Hi,
Since upgrading to Windows 11 I'm finding Directory Opus to be running really hot and cold, it frequently will just hang or go really slow. Frequently when I right click the context menus won't come up. I've disabled Microsoft Defender as described in another thread, but no luck. I keep going back to Windows File Explorer and it's a bummer. ANything else I should try?
Thanks.
See Crash, exit or high CPU when right-clicking certain files for how to work out what's causing slow right-click menus. It will almost always be a shell extension something else has installed.
If you aren't on 12.31 already, updating to that will fix one known issue by blocking the iCloud shell extension (which doesn't seem to do anything useful, but will slow down right-clicks on files in OneDrive folders, for some reason).
Thanks a lot. I've spent some time looking into this and can't resolve anything yet.
For the right context menus, first of all, it's not entirely consistent. When I fresh start DO it seems reasonable for a bit. When it does seem to hang, I'm finding that the Debugview very quickly lists everything and doesn't hang, ending with.,..
[171640] [21836] dopus: AddFiletypeItemsFromReg: "rename"
[171640] [21836] dopus: AddFiletypeItemsFromReg: "properties"
[171640] [21836] dopus: --- Shell Context Menu End ---
But the menu just doesn't open. And then I can click around the lister, open the "Tools" menu, etc. but can't (for example) change which file is highlighted in a window. If I fully exit DO and restart then things are ok, and I can even open right-context menus for a while. I do notice that when launching DOPUS it can take many many seconds before the lister is populated with the files in the directory (20-30 seconds). And, it's not just right menus, sometimes just going to other directories causes long hangs. It all just feels very inconsistent and hit or miss on whether it will behave reasonably or not.
I tried disabling a lot of context menu items but no change.
ANything else to try? Thanks.
PS: I am on 12.31 and already tried uninstalling and reinstalling.
Thanks for trying that. Based on that and the extra info, it sounds like something more general than the context menus in that case.
Could you make some process snapshots during those times where there's a long delay, and send a few to us? We may be able to see what the delay is from those.
Here's how to make process snapshots, and how to send them:
Thanks so much, I sent the logs.
Thanks for sending those. I've downloaded them. It's late here now but I will look at them tomorrow.
The problem seems to involve this folder:
C:\Users\<username>\AppData\Roaming\gSyncit\syncdata8.db-wal
For some reason, despite it being on the local C drive, calls to the Windows ParseDisplayName API on that folder are taking an extremely long time, when they should happen instantly.
(It's also possible it isn't specific to that folder but happening with other folders as well, and that folder just happens to be the one involved when the snapshots were made.)
Since gSyncit is a synching tool, it makes me wonder if it has installed something that interacts with ParseDisplayName and causes it to talk to a slow internet server or freeze/timeout for some reason.
I also see a couple of threads from asdrive64.dll which are potentially involved, but may also be innocent bystanders. I'm not familiar with that DLL and cannot find any information about it via Google, but it has a couple of threads in our process which are sleeping or waiting on something, and those could be involved with the hanging ParseDisplayName call (but may also be uninvolved).
It might be worth a try to disable ASDrive (or whatever it comes from) and gSyncit, if it's possible to do so, to test if either of them are involved.
(Edit: ASDrive looks to be part of IBM Aspera Connect, which is a tool for copying files by the look of its website.)
Thank you. So far it seems that removing gsyncit has helped. Unfortunately it's a tool I rely on.
Is there anything I can do to keep that software and work around that issue? Or do I need to ask them to see if they can fix it in their software? If so, what do I tell them (I'm unclear on what is calling ParseDisaplyName, what is them vs. DO, etc.).
Any guidance is greatly appreciated.
Thanks again.
It might be worth asking them. You could send the same DMP files to them if they're willing to investigate.
Opus calls ParseDisplayName, which is part of the Windows shell API; that may then (depending on the type of folder) talk to shell extensions installed by other software, or Windows might handle everything itself if it's a normal folder.
Here is their response. If you have any other ideas please let me know. Thank you!
"I don’t have the slightest clue how gSyncit could be causing this issue. gSyncit uses the Microsoft .Net Framework which sits between gSyncit and the Windows OS / API.
I have to think Microsoft would have implemented the usage of this specific API properly. I’ve also never heard of this issue in the nearly 16 years gSyncit has existed. "