Opus 11 launches OK and I can perform one or three operations (move files delete fies, etc.) then Opus freezes and can only be shut down through the task manager.
I have reinstalled Opus 11 3 times and have tried running it under Windows 10's Windows 8 compatibility and as an administrator - none have helped.
Please help.
John11
Sorry you're running into problems. Some questions:
(The admin and compatibility options can only cause problems, so please make sure those are turned off again.)
When the freeze happens, does Task Manager's process tab show that dopus.exe, or any other process, is using a lot of CPU?
Does the freeze only happen when copying certain types of files, or when copying from or to certain folders?
Can you perform the same operations using Windows Explorer successfully, or does that also start to freeze in a similar way?
Are you using the latest version (11.16 or above), or an earlier one?
Thanks Leo,
I have now trouble shooted as a non administrator and with Windows 8.1 compatibility turned off. The crashes seem to be caused either primarily or exclusively when I delete a FOLDER and then click my cursor on another FOLDER(this brings up the "reading folder" progress message. I can successfully navigate Opus and moved, deleted, and copied FILES without it freezing
Additional information:
New Windows 10 PC 64 quad 8GB ram
Opus 11.16 64
Windows Exploerer does not crash or freeze
Opus in Task manager .1 CPU and 13.6 MB Mem
The type of folder deleted does not seem to make a difference
Opus completes thefolder deletion prior to the freeze (the deleted folder is in the recyle bin when I restart Opus)
Is deleting a folder necessary to cause the freeze, or is it triggered just by changing between folders?
Crash, exit or high CPU usage when viewing certain directories has troublehshooting suggestions which may help. It's likely being caused by a shell extension which is loaded into the Opus process and going wrong for some reason.
Changing between folders does not freeze Opus - it looks like the freeze ONLY occurs when deleting a Folder. I can move from folder to folder and file to file without freezing Opus.
Anytime I delete a folder it freezes.
Do you have any third-party software installed that affects deletes in any way (e.g. recycle bin manager or undelete tool or anything like that?)
I don't believe so. I usually load these programs at the start of the day and run them all day:
ClipMate
MacroExpress
Classic Shell
MS Outlook 2007
Avast anti-virus
Malware Bytes
Google Chrome
Can you try disabling Classic Shell and the two AV programs and see if it makes a difference?
Yes,
Yesterday I tried running Opus directly from Windows 10 with only the anti-virus and malware programs running. There was do improvement. With only Opus running it still freezes after a directory deletion.
Please try disabling the AV programs as Jon suggested above. (Or do you mean you've also tried that today?)
Running Opus under the (defenseless) native Windows 10 user interface provide no improvement - Opus still freezes when a directory is deleted.
When Opus is in this "frozen" state, open Task Manager, click the Details tab, and then locate dopus.exe in the list of processes.
Right-click it, and choose Create Dump File from the context menu. This will create a .dmp file in the temporary folder (a dialog will show you the actual filename once it's been created).
If you can zip that .dmp file and email it to leo@gpsoft.com.au (or if it's too big for email, put it on a file sharing site and email us a link) we can hopefully find out from that what's happening.
[Moderation note: Removed some intermediate back & forth about Task Manager and email issues which are no longer important, to make the thread easier to follow and fit on one page.]
I emailed a OneDrive link to the zipped Dopus dump file. Let me know if you were able to access it.
Thanks for the file!
Please try using ShellExView to disable the FileHistoryDataSource shell extension, then reboot the machine.
Does the problem still occur after doing that?
Note: A side-effect of doing this may be that you can no longer go to Previous Versions folders. If you use those, this may not be a long-term solution, but it's worth checking to confirm that we've located the right cause.
Purely for reference, and to help any other developers who find this thread: It appears that the FileHistoryDataSource extension (fhshl.dll), despite being part of Windows itself, has a serious bug in it. When it is being unloaded, it unloads various other components it has been using, one of which waits for another thread to finish. But because the first thread is inside of DllMain (with DLL_PROCESS_DETACH), the thread it is waiting for can never finish because it also needs to call DllMain (with DLL_THREAD_DETATCH), and all calls to DllMain are serialised by the DLL Loader Lock. The end result is that no threads in the process can start or finish from that point on. The dump file show lots of threads waiting in their shutdown code, and the Opus lister thread is waiting for a worker thread to be created, all because the FileHistoryDataSource shell extension (fhshl.dll) has caused a deadlock.
Leo,
Disabling the FileHistoryDataSource shell extension, and rebooting appears to have solved the problem.
Thanks much for your help!
Any news on this ? I use previous versions all the time, so I can't disable it, and I also keep moving /adding folders all the time and my dopus keeps crashing.
Windows Explorer also uses previous versions and it does not crash, so I'm starting to use it more and more, but I'd prefer be using dopus...
Thanks.
Disabling the FileHistoryDataSource shell extension is still our recommendation.
We may take steps to block the extension from being loaded into Opus but were not ready to in time for 11.18.
Hopefully Microsoft will fix their bug as it is quite a serious one, but that is outside of our control.
For me, the File History control panel in Windows 10 is incredibly unstable on its own, even on machines without Opus, so there are general problems with that whole part of Windows 10 which Microsoft have yet to address.
It seems this is fixed in the anniversary update release
