GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Help Viewer Stops Responding



Sometimes when I use the search function of the help file viewer, it freezes. If I forcibly close it, Opus also dies - apparently the viewer is sharing the Opus’ process. Waiting does not help.

Is there any other way to handle this? If not, could this be fixed by the viewer being called separated from the Opus’ process in newer versions?


The HTML Help components in Windows may be broken in some way, or something to do with the underlying HTML components they are based on (Internet Explorer, more or less).

I search in the F1 help window quite a lot and have never ran into problems with it, but there are various things that can go wrong with the Windows components it uses.

Reregistering the help components as per here might be worth a try.

If you still get freezes, please generate a crash dump when they happen and send it to us. We might be able to tell why it is freezing, and if it involves any third party components (e.g. antivirus, firewall, or text-input/dictation tools can get involved with HTML components).


I noticed that it is a feature of the ‘.chm’ viewer to create a ‘.chw’ index file when launched. I could not find a corresponding chw file for Opus’ chm - probably because of permission denied on the ‘Program Files’ folder.

Could the lack of a chw file be the source of the freeze? Maybe that file should be included with the installer?

I have manually copied a chw file to “Directory Opus\Help”. I will wait to see if the freezes will still happen.


I don’t think that file would be related or it would freeze for everyone.

How about generating a dump of the freeze for us to look at?


I will eventually send one. Lately my ISP has been having some problems.

Issue with .AVI files only on Opus; Explorer has no issue

Sent you a PM with the link to the dump. Hope this is an okay alternative to sending an email to (If not, tell me.)


Please try uninstalling these things and see if either problem you’re seeing still happens:

  • Dexpot
  • Actual Window Guard
  • ConEmu

They’ve all installed shell extensions of hooks into Opus (and probably most processes) and look like they are also involved in changing the behavior of window positions, z-order, etc. The Help viewer is locking up while trying to enumerate the open windows, so that problem at least is a strong possibility for one of those three tools being the cause. (Or possibly two of them are causing problems when both active at once.)


Thanks, I’ll try and report back later.


Made no difference, problems persist. I checked to make sure that the corresponding modules were not loaded.


I am at a loss in that case, but the issue is something is causing the Microsoft help viewer to lock up while it is enumerating the open windows on the screen. Anything else which changes window behavior might be worth checking.


Something to try when it is frozen: Open Resource Monitor, find dopus.exe and right click it, then choose Analyze Wait Chains.

Does it list any other processes or threads? If so, dumps of Opus plus any mentioned processes (via Task Manager, right click menu) and a screenshot of the Wait Chains dialog may let us see what is blocking things.


2017-10-14 16_30_34-Analyze Wait Chain


If you disable the Movie plugin, does it still happen?

Could we have a process dump plus wait chain screenshot of that to examine?