Javascript error prevents TOC, Index, Search from displaying

Question

I generated webhelp from my RoboHelp HTML project and got a javascript error (this.maCom[...]' is null or not an object) when viewing the result. See below for the full error text. As a result the TOC, index, and search do not display. The javascript error can be found in the browser status bar which indicates "Error on page." I found that if I viewed the result from robohelp, the browser that launched shows the TOC, index, and search, but has a security warning about a restriction from running scripts or ActiveX controls. However, when I move the generated webhelp to my production server, the help does not have the security warning, but does produce the error so that the TOC, index, and search do not show. I had performed the same process to generate webhelp about 8 months ago but did not have any error whatsoever. As a matter of fact, that version is still in production and works fine.
In my research of the problem, I found this is the same error as forum message 4063663 (http://forums.adobe.com/message/4063663). I didn't have a second system with RoboHelp to be able to get another whphost.js, however, I diff'd the generated file with the one found in template_stock and found only two lines different. Those differences were only replacing a couple of variables with static text so I don't think replacing this file will solve any problem for me. This was the only forum message I could find that addressed this issue.
I was originally on RoboHelp 8.0.0 when I first encountered the problem, but went ahead and patched to 8.0.2 and still had the same problem. I even created a new simple project. Once I moved the simple project to the production server, it also would not display the TOC, index, and search.
The odd thing is that just 8 months ago, I used the same process to generate (on 8.0.0) the webhelp without any error. The only thing I can come up with is there was a WinXP patch that affected the webhelp generation. By the way, I also tried this in Chrome and that also produced the error.
I'm not sure what is causing this problem or how to resolve the problem. Any one have any ideas?
Versions:
RoboHelp 8.0.2
Windows XP
IE 8.0.6001.18702CO
Chrome 18.0.1025.168 m
Javascript Error
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8; InfoPath.2; .NET4.0C; .NET4.0E)
Timestamp: Wed, 2 May 2012 16:32:00 UTC
Message: Object expected
Line: 344
Char: 2
Code: 0
URI: http://server1/robohelp/whphost.js
Message: 'this.maCom[...]' is null or not an object
Line: 171
Char: 3
Code: 0
URI: http://server1/robohelp/whphost.js

Answer 1

After further research and tests, I discovered the Security Update for RoboHelp 8 and 9 (http://www.adobe.com/support/security/bulletins/apsb11-23.html) posted as an announcement that I had not seen before. I had used the updates feature in the product, but that said I was up to date and did not include this update.
The two javascript files in this patch solve the problem. The TOC, index, and search now display.
Update:
As I further researched the problem (while writing this response), I found files that were newer than the latest security patches I was aware of. In addition, I discovered that my security organization decided to patch with APSB12-04 without me knowing about it. This patch is why my 8.0.0 installation magically quit working. As I look at the security announcement, the bulletin did not include any prerequisites of specific versions the patch can be applied to (8.0.0, 8.0.1, or 8.0.2). Adobe, please give more information on the bulletins so that organizations that auto-deploy will be forced to know what is running before updating. Information like whether they apply to all Robohelp 8 versions or just a specific version. If APSB12-04 was meant to be applied to all 8 versions, then it did not work. It actually broke my installation of 8.0.0 for the generation of webhelp as well as subsequent installation of 8.0.1 and 8.0.2. It looks like they did a better job for APSB11-23. Maybe the security updates should be some sort of service pack that has an installation and a back-out process. Right now, my security organization has overwritten the files based on the specification in the security bulletin.
I am going to try to patch with APSB12-04 again since I have updated the base to 8.0.2 to see if I can still generate webhelp. If I can't view the TOC, I'll have to remove it once again and be "out of compliance."