GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Opus 10 Hangs in Win10 64Bit Creators Edition Update

After Win10 Creators Update, Opus hangs after having been opened for 5 or 10 minutes. Hangs with any folder in focus. I have to force-close the app and restart it. Then 10 minutes or so later it hangs again. I did let it hang for quite a long time and got this windows error log entry:
The program dopus.exe version stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.

Checked Security and Maintenance control panel and no information on this there.
Also checked the 2 similar threads on this in support, and I do not have Acronis, the other is for Win7 and unrelated.
Thanks for your consideration.
PS: Can't afford to update Opus at this time.

If you can generate some dump files during the hang (instructions below), we may be able to identify what is causing it and suggest a way to fix it.

Note that Opus 10 is not really supported on Windows 10, as it predates Windows 10 by several years, but we're happy to take a look at the dump files to see if they suggest a solution, provided you link your account.

Instructions for generating the dump files:

While it's happening, please go to Task Manager, then the Details tab, right-click dopus.exe and select Create Dump File.

Do that 4 or 5 times, and it should create something like:

C:\Users\<username>\AppData\Local\Temp\dopus (2).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (3).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (4).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (5).DMP

The files will be large, but compress well.

If sending more than one file, using the 7z format instead of zip will give a much reduced size. You can do this via the Archive Files button in Opus.

Please zip or 7z the files and email them to

Thanks for the reply. You're right that V10 is old in relation to Win10CreatorsUdpate, so thanks for taking a look
Dumps in z7 format:

It looks like one of your shell extensions is doing something it shouldn't when its DLL is loaded or unloaded, causing it to freeze. That in turn is causing other threads to deadlock if they load or release another DLL, as the system only allows one DLL load/release to happen at a time and others queue up behind it.

You can use ShellExView to see which shell extensions are installed and try disabling them. Try disabling all or most of them first, then reboot, and see if the problem remains. If it is gone, re-enable a few at a time until the problem comes back, and you should be able to narrow it down to a particular extension fairly quickly.

You don't normally need to reboot after enabling an extension; only after disabling one (as it may already be loaded into processes and be too late to prevent it being loaded, without a reboot).

The dump indicated an extension called ShellExtension.dll might be involved, but it may also be an innocent bystander. So it might be worth looking with ShellExView for an extension with that DLL name and disabling that (and rebooting) as a first step, in case that finds it instantly. (The fact they have named their DLL something as generic as "ShellExtension.dll" also suggests the people who wrote it may not really know what they are doing, as two DLLs with the same name can cause conflicts, and shell extension authors should know this.)

ShellExtension.dll is the issue. That's used by Comodo backup, which I've used along with Opus for years. It might be that with the recent update to Comodo that it is either at odds with Opus or now caused to be at odds with Opus by Win10 Creators Edition update.
After removing Comodo as a test, Opus works fine over the last 2 hours, whereas it only took 10 minutes to hang Opus before.
Since I use Comodo for all our backups, I'm locked with that currently so I'll either have to use another file manager, change from Comodo backup on all our machines, or wait until I can upgrade to the new Opus (That's not so say that Opus vs. Comodo could still be an issue with the latest Opus, thus the reason I'm posting this for your reference.)
Jim Leahy

You can probably keep using both, and either disable the Comodo shell extension system-wide, using ShellExView, or block it just from certain parts of Opus, using the ignore_context_menus setting. (Whether system-wide blocking is needed will depend on exactly how it is going wrong, so you may or may not need that.)

Shell extensions just provide icon overlays and/or ways to launch things via right-click context menus on files. They're rarely needed for the program that they are part of, which will almost always still work with them disabled, as long as there are other ways to access its functionality. The only thing to remember is that updates to the program may re-activate its shell extension, if the system-wide blocking option was used.

Details on blocking shell extensions can be found here:

Thanks again for the reply. Disabling the shell extension seems the best approach for now. That way I can keep using Upus.
Could Comodo have this issue with the latest Opus?
Might be willing to spend some time doing A-B testing for you and provide a report according to your specs for upgrade to the latest Opus? :slight_smile:
Either way, thanks for the good tech support and follow-ups. That's nice.
Jim Leahy

It's most likely something Comodo would have to debug and fix, as we have no access to their code or ability to modify it to fix bugs, assuming the right component has been located and what the crash dumps suggest is the problem really is the problem.

Whether the same would happen with the latest version of Opus, I could not say, as it depends exactly why the 3rd party DLL is (apparently) locking up on thread attach/detach. We have made some changes over the years to help avoid triggering problems in some DLLs, and sometimes just moving code around in memory or changing the timing of things fixes (or breaks) things, as some bugs are only triggered when the stars align properly.

You could try a trial version of Opus 12 to see how things behave, but if the problem is still there then it's really Comodo that you'd need to talk to as only they can investigate their code. We just load their DLL (because the registry tells us to, unless it is blocked by ShellExView or similar) and the rest is a black box to us.