Are you using the 32-bit versions of TurboFloatServer on a 64-bit machine (there's a bug that the customer might be hitting). Or are you using custom paths to either the TurboActivate.dat or the TurboFloatServer-config.xml files?
Case where TurboFloatServer service won't start on Windows Server 2008 r2
I have a client that installed the TurboFloatServer on a Windows Server 2008 R2 computer, but the service didn't start. The log shows nothing of interest (just two successful activations). When the user goes into the Services window, they can see clearly that the service didn't start. If they try to start it from the Services window, they get the following message:
"Windows could not start the {name of server} service on Local Computer.
Error 1053: The service did not respond to the start or control request in a timely fashion."
They CAN, however, start the TurboFloatServer from the command line.
Anything obvious that could be going wrong? The LimeLM web interface shows clearly that they are activated. They are not on a VM.
They are using the 64 bit version of TurboFloatServer on a 64 bit machine. We are using custom paths to both the .dat and the .config files. Everything was renamed- the TurboFloatServer is named something different, the .dat and the .config files are named differently, etc. I would put the names on here, but I would rather not do so for fear that my clients might Google the product and come up with this site (which I don't think would be helpful to them).
I would presume that if the user entered the paths to the .dat and .config files incorrectly, then the -i installation wouldn't have worked in the first place, right? It wouldn't have even installed the service into Windows.
I would presume that if the user entered the paths to the .dat and .config files incorrectly, then the -i installation wouldn't have worked in the first place, right?
Well, it depends. But my guess is that the paths are screwed up. So, tell them to run the -i command again and use the full paths to the TurboActivate.dat / config file (whatever they're named on the machine).
Also, it might be a case of a severely corrupted config file. But if they can run the TFS using the -x command, then that's not the problem.
Ok, thanks. I will have them try that and then get back to you on how it turned out.
Ok, so it was the case that they were running the x86 version of the TurboFloatServer on the 64 bit machine. I actually had to remote desktop in to figure this out, but that was the problem. They seemed to think that they needed to put the installation of the TurboFloatServer in the same directory as my app, and since my app is x86, they chose the x86 version of TurboFloatServer. Sigh. Thanks for your help.