This content has been marked as final. Show 8 replies
I know we're several months removed form your publishing error post...did you ever discover a resolution?
I have users who are getting the same error and support has not been helpful at all with this. When the users get the error, I see a cascade of "dynaZIP" errors on the Robohelp Server console.
One thing that I did find on our server is that there were 65,535 RHS*.tmp files in the c:\windows\temp directory and this looks like where RH places files temporarily while zipping them. I deleted a large number of these files and the errors have now stopped.
Since 65535 is the largest 16 bit binary number (1111111111111111) perhaps there's a 16 bit binary counter in the application for tracking these temp files.
For the large number of tmp files (which I see, too!) that is the maxinum number of temporary files in a folder for the GetTempFileName function in Windows, http://msdn.microsoft.com/en-us/library/aa364991(VS.85).aspx
I'm getting the same problems as nu_sheck and Scott_I. Plus the server is bombarded with ProtocolHost.exe errors until IIS curls up and dies. I'm trying to upgrade to RoboHelp Server 7. I thought I had an installation error. Maybe it is installed correctly as I'm getting the same errors as everyone else.
I'm coming from versions 3 and 4 of RoboHelp Server. I've installed RoboHelp Server 7 on Windows Server 2003 SP2. IIS 6.0 has a wonderful feature in that the application pool can be configured to restart for various reasons.
I've read here that you need to have the Windows Indexing service running as well as the Robohelp Windows service. Both are running under the default account, LocalSystem.
The application pool is also running under the default account, NetworkService.
I have excluded both the C:\WINDOWS\Temp and Robohelp product files from the scans of our anti-virus program.
In addition to the thousands of RHS*.tmp files I also get JET*.tmp files in C:\WINDOWS\Temp. I'm guessing that these are from the jet engine ACCESS database.
If the Microsoft Indexing service is needed by RoboHelp, why isn't it configured? Should the Indexing service exclude C:\WINDOWS\Temp?
We move our INETPUB folder to the D: drive. We also have a D:\Program Files folder where RoboHelp is installed. We have two web sites (Application Help Site and Business Help Site) using the default application pool.
From the forum I see that the ProtocolHost.exe errors began with version 6 and are still present in version 7. My understanding is that the RoboHelp Windows service is a feature of versions 6 and 7.
We use RoboHelp with our local CRM application. I'd like to know if anyone is using RoboHelp Server 7 on Windows Server 2003 in Production.
Thanks for your help.
Sorry to blather on. We are using VMware. All RoboHelp servers are virtual. I'm also using local ACCESS databases. This was an attempt to keep it simple.
Our experience with versions 3 and 4 of RoboHelp server were OK, except for the need to do an IISRESET when someone attempted to publish. We now have moved to version 7 of the RoboHelp client. Does anybody know if this will work with the older versions of the server? I thought it required version 7 because it was Unicode.
Does anyone know what the RoboHelp Windows service does? Can it handle multiple web sites? Is it multithreaded?
What is ProtocolHost.exe and what is it trying to do?
We were hoping that RoboHelp Server 7 would fix the "IISRESET problem". We can't use it in the current state.
When we publish and get errors, it seems to recover. I think there are broken links because RoboHelp crashed. We can continue to publish. We get errors and eventuall the web server dies. Why isn't there some utility to verify that the links are good?
It the web app throws errors when we publish through the client, would we be better off just copying the files over and dropping them into the publishing folder on the server?
Hey guys I see you are having as much fun as me. Ok here is what I know. IISReset and many of the other problems related to RoboHelp Server 7 not playing well with Windows Server 2003. To my understanding RoboHelp Server 7 and Server 2000 are a better match. Which really is not a solution for me. A person I work with became a perfered member with Adobe and sends in issues with the product so the can improve it. They said RoboHelp Server 8 will address most of the issues we are experiencing.
So here is the game plan I have taken.
- I configured RoboHelp Server Service to automatically restart after a failure. Go to services, select RoboHelp Server Service, go to properties, select Recovery Tab and set after first failure - restart the service.
- We still have issues posting to the server from time to time in which we do a manual reboot.
- Rebooting is not the solution I want but I'm currently holding until the release of RoboHelp Server 8. Which I'm hoping will fix the majority of issues
In what I have read Adobe purchased RoboHelp product and did not have much support or documentation on it. I believe they are working on a full stable product with Version 8 with good support. So I would start planning on upgrading when version 8 comes out.
I also am running the software on VMWare which comes in handy becuse I have had to roll the server back once to get it working again. I currently run 6 different websites on the product.
I,too, configured the RoboHelp Windows server to constantly restart. This is a sure sign that something is wrong. We can't tolerate the reboots of the server.
I hope version 8 is on the current server platform, Windows Server 2008. They'll have to deal with IIS 7.0.
We were told to publish Clownfish. We have a CRM app and wanted the context-sensitive help. The sample amp only demonstrates some of the features.
Any idea when version 8 will be made available? 2 months? 6 months? 1 year? Don't know how long I can wait.
Should be a free upgrade, as it seems that RoboHelp Server 7 is so flawed. Don't they test it before it's released? The errors we are encountering are not as a result of users doing anything incorrectly - if they were, they should be able to provide better advice than 'try re-installing'.