We're currently facing some issues trying to start a Service in Windows, which is an executable file and the output of a compiling process using .NET framework for C++ (Windows\Microsoft.NET\Framework\v2.0.50727). We are able to compile, start and execute the exact same service in our DEV Environment, which consists of Windows 7 installed in Virtual Box with VisualStudio2005 (it's old software, I know...).
When we do it in our Test environment, we get a timeout error when trying to start the Service (1053: The Service Did Not Respond to the Start or Control Request in a Timely Fashion.). The server is running WindowsServer 2008 R2 Standard. We already tried to change the timeout time, without success. We also compiled the source code using the same Visual Studio 2005 SW and although we were able to compile it successfully we are still getting the same timeout message.
We are currently trying to understand what's objectively causing the different behaviour. The most obvious difference is the windows version, naturally, but since the compilation output appears identical and there are no errors during the compilation process in both environments and both output logs are identical as well we are running low on ideas to identify and validate objective differences. Our latest approach consists in trying to understand if by using Dependency Walker (dependencywalker.com) we are able to identify any issue regarding DLLs (we also checked if there is any corrupt DLL or system file in the environment and there isn't any, using the windows command for it). We're also checking some of the suggestion made on the following post: Error 1053 the service did not respond to the start or control request in a timely fashion.
Any one faced a similar issues? If so, can you suggest any kind of approach to identify the reason why the service isn't staring, other than the ones here mentioned?
Thanks in advance.
We ended up extending the timeout time regarding Service startup in Windows to 10 minutes followed by the necessary restart and we managed to start the service normally and almost immediately, which makes us think that the timeout time was never really an issue here. Although we haven't been able to pinpoint the exact cause we are still inclined to think that it was a Windows/Server related issue.