Robohelp 2020 command line compiling gets jammed randomly all the time

[CUSTOMTOOLS98A4]

We are trying to compile helps for our product dynamically at our build server as part of the build process using the --cl (command line), -o (preset selection) and -l (log file) parameters of RoboHelp.exe.

There are 7 different presets being compiled one after another and the process gets jammed in some of them 95% of time. All presets compile without issues using the GUI. What could be wrong? When the jam happens, there is no log file present yet as it seems to be produced after the command has executed (duh...pretty useless log for jams/crashes...). Couldn't find anything from Event Logs either with a quick look. Is there any debugging/verbose flags or such to better find the root cause?

Br,
Simo Erkinheimo
Product Manager | CUSTOMTOOLS

[Peter Grainge]

Please search before posting. See https://community.adobe.com/t5/robohelp/batch-compile-spotty-in-rh-2020v3/td-p/11761408

There is a known issue that will be fixed in an update.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[CUSTOMTOOLS98A4]

Thank you for your reply, Peter!

With a quick look it wasn't very easy to spot the similarities of that post and my issue. I guess I was looking for different keywords.

Tested with 20s delay between calls, but that didn't seem to fix the issue. Had a hunch that maybe the delay is for the process to have enough time to die, so it could as well be taskkilled after every call. This seemed to produce more of my help files in general but still was very unreliable and didn't actually finish even once. I need to know more details, hints or whatever to get this working now. Is there a file lock somewhere? License issue? Could it be TFS related (as files are actually read-only)?

For us this issue is blocking our production to the point that without a reliable workaround we'd have to revert back to previous system (FlyHelp). So, it's hard to image this wouldn't actually be a huge deal for other users too. This issue deserves to be treated critical and needs to be hotfixed yesterday. What is the schedule for that update?

We have version 2020.3.32. Do we have any other option to get this thing working?

Sorry for my strict tone. I just can't believe that after all the hard migration work we've done, we'd have to just throw it all to garbage because of the very last step that no one had clue would become such a problem, especially as it was tested working!

/Simo Erkinheimo

[Peter Grainge]

I'm the messenger, I'm just another user like you. If you are unhappy with the situation you will have to take that up with Adobe.

See https://helpx.adobe.com/contact/enterprise-support.other.html#robohelp for your support contact options.

My understanding is that Adobe are aware of this and are working on it in with a view to the fix being in the next update. If there was a workaround I believe they would have told me.

Is it different outputs from one project that you want to batch generate? If it is, you can do that via Quick Generate.

You also seem to be saying it was working in an earlier release. You could uninstall and then install an earlier version from Adobe - Support : RoboHelp Support Center : Service Releases. However, that could give you problems as with each drop the projects are upgraded. 

In this topic Opening Corrupt RoboHelp Projects (grainge.org) I explain how you can open topics in an earlier version under "Opening a New UI Version in an Earlier Version or Update".What I can't say is whether that will have a detrimental effect. Obviously you must only go this route at your own risk and with backups.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[CUSTOMTOOLS98A4]

Yes, I'm chatting with the support at the moment and they are looking into the issue.

Thanks for your help, Peter. I thought you'd be even more "an insider" as you seemed to have knowledge that wasn't on the other post. We actually migrated from FlyHelp to RoboHelp and everything else is done related to that migration except that we now face the issue with the build process. I'm just super frustrated about this. We haven't tested with earlier version of RoboHelp. We really need to revert our migration completely and ditch Robohelp unless we get a workaround. This screws up our own product release schedule.

I'll post here if/when I get new information from the support.

[Peter Grainge]

Yes I have a close relationship with Adobe but I can only relay what I know. I believe I said in the other post that the issue was known and that Adobe are working on it for Update 4.

Whilst there is this issue at the moment you haven't explained why it is so major that you would throw away all your work. How many projects are you having to generate in this way?

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[CUSTOMTOOLS98A4]

We are developing a software and dynamic help generation is part of our CI/CD pipeline. Source files for helps are HTML, and hosted in our on-premise TFS. We migrated from FlyHelp to RoboHelp because we had in mind that more people could start contributing to our Helps with the ease of RoboHelp's user interface compared to raw HTML. RoboHelp is btw very bad with TFS but we figured out we could take that hit as we all have Visual Studio & its source control explorer anyway. However, it was still a requirement that the build server should able to generate the CHMs from those source HTML files, which then are embeded to our product's installer, all during that same build process. This happens every single day as release build and every single hour as debug build, for 4-8 separate development streams each having single RH project but 7 output presets (at the moment). There is absolutely no room for not having this reliably working. At the moment our next major release stream is blocked in order to get it producing builds, we'll have to resolve this issue. Reverting the migration is the last option but we'll have to take it unless the issue gets resolved asap.

I'm currently in process of investigating it myself what DLLs and file handles the RoboHelp process locks, just to figure out some sort of workaround myself. The support just validated what you already said but wasn't able to give any otherwise useful pointers.

[Jeff_Coatsworth]

I would highly doubt that you're making enough changes to the docs that warrants sucking in a new build of the output each hour (or even each day). Just leave the same version of the output in the location where the build process can pick it up each time it runs - your software won't care that the doc output is slightly dated, only that it's there to be scooped up in the build.
Of course, YMMV, so good luck.

[CUSTOMTOOLS98A4]

Yes of course we could change the build process, however, it wouldn't be as simple as that. There's also a clean-up routine after each build, too. Changes we do to the stream are seldom help related, yet the helps are part of every build and some of the content is automatically generated. We could compile the CHM:s manually and check them in to TFS on as-needed basis but that would be much worse than what we had. We did talk about doing it only upon release but also that would be step down from previous as then all the content validation would pile up to latest minute.

Instead, I have continued my own investigations and had some promising results with restarting AGMService and AGSService before every output preset compilation.

[Vivek Kumar]

Hi Simo,

I am from Adobe. My apology for the trouble you are facing. This bug has been fixed in update 4 beta but that is not ready yet for the production use. Issue is that there is some communication mismtach between the threads and exit is not clean. Restarting AGMService might be giving some more time for the exit to clean up. Have you tried killing all RoboHelp.exe processes before the next job? 

Thanks,

Vivek

[CUSTOMTOOLS98A4]

Thanks for the reply!

I noticed the same things with the sub-process communication. You are quite heavy on that area 😉 I was pretty darn near to start implementing my own watcher to monitor them in order to restart the process immediately on zero CPU load but I also was a bit unsure if it actually was a semaphore leak (noticed with Process Explorer) which would explain the issue reproducing also after process restart. I did have Taskkill /IM "Robohelp.exe" /F in my batch script before every call but that didn't seem to make a difference. I'm not 100% sure though if taskkill actually didn't succeed taking down the process which is also possible in some cases like shared locks in inter-process communication. I did try restarting both AGMService and AGSService before every call but also that didn't eventually make any difference. I also tried clearing all caches I found (%APPDATA%\Adobe and %APPDATA%\Adobe Robohelp 2020) before every call, and I tried executing everything with different user privilege levels. No luck with anything.

I did manage to get the batch process completing few times so that robohelp gui was up & running at the same time but this trick didn't seem to work during the build process.

At the moment I've pretty much given up. We have our next release baking at the moment and I'll have to continue dealing with this issue immediately after its release on week 6. Luckily we had decided to have this one release in between as a safeguard for the "help system migration" -project. I'm sorry to say but we have no other viable option than to revert the migration after 2 weeks unless we get our CI/CD pipeline stable.

I'd definitely appreciate any pointers you could give to solve this, no matter how technical.

[Vivek Kumar]

It could be all the processes are not getting killed. You can try putting a longer sleep in between and check the task manager during that time if that was the case. My team is in India and today is a holiday. Allow me a day to come back on this. I sincerely hope to provide you some workaround.

[MayankGupta · Accepted solution]

Hi Simo,

I have created a custom batch script as a workaround for this. Following are the steps:

1. Create a batch file with the following code: (let's say "watcher.bat")

:start
taskkill /F /IM "Robohelp.exe" 
START %*
:check
SLEEP 10
setlocal enabledelayedexpansion 
set /a Cnt = 0
tasklist | findstr /i /L /C:"Robohelp"
FOR /F "tokens=*" %%A IN ('tasklist ^| findstr /i /L /C:"Robohelp"') do set /a Cnt+=1
IF %Cnt% EQU 0 GOTO end
IF %Cnt% EQU 5 GOTO start
IF %Cnt% EQU 7 (GOTO start) ELSE (GOTO check)
:end

 2. Add CALL <Path_to_watcher.bat> "" in front of output generation command, something like:

<output_gen_cmd>

to

CALL <Path_to_watcher.bat> "" <output_gen_cmd>

Try running the batch output after making these changes.

In my testing, this did fix the issue. Please give it a try once and let me know if this works for you as well.

Regards,

Mayank Gupta

[CUSTOMTOOLS98A4]

Mayank,

With preliminary tests, the watcher seems to work great!

Just a minor change that SLEEP is not at least generally available Windows command, so that could be replaced with

ping 127.0.0.1 -n 11 -w 1000 >nul

I'm very, very pleased with your customer care. Thank you very much for your whole team!