I am having a recurring issue of application unresponsiveness where the application stops and must be closed and reopened to start working again, at which time it works just fine for a while. It's almost like it's waiting for a response from another application (and the message appears to say the same thing - 'waiting on application name: svchost.exe').
This is only happening with Directory Opus; it doesn't happen with Windows Explorer. Is there a known issue?
Best point to start with would be the section "other Troubleshooting". To me, the issue doesn't sound well known. If it's periodically, Anti-Virus & the like could be the reason. The troubleshooting section also has tips, how to narrow down the reason for such problems by using monitoring tools like Process Monitor.
[url]General slowdown or instability investigation steps]
or generally
It's most likely a 3rd party shell extension or similar component going wrong.
One of these is the best place to start; which one depending on the action that tends to trigger the problem:
[ul][li]Crash, exit or high CPU usage when viewing certain directories[/li]
[li]Crash, exit or high CPU usage when right-clicking certain files[/li][/ul]
I was previously running Directory Opus v. 9.x and it was working fine. It's only after a recent license and product update to 11.18 that I started seeing this issue. I've gone through the items listed and am monitoring to see if it helps. The problem mostly seems to occur when I open a new tab or move to a new directory. It's almost like there's a socket disconnect at the wrong time and the system keeps waiting for a response without handling the lack of it correctly.
Should the entire program become unresponsive if a single tab is waiting for something?
Not usually, but it can depend what is being waited on, and since shell extensions load 3rd party code into Opus all bets are off ultimately.
From v9 to v11 support for additional shell extension types was added, which adds to that possibility.
Did you try disabling everything not from Microsoft using ShellExView?
Not usually, but it can depend what is being waited on, and since shell extensions load 3rd party code into Opus all bets are off ultimately.
From v9 to v11 support for additional shell extension types was added, which adds to that possibility.
Did you try disabling everything not from Microsoft using ShellExView?[/quote]
Sorry - I've been working on a whole lot of stuff. I've finally been able to disable the significant majority of non-Microsoft shell extensions. Some are items I cannot disable (e.g. antivirus), but I also think I've isolated what is responsible for most of the issues.
For reasons linked to the same reason I use Directory Opus, I use a file contents search tool (File Locator Pro). I believe there is a conflict when both Directory Opus and File Locator Pro are trying to do something at the same time. File Locator Pro continues to work, but Directory Opus generally cannot recover when they get into conflict.
Hm. Is there a way to permanently increase the priority class of dopus.exe? If it's getting into a race condition, that might resolve the issue.
You can raise priority via task manager but it would only help in very specific situations and I'm not sure this is one of them.
What makes you suspect the conflict is with File Locator Pro, and that task priority might help?
Have you tried disabling any shell extensions or did you skip that?
I've disabled all non-Microsoft shell extensions including the ones for my AV software (for some reason I was stupidly conflating shell extensions with filter drivers...I have no idea why). I'm testing now.
I'm thinking it's related to the search tool because when I search with it, Directory Opus can't navigate folder trees and is generally unresponsive. The moment the search is complete, it recovers sometimes. I'm trying to see if I get the unresponsiveness when the executable isn't active.
Sorry...addendum: I was thinking the task priority might help if they were competing for the same resource and becoming deadlocked. If Directory Opus was losing in the deadlock competition but then continues to wait for a response to the request, it might cause it to stop responding. That's why I asked if a thread could make the whole product become unresponsive if a single tab was waiting for something.
Well, I've disabled all non-Microsoft shell extensions and it's still happening (though less often than before).
It's sitting unresponsive right now and when I use 'Analyze Wait Chain' in Resource Monitor, it shows that it's waiting for DOPUS to finish network I/O. Dopus.exe (PID: 4296) Thread 15160 is waiting for the same PID, with thread 2904, and the app isn't moving. It's been sitting for several minutes with no updates right now. Should I try to let it crash gracefully and capture a dump file?
Whoops! Correction - I've left the DOPUS shell extensions active. Should those be disabled as well?
You shouldn't need to disable Opus's own extensions.
Can you create a dump file at the point where it seems to be hung? (Right-click the process in Task Manager and there's an option to create a dump from the running process.)
Here at work, I also have to deal with recurrant unresponsivenesses for quite some time, other collegues as well.
When it happens, browsing with Explorer works just fine, so is that problem very likely to have something to do with shell extensions in these cases? I mean the shell extensions are loaded and working for Explorer just fine it seems. Anyway, I disabled basically all non-microsoft shell and context menu extensions for now.
I also disconnected all mapped/network drives (using UNC only anyway) and also disabled smart favourites and recent listings in DO.
I can tell: That helped. Did not notice unresponsiveness during the last days. Will re-enable different things over the following weeks to hopefully find the real cause of this. The delays and "hangs" have been a real pita recently and seemed to occur increasingly.
Take a dump file while it's hung, it's the only way we're able to see what's going on.
I'm zipping it; what information is the dump file likely to contain? For example, does it contain details of files in the file system, or just OS and Directory Opus specific information?
It could potentially contain any information that's part of the Opus process, including filepaths and config details, FTP passwords (if used) and so on. For that reason it's best to zip and email rather than post in public. Zips can be emailed to leo@gpsoft.com.au
(Minidumps which Opus creates automatically in some situations are less likely to contain such info as they take a very minimal snapshot to avoid using up huge amounts of disk space, but dumps created using Task Manager typically contain more.)
I'll check, but I think I might have to wait for someone else to report this issue for your review, as the data on my machine are sensitive and I'm bound by fairly strict laws pertaining to them. 
That's understandable.
Your bet bets if you want to diagnose the problem locally are these two guides: