ORF No Longer Hangs on Windows Vista

This has turned out to be a lot more interesting issue than I expected. I was thinking about contacting MS PSS and so I wrote an as-simple-as-possible test application to reproduce the issue. Surprisingly, the test app worked flawlessly on Vista, so started investigating the differences.

First, my test application was using the HTML Help API (hhctrl.ocx) directly and was statically linked (which means that Windows would not allow the test app to start if hhctrl.ocx is not available on the system path). ORF, on the other hand, uses a third-party library that loads hhctrl.ocx dynamically and uses some registry magic to determine the location of hhctrl.ocx, regardless the system path.

My initial thought was that the ORF Log Viewer and the test app was using different versions of hhctrl.ocx and the Log Viewer found the broken one. To test my theory, I started both applications and checked the loaded DLLs by Process Explorer just to find that Log Viewer doesn’t even have hhctrl.ocx loaded. Wow, that makes sense! Calls to hhctrl.ocx will hardly work if it’s not loaded. Actually, our calls to HtmlHelp() ended up in the middle of invalid memory.

I checked the library code again, now digging deeper in the loader code and found that it tries to determine the location of hhctrl.ocx by checking its COM registration under HKCR\CLSID\{adb880a6-d8ff-11cf-9377-00aa003b7a11}\InprocServer32. Under pre-Vista operating systems, the default value for this key used to be simple String Value (REG_SZ), containing e.g. “C:\WINDOWS\system32\hhctrl.ocx”. On Vista, however, this is an Expandable String Value, pointing to e.g. “%SystemRoot%\System32\hhctrl.ocx”. The library fails to check for this and to expand the the value into a real file system path, so it also fails to load hhctrl.ocx. Even worse, the library does not offer proper error handling, so the caller application is not aware of the failed load and calls the trusted HtmlHelp() call, resulting in some accidental endless loop.

End of story, library fixed.

If you can’t wait for ORF 4.0 to run the Log Viewer and the Reporting Tool on Vista, you can apply a manual fix as described below:

  • Run regedt32.exe as Administrator (%SystemRoot%\System32\regedt32.exe)
  • Open the HKEY_CLASSES_ROOT\CLSID\{adb880a6-d8ff-11cf-9377-00aa003b7a11}\InprocServer32 key
  • Change the %SystemRoot% variable in the value to C:\Windows (or what is your local system root path)

Expect a little fun with permissions. Ah, and don’t forget to change it back to %SystemRoot% when ORF 4.0 ships—I am not aware of any problems with hardcoding the system path, but who knows.

4 thoughts on “ORF No Longer Hangs on Windows Vista

  1. allianz

    Quite possibly your other issue has a simple fix also.

    see http://msdn2.microsoft.com/en-us/library/ms172485.aspx

    “The SMTP service is required for using the SMTP delivery protocol, but it is not installed with Windows Vista. To use the SMTP delivery protocol on Windows Vista, you must separately install an SMTP service.”

    it seems that this service is not installed automatically, but you can install it by the usual means. I have not yet tried it, but this would be “control panel”/”Add remove software”/”Windows components”.

  2. Peter Post author


    The SMTP Service is not listed there, it is fully missing from Vista. I think the SQL Server guys meant to install a separate SMTP server software.

  3. allianz

    What version of Vista are you using?

    I believe that SMTP for IIS 7.0 is only available on: Home Premium, Business, Enterprise and Ultimate versions.

    see http://windowshelp.microsoft.com/Windows/en-US/Help/a8075305-2a45-4e84-bbcc-7e73c87db82d1033.mspx

    You might also like to review this article:

    It seems that the metabase has gone, replaced by the system of xml config files that all .NET applications use: Enterprise, Machine, Application. By default most configuration occurs in the Application. For example you can build a web application that includes a virtual directory and set up the virtual directory simply by copying files from one location to another.

    ADSI and WMI methods of updating configuration still exist in the form of an emulation that updates the config files.

  4. Peter Post author


    I was using Vista Ultimate and Vista Business, neither has IIS SMTP. In the blog link I previously posted, a guy name Chuck asked where the SMTP Service is from Vista and BillS (MSFT) responded “[…] the SMTP server has always fit under the ‘IIS’ umbrella, but wasn’t actually owned by the IIS team. The folks that owned it have decided to no longer ship it in Vista (the Windows client sku) and instead are only shipping it in Longhorn Server.”

    Steve Schofield confirms this at http://weblogs.asp.net/steveschofield/archive/2006/12/19/iis7-post-23-vista-and-smtp-server-where-is-it.aspx and also adds that even on Longhorn Server, it is quite “hidden”: http://weblogs.asp.net/steveschofield/archive/2006/05/29/Looking-for-SMTP-service-in-IIS-7-_2F00_-Longhorn-beta-2_2E00_.aspx

Leave a Reply

Your email address will not be published. Required fields are marked *

AlphaOmega Captcha Classica  –  Enter Security Code