One failure that commonly occurs when starting a Windows service is caused by missing DLLs, which usually results in an error window stating a particular DLL cannot be found. Fixing this problem can often be a trial-and-error process because the DLL mentioned in the error may depend on other DLLs that are also missing. It is important to understand that a Windows service is launched by the operating system and can be configured to execute as a different user, which means the service’s environment (most importantly its
PATH) may not match yours and therefore extra steps are necessary to ensure that the service can locate its required DLLs
1.
The simplest approach is to copy all of the necessary DLLs to the directory containing the service executable. If this solution is undesirable, another option is to modify the system
PATH to include the directory or directories containing the required DLLs. (Note that modifying the system
PATH requires restarting the system.) Finally, you can copy the necessary DLLs to
\WINDOWS\system32, although we do not recommend this approach
2.
Failures encountered by the Ice run time prior to initialization of the communicator are reported to the Windows event log if no other logger implementation is defined, so that should be the first place you look. Typically you will find an entry in the
System event log resembling the following message:
Error code 1 corresponds to
EXIT_FAILURE, the value used by the
Service class to indicate a failure during startup. Additional diagnostic messages may be available in the
Application event log. See
page 276 for more information on configuring a logger for a Windows service.
As we mentioned earlier, insufficient access rights can also prevent a Windows service from starting successfully. By default, a Windows service is configured to run under a local system account, in which case the service may not be able to access resources owned by other users. It may be necessary for you to configure a service to run under a different account, which you can do using the Services control panel. See
page 1782 for more information on selecting a user account for your service, and
page 1788 for instructions on configuring the access rights of files and directories.
Your choice of user account determines whether you receive any notification when the Windows Firewall blocks the ports that are used by your service. For example, if you use
Local Service as recommended on
page 1782, you will not see any Windows Security Alert dialog (see this Microsoft
article for details).
If you are not prompted to unblock your service, you will need to manually add an exception in Windows Firewall. For example, follow the steps below to unblock the ports of a Glacier2 router service:
Note that adding an exception for a program unblocks all ports on which the program listens. Review the endpoint configurations of your services carefully to ensure that no unnecessary ports are opened.
For services listening on one or a few fixed ports, you could also create port exceptions in your Windows Firewall. Please refer to the Windows Firewall documentation for details.
