Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix 1069

Service Error 1069 and 17058: The SQL Server Account Cannot Start the Instance

11 min read Updated October 4, 2026 SQL Server

Fix it now

Two programs are complaining about identity. Error 1069 is Windows refusing to log the service account on, so the engine never ran; error 17058 is SQL Server starting and finding it cannot open its error log. The System event log entry tells you which of the two problems you have, and it decides the fix.

Run on the SQL Server, in an elevated Command Prompt

runas /user:DOMAIN\SQLSvc cmd
sc qmanagedaccount MSSQLSERVER
  1. Open Event Viewer and read the System log. Event 7038 reports the account problem itself: disabled, password must be changed, wrong user name or password, locked out, or the domain could not be contacted. Event 7041 is the narrower case, “the user has not been granted the requested logon type at this computer”.
  2. For 7041, grant the account the right it lacks in secpol.msc, under Local Policies then User Rights Assignment, and remove any matching Deny entry, which wins over the grant.
  3. For 7038, fix the account in Active Directory Users and Computers or Computer Management as the event describes, then re-enter the credentials on the Log On tab of the instance’s properties in SQL Server Configuration Manager. Use Configuration Manager, not services.msc.
  4. For 17058, check the folder named by the -e startup parameter: it must exist, have free space, and let the service identity write. Rename a locked ERRORLOG file and let the service create a fresh one.

The runas test above proves whether the credentials themselves are good. If it opens a command prompt, the password is right and the problem is a right, a lock or the log folder.

If both services start and stay started, you are done. If the service starts and exits a second later, the next section covers what the engine is failing on.

Why it happens

The Service Control Manager authenticates the service account before the executable runs. Error 1069 is Windows system error ERROR_SERVICE_LOGON_FAILED, published as “The service did not start due to a logon failure”, and it is a verdict on the credentials rather than on SQL Server. Error 1067 is ERROR_PROCESS_ABORTED, published as “The process terminated unexpectedly”, which means the engine did start and then gave up.

The two System log events behind 1069 are not interchangeable, and the difference is the whole fork. Event 7038 carries the account problem: the account is disabled, its password must be changed before signing in, the user name or password is incorrect, the account is locked out, or the specified domain does not exist or could not be contacted. Event 7041 carries one specific thing, “Logon failure: the user has not been granted the requested logon type at this computer”, which is the same wording as Windows error 1385, ERROR_LOGON_TYPE_NOT_GRANTED. One tells you to fix a password or an account; the other tells you to grant a right.

Error 17058 is different in kind because the process did start. Its published text is “initerrlog: Could not open error log file”, followed by the operating system error. The engine’s first act is to open its error log, and if that fails it has nowhere to report anything, so it exits and Windows reports 1067. Error 17053 is the engine’s general operating system complaint, published as “Operating system error encountered”, with the Windows number attached.

Modern installations grant file permissions to a per-service identity rather than to the account directly: NT SERVICE\MSSQLSERVER for a default instance, NT SERVICE\MSSQL$INSTANCENAME for a named one, and NT SERVICE\SQLSERVERAGENT or NT SERVICE\SQLAGENT$INSTANCENAME for Agent. This matters for what re-entering the account can and cannot fix, and it is where most of the wasted time on this error goes.

The password changed, expired, or the account is locked or disabled

You have this one if The service ran for months and failed overnight or after a rotation. Event 7038 names the account and the specific condition.

  1. Test the credentials with runas /user:DOMAIN\SQLSvc cmd. If that fails, reset the password in Active Directory Users and Computers or Computer Management first.
  2. Clear “User must change password at next logon”, unlock the account, or enable it, according to what the 7038 event says.
  3. Re-enter the credentials on the Log On tab in SQL Server Configuration Manager, and do the same for SQL Server Agent and anything else using that account.

Credentials and proxies inside SQL Server hold their own stored passwords. If the same account is used there, update them too or Agent job steps will fail after the service starts.

The account does not hold the logon right

You have this one if Event 7041, or Windows error 1385, and the password has already been proved correct.

  1. Grant the right in secpol.msc under Local Policies, User Rights Assignment.
  2. Remove the account from any matching Deny entry, since a deny beats a grant.
  3. If the right disappears again later, a Group Policy is overwriting the local setting; add the account to that policy instead of fixing the server by hand.

No domain controller could be reached

You have this one if Event 7038 reporting that the specified domain does not exist or could not be contacted, usually at boot or during a recovery exercise.

  1. Set the SQL Server service to Automatic (Delayed Start), which lets it launch after services such as Netlogon are up. This is the default on SQL Server 2022 and later.
  2. Add the dependency explicitly where the ordering still bites: sc config MSSQL$INSTANCE depend=keyiso/netlogon.
  3. In a disaster recovery boot, bring a domain controller up before the database servers.

A group managed service account has lost its managed flag

You have this one if The service uses a gMSA, the account is healthy in Active Directory, and the service still fails to log on.

  1. Confirm the account in PowerShell with Get-ADServiceAccount -Identity 'gmsaName' -Properties PasswordLastSet.
  2. Read the flag with sc qmanagedaccount MSSQL$INSTANCE.
  3. If it reports false, set it with sc managedaccount MSSQL$INSTANCE TRUE and start the service.

The error log cannot be written

You have this one if Error 17058, or a service that starts and stops within a second while the ERRORLOG file keeps an old timestamp.

  1. Check the -e startup parameter and confirm the folder exists and has free space.
  2. Grant the per-service identity modify rights on that folder. If the LOG folder was moved, this will not have been done for you.
  3. Exclude the SQL Server data, log and backup folders from on-access antivirus scanning, then rename a locked ERRORLOG and start the service.

Full reference

What re-entering the account in Configuration Manager does, and does not, do

Microsoft is explicit that you should always use SQL Server tools such as Configuration Manager to change the account or its password, because Configuration Manager also updates the Windows local security store that protects the service master key, and the Services console does not. That much is worth doing every time.

What it will not do is repair permissions on folders SQL Server does not own. Setup configures the ACL for the per-service account at its own locations. Microsoft’s rule for anywhere else is direct: when database files are stored in a user-defined location, you must grant the per-service SID access to that location. For a network share it is stronger still, because Setup cannot provision access to a share at all, so the account has to be given access before the database is created.

If someone has moved the data, log or backup folders to another volume or onto a share, re-entering the service account will not put the permissions back. Grant NT SERVICE\MSSQLSERVER, or NT SERVICE\MSSQL$INSTANCENAME for a named instance, modify rights on the moved folder by hand. Looping on Configuration Manager is the most common way to spend an afternoon on this error.

Per-service identities worth knowing

Service Per-service SID
Database Engine, default instance NT SERVICE\MSSQLSERVER
Database Engine, named instance NT SERVICE\MSSQL$INSTANCENAME
SQL Server Agent, default instance NT SERVICE\SQLSERVERAGENT
SQL Server Agent, named instance NT SERVICE\SQLAGENT$INSTANCENAME

Reading the operating system error on a 17053 or 17058 line

Operating system error What it means in this context
3 The path does not exist, usually a -e or -d parameter pointing at a folder that moved
5 Access denied: the per-service identity has no rights on the folder or file
32 The file is open in another process, typically antivirus or a backup agent
112 The volume is full, so the log file cannot be written or extended

Commands that answer a specific question

Command What it settles
runas /user:DOMAIN\account cmd Whether the credentials themselves are valid on this machine
sc qmanagedaccount <service> Whether Windows still treats a gMSA as managed
sc managedaccount <service> TRUE Sets that flag back
sc config <service> depend=keyiso/netlogon Makes the service wait for Netlogon at boot
secpol.msc Grants or removes user rights, including any Deny that is winning

When the service starts and then stops

  • Read the SQL Server error log if it exists, and the Application log in Event Viewer if it does not. A service that starts and exits is the engine deciding it cannot continue, and it almost always says why in one of those two places.
  • Windows will report 1067 for that case, which carries no diagnosis of its own.
  • Check every path in the startup parameters, including on the second node after a failover or a rebuild.
  • If the engine cannot open its error log at all, you are looking at 17058 and the answer is the LOG folder rather than anything inside SQL Server.

Every code this article covers

Code What it points at Source
1069 Windows error ERROR_SERVICE_LOGON_FAILED: the service did not start due to a logon failure Microsoft Learn
1067 Windows error ERROR_PROCESS_ABORTED: the process terminated unexpectedly, so the engine started and then gave up Microsoft Learn
17058 initerrlog: could not open the error log file, with the operating system error attached Microsoft Learn
17053 An operating system error was encountered, with the Windows number attached Microsoft Learn
1385 Windows error ERROR_LOGON_TYPE_NOT_GRANTED: the user has not been granted the requested logon type at this computer Microsoft Learn
Event ID 7038 Service Control Manager reporting the account problem: disabled, password must be changed, wrong user name or password, locked out, or the domain could not be contacted Microsoft Learn
Event ID 7041 Service Control Manager reporting that the account has not been granted the requested logon type at this computer Microsoft Learn

Confirm the fix worked

  1. Both SQL Server and SQL Server Agent are running and set to start automatically.
  2. The current ERRORLOG carries a fresh timestamp for this start.
  3. A normal login connects and runs a query.
  4. Any folder that was moved grants the per-service SID modify rights, checked directly rather than assumed.
  5. Restart the machine once and confirm both services come up without intervention.

Questions people ask about this

Why Configuration Manager rather than services.msc?

Because Microsoft documents Configuration Manager as doing more than storing a password: it also updates the Windows local security store that protects the service master key. The Services console changes the account name and password and leaves the rest alone.

I re-entered the account and the permissions still are not right. Why?

Because Setup configures the ACL for the per-service account at its own locations. Microsoft’s documented rule is that when database files are stored in a user-defined location you must grant the per-service SID access to that location yourself, and that Setup cannot provision access to a network share at all.

Does this mean my licence or key has a problem?

No. This is a Windows identity and file permission problem and it costs nothing to resolve. SQL Server does not check a key when the service starts.

Can I run the service as Local System to get going quickly?

It will usually start, and it gives the engine far more rights on the machine than it needs while breaking anything that depends on the domain identity, such as network backups or linked servers using Windows authentication. Treat it as a diagnostic step, not a destination.

The System log shows 7038 and I was told it means the same as 7041. Does it?

No. Event 7041 is specifically the account not holding the required logon right, which is Windows error 1385. Event 7038 reports the account condition instead: disabled, password expiring, wrong credentials, locked out, or an unreachable domain. Which one you get decides whether you reset a password or grant a right.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error SSIS Error 0xC0047062: Packages Fail as Agent Jobs but Run in Visual Studio Free Fix Error 605: Page Belongs to the Wrong Allocation Unit – Corruption or Dirty Read Free Fix Error 10054: Existing Connection Forcibly Closed During a Running Query Free Fix Error 9002: The Transaction Log Is Full – Find the log_reuse_wait Reason
← Back to Knowledge Base