By Steve Endow

UPDATE: A Dynamics GP partner discovered a method to stop the excessive HHCTRL events by implementing specific registry entries. You can find that solution at the end of this post.

Recently, a customer reached out to me about an issue in their Windows Application event log. The log was being bombarded with events originating from “HHCTRL,” recording multiple events per second and resulting in thousands of entries.

These events were categorized as “Information” messages and didn’t seem to indicate a significant problem. However, their sheer volume became problematic as they made it challenging to isolate any genuine errors within the log.

The description for Event ID 1903 from source HHCTRL is missing. This suggests that the component triggering this event is either not installed on your computer or the installation is faulty. You might need to install or repair the component.

I had encountered this before and conducted some initial research, but the information available was limited. Existing threads either lacked details or proposed solutions that proved ineffective. Some discussions pointed to a Microsoft security patch for HTML Help as potentially introducing this HHCTRL event log issue.

Facing the issue again, I collaborated with a colleague and we believe we’ve pinpointed the root cause. We suspected a connection with an application capable of running as both a standard Windows application and a Windows Service. My colleague’s testing revealed that the messages were absent when the application ran as a regular program. However, when launched as a service, the HHCTRL messages flooded the Event Viewer. I was able to confirm this behavior on my server.

We explored potential permission issues, but both of us were using Administrator accounts for testing, casting doubt on that theory.

Puzzled, I turned to the SysInternals Process Monitor. While monitoring the process, I searched for HHCTRL and discovered the application was trying to access the hhctrl.ocx file within the local application folder. Failing to locate it, an error was generated. Copying hhctrl.ocx to the application directory resolved the error in Process Monitor but didn’t stop the messages in Event Viewer.

Unregistering and re-registering hhctrl.ocx in various directories also proved futile.

We then shifted our focus to the discrepancy in behavior between launching the app as a service versus a regular program. That’s when it clicked.

Services operate in a distinct security and user-profile environment. Despite having user-equivalent permissions, services lack the full context of an application running within a user session.

For example, a service might not use the same system variables as a user, leading to a different TEMP directory. Some actions readily available to a user are restricted for services. Having encountered this peculiarity before, we recognized it as a potential factor.

Knowing that the HHCTRL messages surfaced only in service mode and seemed connected to HTML Help, we dug deeper into this component. Research revealed security updates to HTML Help that imposed restrictions on certain operations. We hypothesized that while an application in a user session possessed sufficient permissions, running as a service triggered limitations imposed by the HTML Help security patch, resulting in Event ID 1903.

To test this, I created a Windows Task Scheduler task to launch the Dynamics GP eConnect Programmers Guide, a .chm help file. Task Scheduler allows running applications either within a user session or as a system task independent of user login, similar to a Windows Service.

Choosing “Run only when a user is logged on” resulted in no HHCTRL messages in the Event Viewer. However, selecting “Run whether a user is logged on or not” triggered the HHCTRL message.

Our conclusion: when an application using HTML Help attempts to run as a service or a background process outside a user session, security restrictions on HTML Help hinder its functionality, leading to Event 1903 being logged. This, in itself, is not the core issue.

The problem, potentially stemming from design flaws or bugs, is the persistent, repeated attempts by HTML Help multiple times per second, flooding the Application log with HHCTRL 1903 messages – an annoyance, to say the least.

Having identified the cause, what could be done? While the ideal solution lies with Microsoft addressing the issue, the fact that it has persisted for years made that outcome seem unlikely.

We explored workarounds. Process Monitor highlighted hhctrl.ocx as a factor. Could unregistering or removing it help? My colleague had attempted this before, but the file is locked by Windows, preventing deletion or renaming.

Enter Unlocker, a Windows utility that allows manipulating locked files. Using Unlocker, I renamed the two instances of the OCX files on my server. The problem persisted, suggesting the OCX was still in memory, so I rebooted.

Success! Renaming the hhctrl.ocx file in both the Windows\System32 and Windows\SysWOW64 directories stopped the HHCTRL messages. Launching the application as a service no longer filled the Application log with these messages.

There was a minor drawback. By renaming the hhctrl.ocx files, we effectively disabled the Windows HTML Help system, making F1 help and help files inaccessible. While potentially insignificant on a server, this could pose problems on a workstation.

We presented the customer with these options:

1. Disregard the HHCTRL messages.
2. Disable the HTML Help system.
3. Run the application within a user session instead of as a service.

While not ideal, we considered options 1 and 2 the least disruptive.

And so concludes the saga of the relentless HHCTRL event log messages.

UPDATE: Thanks to Bill from JourneyTeam for discovering a method to suppress the HHCTRL messages using registry modifications.

Create a file named hhctrlfix-32.reg and paste the following content:

1
2
3
4
5
6

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\HTMLHelp\1.x\HHRestrictions]
"MaxAllowedZone"=dword:00000001
"EnableNonInteractiveUser"=dword:00000001
"EnableFrameNavigationInSafeMode"=dword:00000001

Create another file named hhctrlfix-64.reg and paste the following:

1
2
3
4
5
6

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\HHRestrictions]
"MaxAllowedZone"=dword:00000001
"EnableNonInteractiveUser"=dword:00000001
"EnableFrameNavigationInSafeMode"=dword:00000001

Double-click each of these .reg files to import the settings into your registry.

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles. He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him onGoogle+andTwitter

http://www.precipioservices.com