Service login and error: 1068: the dependency service or group failed to start but the service has no dependencies

Question

As the title says, I am trying to start a windows service, but it is failing with error 1068. The weird thing about this though is that the service reports it has NO dependencies. I've seen this on multiple different services, one of which we wrote ourselves and we know it has no other dependencies, and one which is a known good service from a third party vendor.

However this only happens when using a specific login for the service. If I use the local system account as the login the services both start without any issue. The account I am using is the one I'm currently logged into, and the user permissions show that my account has permission to start a service.

Unfortunately, the services we are using need to be logged in as specific users to authenticate with third party licensing, so we are kind of stuck with this issue.

Answer 1

Hello Planck, Jeremy,

How is your issue going? To add, the presence of Event ID 3095 confirms that the Service Control Manager (SCM) or the credential subsystem is attempting to invoke the Netlogon service to authenticate the configured logon account. Because the machine operates in a workgroup, Netlogon immediately terminates upon startup, which the SCM subsequently interprets as a fatal dependency failure, resulting in Error 1068. This failure occurs when the SCM attempts a domain-level credential lookup instead of querying the local Security Account Manager (SAM) database. You must force explicit local authentication by modifying the service account format in the Services console to use the exact syntax of .\Username or ComputerName\Username, stripping away any implicit Universal Principal Name (UPN) or legacy domain structures that the OS might be trying to resolve.

Furthermore, you must inspect the raw registry configuration by navigating to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<YourServiceName>. Double-check the DependOnService multi-string value directly within the registry. The Windows Services GUI often masks group dependencies prefixed with a plus sign (like +TDI) or orphaned network provider calls left behind by deployment frameworks. For a truly independent workgroup service, this registry value must be completely empty. Finally, launch secpol.msc and navigate to Local Policies, User Rights Assignment, and ensure your specific local account is explicitly granted the SeServiceLogonRight (Log on as a service) privilege. Relying on local group inheritance for this specific right can fail silently in isolated workgroup environments during the SCM credential broker phase, causing the Netlogon fallback loop you are experiencing.

Hope this answer brought you some useful information. If it has, please consider accepting the answer so that other people sharing the same issue would benefit too. Thank you :)

VP

Answer 2

Hello Planck, Jeremy,

Error 1068 designates a dependency failure, but because your issue strictly correlates with a specific user account context and bypasses Local System, the Service Control Manager is failing to initialize the underlying security and credential subsystems required to build that specific user session. Your description currently lacks the necessary environmental details to pinpoint the exact authentication failure. You need to clarify whether the account in question is a standard local user, an Active Directory domain account, or a Group Managed Service Account. Most importantly, you must inspect the System Event Log via eventvwr.msc immediately after the failed startup attempt. Filter the log for Event ID 7001 originating from the Service Control Manager, as Windows explicitly records the exact name of the failed implicit dependency inside this event payload.

As a best-practice isolation step while you retrieve those logs, you must verify that the Remote Procedure Call (RpcSs) and Secondary Logon (seclogon) services are running, as the operating system requires these to broker non-System credentials during service initialization. If the configured account is a domain identity, the Netlogon, Workstation (LanmanWorkstation), and CNG Key Isolation (KeyIso) services become implicit mandatory dependencies for Kerberos token generation and must also be in a running state. Please provide the exact dependent service named in Event ID 7001 so the broken authentication chain can be definitively repaired.

Hope you found something useful in the answer. If it helped you get more insight into the issue, please consider accepting it. Thank you and have a nice day!

VP

Answer 3

The error 1068, which states "the dependency service or group failed to start," typically indicates that a service cannot start due to a failure in one of its dependencies. However, in your case, since the services report having no dependencies and the issue only occurs when using a specific login, it suggests that the problem may be related to the account permissions or configuration for that user.

Here are a few steps you can take to troubleshoot this issue:

1. Check User Permissions: Ensure that the specific user account has the necessary permissions to start the service. The account may need to be part of the local Administrators group or have specific rights assigned.
2. Service Logon Configuration: Verify that the service's logon information is correctly configured. You can do this by accessing the service properties in the Services management console and checking the "Log On" tab. Ensure that the password for the account is correct and that it has not expired.
3. Event Viewer Logs: Check the Windows Event Viewer for any additional error messages that might provide more context about why the service is failing to start. Look specifically under the System and Application logs for any related errors.
4. Dependency Services: Even if the service itself has no dependencies, it might rely on other system services that could be failing. Check the status of related services that might not be explicitly listed as dependencies.
5. Group Policy Settings: If the machine is part of a domain, group policy settings might be affecting the service's ability to start under a specific user account. Review any relevant policies that could restrict service logon.
6. Testing with Other Accounts: If possible, test the service with other user accounts to determine if the issue is isolated to one specific account or if it affects multiple accounts.

By following these steps, you should be able to identify the root cause of the issue and resolve the error 1068 when using the specific login for the service.

---

References:

• The SQL Server service and the SQL Server Agent service fail to start on a standalone server
• Troubleshoot Netlogon service startup failures