Ice Docs

Troubleshooting Windows Services

7 min read

7 min read

7 min read

7 min read

7 min read

7 min read

7 min read

7 min read

7 min read

This page describes how to troubleshoot Windows Services.

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.

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.

Assuming that DLL issues are resolved, a Windows service can fail to start for a number of other reasons, including

  • invalid command-line arguments or configuration properties
  • inability to access necessary resources such as file systems and databases, because either the resources do not exist or the service does not have sufficient access rights to them
  • networking issues, such as attempting to open a port that is already in use, or DNS lookup failures

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:

The IceBridge service terminated with service-specific error 1.

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 Service Logging Considerations 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. You should also review the access rights of files and directories required by the service.

Windows Firewall blocks inbound connections by default, so a service that accepts connections needs an inbound rule that allows them. Create this rule when you install the service; iceserviceinstall does not create it. For example, this New-NetFirewallRule command, in an elevated PowerShell session, allows connections to a Glacier2 router on TCP port 4063:

PowerShell
New-NetFirewallRule -DisplayName "Glacier2 router" -Direction Inbound -Action Allow `
    -Program "C:\Program Files\ZeroC\Ice-Services-3.8.3\bin\glacier2router.exe" `
    -Protocol TCP -LocalPort 4063

A block rule takes precedence over an allow rule. If the service remains unreachable, look in the Inbound Rules of the Windows Firewall with Advanced Security console (wf.msc) for block rules on the service executable, and delete them. See Windows Firewall rules for the rule types and their precedence.

The IceGrid node uses Windows' Perflib facility to obtain statistics about the CPU utilization of its host for load balancing purposes. Occasionally, the IceGrid node may log the following warning message when it starts:

warning: Unable to lookup the performance counter name:
<error description>
This usually occurs when you do not have sufficient privileges

The second line is the description Windows provides for the error. One cause is that the node's user account cannot read the following key in the Windows registry:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib

After logging this warning, the node reports a load average of 0 until you restart it.

As part of its installation procedure, the iceserviceinstall utility modifies the permissions of this registry key to grant read access to the node's designated user account. If you are trying to change the node's user account, we recommend using the iceserviceinstall utility to uninstall and reinstall the node. If you wish to modify the permissions of this registry key manually, follow these steps:

  1. Start regedit and navigate to the Perflib key.
  2. Right click on Perflib and select Permissions.
  3. If the desired user account is not already present, click Add to add the user account. Enter LOCAL SERVICE if you wish to run the node in the Local Service account, otherwise enter the name of the user account. Press OK.
  4. Check the Read box in the Allow column to grant read access to the registry key and press OK to apply the changes.

Another way to grant the node's user account with the necessary access rights is to add it to the Performance Monitor Users group.

After you correct the access rights, restart the IceGrid node and check that it no longer logs this warning. The icegridadmin command node load NAME prints the load averages the node reports.