Rick Hi

I am considering the RoboEngine 8, however, I am concerned about all of the negative comments I have seen with previous versions.  My draw to the server edition is the ability to get feedback from the end users of our products.  Also the ability to generate reports on search terms, where users navigate etc. are of great importance in making future improvements to our online help.  Are there additional benefits that I should be aware of as well?  Could you elaborate please?  Also does Adobe have any classes, Webinars, or consultants that could help in gaining a better understanding of the new RoboEngine 8 and help to set it up and integrate it with RoboSource Control?

I currently have RoboHelpX7 and I did have some initial issues when I upgraded to x7 from x6 previously, but I believe I have resolved all of those issues.  I would also like your opinion on the Technical Communication Suite 2 that is available.  I'm drawn to that because of the inclusion of FrameMaker that can handle printed documentation much better than exporting it into printed documentation from RoboHelp into Word or a PDF.  I also see that FrameMaker is integrated with RoboHelpx8 in this package and when you make a change in FrameMaker you can also update or add the info to a Robohelp project topic with minimal assistance.   There are also other products included in this package.

Has anyone purchased the Technical Communication Suite 2 product and if so, what was your experience?

Thanks,

Lana 

Hi Lana,

You can also check out the following links for some info about RoboHelp Server 8

http://blogs.adobe.com/techcomm/2009/03/adobe_robohelp_server_8_instal lation.html

http://forums.adobe.com/thread/88064?tstart=0

Tulika.

Update on ProtocolHost.exe error

After nearly a year of production use of the RH 7 using RH7 Server, I've had little problem with the server crashing or hanging due to the following error:

Reporting queued error: faulting application ProtocolHost.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.4455.

This error seemed to occur with no consistency (see above entries).  But if it occurred too many times in a server session, the server's response would degrade and sometimes hang.  My initial solution was to weekly reboot the server and delete temp files created at execution of calls for the RH application's web site.  This "kept the problem at bay". 

Now the mystery.  After many fingers pointing to RH 7 Server about this problem, I've found that the error has not occurred since early November as reported in the server's event viewer. In fact there has not been one application error posted to the viewer since November.  RH 7 user usage has increased dramatically over the last few month's. It is the only application on the server.  I have no explanation for this miracle and haven't changed a thing to the RH releases of RH7 and RH7 server. This leads me to believe that something in the server environment changed - perhaps a Microsoft update to the ntdll module or something. This would seem to vindicate RH server software unless it too was upgraded through server or network upgrades. 

Regardless, the problem appears to be solved in my environment. 

Hi John,

Not sure how to find the .net framework we're on. Is it in: C:\WINDOWS\Microsoft.NET\Framework ? If so, there is no last update info around that date.  I'm attaching a WordPad file that shows our event viewer for Security, Our Last Application Error, and System events all around the 11/10/09 Time frame that this appeared to fix itself.

I'm not a server guy (but I play one on TV), but my suspicion is that maybe the Service Pack installed (highlighted) later that day had the framework change that took care of it.

Thanks,

Jim

Jim Dages

Technician II

Payroll & Benefit Services

University of Colorado

3100 Marine Street, 6th Floor

Boulder, CO 80309-0575

(303) 735-5495

jim.dages@cusys.edu

Please consider the environment before printing this email.

CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you.

John,

There are 3 .NET Frameworks in Add/Remove:

2.0 Service Pack 2

3.0 Service Pack 2

3.5 SP1

Update history reveals One November 4, 2009 Automatic update to Windows not Windows Server 2003.  Its Windows Update Agent 7.2.6001.788 but this was before the problem fixed itself. All other Server updates were in September and December.

Try a Docx version of the log.

Thanks for your interest.  This ProtocolHost error was my reasoning for moving to RH8.  We're thinking of expanding our RH usage to a second website and I know the Server software is all new in RH8. Now that the error appears resolved, I'm not sure what to do. We had such a hard time getting one website working with the server in RH7.

Jim

Jim Dages

Technician II

Payroll & Benefit Services

University of Colorado

3100 Marine Street, 6th Floor

Boulder, CO 80309-0575

(303) 735-5495

jim.dages@cusys.edu

Please consider the environment before printing this email.

CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you.

The sad thing is I may be the last living human to be using RH Server 7.  But I think I've found what's causing the Protocol Host exe error.  I also have a simple 'work around' based on my findings. Sit back with a cup of joe, read it and weep.

History of the RoboHelp Server Protocol Host exe issue

After intense investigation of the Protocol Host exe issue with RoboHelp (RH) Server 7, I believe I understand what is causing the problem.  RH 7 Server builds temporary files in the C:\Windows\Temp directory when the first client session is requested through the RH 7 application website or by a RH Server routine that runs at midnight every night.  These files appear to be the storage for the index as it is loaded to the application.  And I believe they are reused with each session requested from the server – this is key. They also are not deleted by Windows after a session ends or the server is brought down.  Our site has been running a weekly routine to delete all RH temp files in order to keep the count of temporary files down because of the Protocol Host exe errors.

In our environment I noticed that if all the RH temporary files were deleted before a session was requested from the server, the server would create temp files with the date and time stamp of the client request (approx. 14 to 116 files in our case).   But I also noticed that 4 RH temporary files dated from months before also appeared in the directory.   The first session requested from a fresh server session does not generate a Protocol Host exe error to the application event log. But, during its initial load, once it creates the first set of temporary files including the 4 previously dated files, any subsequent sessions:

·         Work (“over time”) to load the index, laboriously loading as the server application tries to create an index. 

·         Or will partially load the index leaving a ‘loading index’ message in the application pod

·         Or will not load the index at all (leaving a ‘network 500’ message indicating a timeout inside the index pod of the application)

And all these subsequent sessions:

·         Receive the Protocol Host exe error in the Server’s event log

·         Send an “Error messages were returned from the IndexCreator” message in the Troubleshoot log  of Adobe RH Server Configuration Manager

·         Create more temporary files for each session including 4 more of the same previously dated files  

Success

I simply deleted the 4 ‘rogue’ previously dated temporary files and requested a client session from the website in order to test.

The session loaded like lightening and the index was immediately (completely) there:

·         No  Protocol Host exe error

·         No “Error messages were returned from the IndexCreator” message

·         No additional temporary files created

I started 3 more sessions with the same non-errant results.

Testing

With a new server environment after a reboot and with no RH temp files in the Windows directory, the initial session request created temp files with a time stamp of the request time and a set from the previous session (from the registry?) and the 4 temp files that are suspected to be corrupt.

These 4 files are named differently with each load but have the same “date modified” time stamp each time they are loaded.

-          RHxxxx.tmp       2/25/09 3:28 PM

-          RHxxxx.tmp       2/20/09 3:12 PM

-          RHxxxx.tmp       3/03/09 2:43 PM

-          RHxxxx.tmp       3/13/09 9:28 AM

This is different (corrupt?) from the other temp files that are date and time stamped based on the time the system builds an index. 

Once I deleted all suspected corrupt files (found by listing the directory by the date column), I loaded as many as 6 client sessions within about 10 seconds with no new temp files created and no corrupt files sent to the temp file folder.

Now, I suspect that the reason these ‘rogue’ temporary files are showing up is that they are somehow associated with the server’s registry. They are pulled in when the server loads temp files during its midnight routine or the first time an application session is requested and uses that corrupted set the server created at midnight. Each requested session appears to create its temp files in sequence Alfa-numerically. RH or Windows must keep track of its last used number and start with the next number each time. The 4 rogue temporary files are recreated with names that are in sequence with the other temp files being created.  But the rogue files create times remain the same.  The first rogue file seems to consistently appear as the 12^th temp file created but each set of files created appear to be almost randomly numbered based on create time.  It also appears that RH Server continues to create sets of temp files that include the rogue files until it is satisfied that it has a good set for the index.  It uses the most recent session’s files as well as new sets in its midnight run and creates up to 120 files.  In our case these 120 files appear to be redundant reloads in sets from 28 to 44 files.  However, each set includes one rogue file in the middle of the midnight set and the previous session’s time stamp set even though the previous session didn’t include the bad file.  So, RH Server’s midnight run appears to always load rogue files where a ‘clean’ set of temp files seems to be created by the initial application request;   unless there are rogue files already in the directory. If there are corrupt files in the temp directory, new application requests create new sets of temp files that include more corrupt files.

Simply put, these 4 rogue temporary files are essentially corrupt and wreak havoc on the application when it tries to open subsequent sessions.  When there is a session request, the RH application goes out to the temp files and says, “Wait a minute, who are you? Uh oh, I need to create a new index because you shouldn’t be here and you have corrupted my perfectly numbered temporary file system that I want to attach to this session as well.  Oh my, I’ll have to uniquely number these new files (I should be able to delete you all but I don’t)…. I’ll create a new set of files. I’m feeling sick, I guess I’ll just serve the documents and try to figure who’s using what later”.  Network response time, the size of the index and the number of temp files will decide how much of an index build you get.  ‘IndexCreator’ error is logged.  And as more and more sessions are requested the situation ‘snowballs’ as the application agonizes, “Oh, no there’s hardly any room to work and the network will only give me so much time.  Look at all these uniquely numbered files. I’m going to throw up – Blah, Protocol Host exe error!” That session’s index won’t work.  After about 10 Protocol Host exe errors, our server response is very slow and sometimes even hangs. Loaded sessions don’t have working directories, and several sets of files including the 4 rogue files have been generated in the temp file directory.

RH continues to create new sets of temp files for each requested session as long as any of these rogue files are in the temp directory.   

Another Test

I tried another reboot of the server, this time keeping the ‘good’ set of RH temp files (no corrupt files) in the directory as I rebooted.  After it came up I looked at the Windows temp directory to make sure no new files were added.  And then, I requested a session from the website. Right now the temp files appear to work for new sessions.

Watched this good session of the server (with no corrupt files and working) to see what happens to the files at 12:00 AM when the Server tries rebuilding the index  I kept 2 sessions running over night.

In the morning – Looked at server

·         RH Configuration Manager Troubleshoot - no new messages.

·         Event Viewer – Application error at 12:00 AM - Protocol Host exe (from RH Server routine).  

·         New Temp files were added at 12:00 AM including the 4 rogue files. 

·         2 sessions left running overnight indexes are working fine initially.  But, hitting their indexes generated RH Troubleshoot ‘IndexCreator’ message (this is because of the 4 new corrupt temp files created since they became active sessions).   No new bad files or Protocol Host exe errors are created. 

Deleted the 4 bad files and searched index on existing 2 sessions.  Index did not work and Protocol Host exe errors were generated.  New temp files including the 4 bad files were generated again.  Deleted 4 bad files and hit the index on existing sessions – tries to reload but fails to reload it all. They get RH Troubleshoot Indexcreator messages but no Protocol Host exes.  So it appears existing sessions created IndexCreator messages when rebuilding the index – becoming corrupt.  New sessions create Protocol Host exe errors if the bad files are there or they create the bad files when building an index.

Deleted all temp files and emptied recycle bin

Started a session – perfect no errors, no bad temp files, 14 temp files created (344k each), index works fine.

Started another session – perfect again.

Conclusions

When RH Server nightly routine runs at midnight:         

It appears to try to verify there is an index at midnight. But it goes ahead and creates a new set of temp files and another set based on the previous application session. And it includes the 4 corrupt files in its ‘midnight’ set. 

RH Server sends “Error messages were returned from IndexCreator” messages every night at midnight only when the previous application session had corrupt temp files. The “Error messages were returned from IndexCreator” message appears when the server or a session references a bad set of temp (index) files in the windows directory.

The Protocol Host exe error happens when the application tries to build a session index with a corrupt set of temp (index) files.  

When RH application requests a session from the website:

·         If there are no temp files in directory, The server will build temp files with 4 corrupt files and generate Protocol host exe error

·         If there are temp files with 4 corrupt files, server will build another set of temp files with 4 corrupt files and generate a Protocol host exe error

·         If 4 corrupt files are deleted but temp files are left, session will use the temp files and load correctly no Protocol host exe error and no ‘Error messages were returned from IndexCreator’

When RH existing application sessions reference a set of temp files with 4 corrupt files:

·         Creates ‘IndexCreator’ messages when rebuilding the index but no Protocol Host exe errors

·         Eventually loads only partial index if the temp directory files change during its session.

Temporary Solution

Run the current weekly ‘delete all temp files’ routine on a nightly basis after the midnight RH routine that loads the corrupt files.  This will start each day with a clean Windows temp directory (with no corrupt files) when the first application request occurs.   The first requested application session will create a good (clean) set of temp files and the madness of the ‘snowballing corrupt, redundant temp files’ will stop.

Permanent Solution

Determine where the corrupt file names are coming from and delete them.

What Changed? Ideas on why the RoboHelp application errors stopped between 11/10/2009 at 11:01 to 3/22/10 at 10:30 AM

Each night at midnight a RH routine logs onto the server to rescan server documents.  This has been in place since we’ve implemented RH.  The application event log reveals that on 2/15/10 the “Error messages were returned from IndexCreator” messages started again. This indicates that there were corrupt temp files in the windows temp directory.

Our weekly routine wipes out the RH temp files so each server session’s first request uses a stored or found number (Registry?) for its file numbering start.

So RH or Windows determines starting number for temp file names and creates/moves 4 files with consistent 2009 dates into the temp file folder. 

Assuming these file names come from the registry, if someone recently changed the registry on the server (around 3/22/10), it would explain how our environment miraculously had no errors for 4 month’s with no application errors and then mysteriously re-appeared. It was possibly corrupted, or maybe reloaded with an old one (which included the corrupted temp files). I’m not sure where else these files/file names would be stored.  Or did some maintenance to the registry cause a change that brings in these 4 corrupt files? 

RH Trouble Shoot gave a message on 3-15-00.02 Unable to locate the URL ‘intruvent/jsp/admin/Login.jsp’ – this appears to be an access error.  This occurs at midnight in the log, the same time RH tries to build its index and sends the message that the “Error messages were returned from IndexCreator” message is sent. 

Or the Server’s event viewer Application Log shows that the NetBackup SAN Client Fibre Transport Service stopped being started and stopped every Sunday Morning after 3/21/2010.  It had done this weekly since the server was brought online.

The Server’s event viewer Application log shows an Information message from HP Port Resolver on 3/12/2010 at 10:58:56 PM stating “the description for Event ID (0) in Source (HP Port Resolver) cannot   be found.  The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer.”  The last HP Port Resolver was 4/23/2009 before this one. And it hasn’t sent a message since the 3/12/2010 message.

The Server’s event viewer System log shows that an Application Popup for the Service Control Manager occurred on 3/7/2010 at 6:10:41 AM stating that “The RS03 Server service failed to start due to the following error:  The service did not respond to the start or control request in a timely fashion.

The Server’s event viewer System log shows that for many months the Service Control Manager reported that each Sunday morning around reboot time that the RoboHelp Server Service service terminated unexpectedly. It has done this 1 time(s)…. Restart the service.  This is was pretty consistent on Sunday mornings last year.  And now is less frequent.  Could these restarts have caused a ‘clean up’ of the directory?