Windows Service won't start after OneAgent instrumentation

[carlos]

When trying to instrument OneAgent under Windows, on a particular application called ArCGIS, used for oil and mining data analysis, the Windows Service which handles app start and stop does not start at all.

If we instrument manually, on the .bat files which run the JVM and Tomcat, through command line it works perfectly.

But customer would like to continue using one single Service to manage the application. I thought it was a matter of the service timing out waiting for our instrumentation + application start up, could it be? Any thoughts on this? There are no warnings or issues neither at the app log, nor the oneagent log.

[JamesKitson]

I'd probably open a support case for something like this.

James

[Julius_Loman]

I've encountered similar issue a while ago and this was caused by some specific JVM parameters for Tomcat hidden somewhere in the Windows registry for the startup service. After removing the (unimportant!) parameter the service started normally.

Unfortunately, I don't remember more details.

[carlos]

Thanks Julius, I'll check on the registry then...

[Julius_Loman]

Anyway, there was a message in application logs, oneagent logs or windows event log pointing instrumentation failure. Be sure to check all possible places for startup errors.

[jonathan_kenned]

We had this issue. It was caused by the oneagent not being able to talk back to the security gateway. For us it was firewall block.

[carlos]

@Julius L.

There was not relevant information in the different logs, but I ddi find a bunch of arguments and parameters within the service...I guess some of them are really not needed...is this similar to your finding Julius?

[Julius_Loman]

Unfortunately no, the situation I've encountered was some other instrumentation parameters conflicting with Dynatrace.

Since you are referring to windows service only, did you try to reboot the server?

Since the service is not starting, there should definitely be a log entry somewhere (probably in Windows Event Log).