SQL Server Service Will Not Start: Error 17113, 17058, 1067 and Where the Real Reason Is

The service will not come up. The Services applet says it started and then stopped, Configuration Manager offers nothing useful, and the number on screen is 1067, which means almost nothing. The real reason is in a text file on the server, and it is usually 1 line long. Everything else on this page is about reading that line and acting on it.

Read the Last 20 Lines of the ERRORLOG First

The ERRORLOG is a plain text file and it is written before anything else in startup happens, which is exactly why it is the first thing to read when nothing will start. On Windows it is called ERRORLOG with no extension; MS Docs gives the default locations on Viewing the SQL Server error log, which are <drive>:\Program Files\Microsoft SQL Server\MSSQL.<n>\MSSQL\LOG\ERRORLOG on Windows and /var/opt/mssql/log on Linux. A new log is created every time the instance starts, so ERRORLOG.1 is the attempt before this one.

# Windows. Adjust the version folder and instance name to yours.
Get-Content -Path 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ERRORLOG' -Tail 20

# Watch it live while you retry the service
Get-Content -Path 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ERRORLOG' -Tail 20 -Wait

# Linux
sudo tail -n 20 /var/opt/mssql/log/errorlog

# Watch it live
sudo tail -n 20 -f /var/opt/mssql/log/errorlog

Here is what a healthy start looks like, so you know what you are comparing against. The lines that matter are the startup parameters near the top and the last 2 lines at the bottom:

21:59:52.39 Server   Microsoft SQL Server 2022 (RTM-CU27) (KB5104824) - 16.0.4295.3 (X64)
21:59:52.39 Server   Logging SQL Server messages in file '/var/opt/mssql/log/errorlog'.
21:59:52.39 Server   Registry startup parameters:
                      -d /var/opt/mssql/data/master.mdf
                      -l /var/opt/mssql/data/mastlog.ldf
                      -e /var/opt/mssql/log/errorlog
21:59:59.08 spid28s  Starting up database 'master'.
22:00:02.25 spid37s  SQL Server is now ready for client connections.
22:00:08.80 spid28s  Recovery is complete.

Those 3 parameters are the whole startup contract: -d is the master data file, -l is its log file, and -e is the error log. MS Docs lists them and the rest on Database Engine service startup options, and it is blunt about the consequence: if the Database Engine cannot locate the necessary files, SQL Server does not start. Nearly every failure on this page is 1 of those 3 paths being wrong or unreadable.

Which Error You Actually Have

Match what the tool put on screen, not what you think the problem is. MS Docs keeps the authoritative version of this mapping on SQL Server startup errors, which is worth a bookmark because the Services applet wording differs slightly from the command prompt wording for the same fault.

Error 1067: The Process Terminated Unexpectedly

This is Windows telling you a process it launched died, and nothing more. It is not a SQL Server error number, it has no severity and no state, and it will be identical whatever the real cause was. Chasing 1067 as though it were a diagnosis is the single most common wasted hour on this problem.

It does carry 1 piece of information worth having. MS Docs maps the Services applet wording above directly to Event ID 17058 and SQL Server doesn’t start, whose cause is a bad error log path. So if 1067 is all you have, the error log path is the first thing to check, and the Windows Application log will carry the matching 17058 entry with the path in it. The command prompt is more forthcoming than the applet, so it is worth trying: NET START MSSQLSERVER returns a service specific error number, and that number is the one to search for.

Reading the Windows Application log and the Event Viewer entries is documented here, not reproduced: the reproductions behind this page were run on Linux, which has no Service Control Manager and no Event Viewer, so the 1067 wrapper cannot be produced there at all. The SQL Server errors underneath it are identical on both platforms, and those are reproduced below.

Error 17113: It Cannot Open a File It Needs at Startup

17113 is the useful one, because it names the file and it names the operating system error. The number in brackets is the whole diagnosis: 2 is the file is not there, 3 is the path is not there, 5 is the file is there and the service account cannot read it. MS Docs covers the case on Error 17113 when you start SQL Server service and the reason it is fatal in 1 sentence: SQL Server cannot start if the master database is unavailable.

The reproduction for the box above took a working instance, removed read permission from master.mdf and started it again. The entire log for that attempt was 13 lines, and this is all of it that matters:

21:53:43.93 Server   Microsoft SQL Server 2022 (RTM-CU27) (KB5104824) - 16.0.4295.3 (X64)
21:53:43.95 Server   Logging SQL Server messages in file '/var/opt/mssql/log/errorlog'.
21:53:43.95 Server   Registry startup parameters:
                      -d /var/opt/mssql/data/master.mdf
                      -l /var/opt/mssql/data/mastlog.ldf
                      -e /var/opt/mssql/log/errorlog
21:53:43.96 Server   Error: 17113, Severity: 16, State: 1.
21:53:43.96 Server   Error 5(Access is denied.) occurred while opening file
                     '/var/opt/mssql/data/master.mdf' to obtain configuration information
                     at startup. An invalid startup option might have caused the error.
                     Verify your startup options, and correct or remove them if necessary.

Note what the log gives you for free: the path it tried. Compare that against where the file actually is, and against the -d parameter, and 1 of the 3 will be wrong. On Windows the parameters live in Configuration Manager and in the registry, and MS Docs gives both routes on the 17113 page, including the SQLArg0 value under MSSQLServer\Parameters. On Linux there are no registry parameters: the paths come from mssql.conf, and mssql-conf is the only supported way to change them.

One caution, because it turns a 5 minute fix into a restore. If the file is genuinely missing, do not repoint the master data file at a different directory hoping SQL Server will find it there. In the reproduction behind this page, pointing -d at an empty directory made SQL Server create a brand new master.mdf in it, pair that with the existing log file, and fail with Error: 9003, Severity: 20 and Cannot recover the master database. That is a worse position than the one you started in, and it is covered separately on Cannot Recover the Master Database (Error 3417). Fix the path to point at the real file, or restore master. Do not introduce a third option.

Error 17058: initerrlog Could Not Open the Error Log File

This one has a trap built into it. SQL Server could not open the error log, so the error about the error log cannot be written to the error log. The file you were told to read will sit there holding the previous successful startup, looking perfectly healthy, while the service refuses to come up.

Where to read it instead, in order. On Windows, the Windows Application log carries it as Event ID 17058 with the full path in the description, and MS Docs shows the exact entry and the fix on Event ID 17058 and SQL Server doesn’t start. On Linux, run sqlservr in the foreground from a shell and it prints to the console. Either way you are looking for the quoted path, and then for whichever of these is true of it: the folder has been renamed, the drive is not presented, the disk is full, or the service account cannot write there.

What the reproduction added to the documentation is the behaviour, which is easy to misread as a hang. SQL Server does not fail once and stop. It retried 10 times in under 3 seconds, writing the identical pair of lines each time, and then the process ended. So a console full of the same message is 1 fault, not 10, and a monitoring tool set to restart on failure will produce hundreds of them without ever getting closer.

21:58:19.50 Server   Error: 17058, Severity: 16, State: 1.
21:58:19.50 Server   initerrlog: Could not open error log file
                     '/var/opt/mssql/logro/errorlog'. Operating system error =
                     5(Access is denied.).
21:58:19.80 Server   Error: 17058, Severity: 16, State: 1.
21:58:19.80 Server   initerrlog: Could not open error log file
                     '/var/opt/mssql/logro/errorlog'. Operating system error =
                     5(Access is denied.).

MS Docs’ own example of this error shows operating system error 3, the path not found, where the reproduction produced error 5, access denied. Same error number, same fix location, different half of the problem: 3 means the folder is not where the parameter says, 5 means it is and the account cannot write in it.

A Bad Startup Parameter, and Why the Log Stays Silent

A malformed startup parameter does not produce an error number, does not produce a severity, and does not reach the ERRORLOG at all. It goes to the console and nowhere else. This is the complete output of a start attempt with 1 bad trace flag on the command line:

An invalid startup option 'Tabc' was supplied, either from the registry or the
command prompt. Correct or remove the option.

So the ERRORLOG still held the previous failure, timestamped minutes earlier, and anybody reading it would have diagnosed the wrong fault. Check the timestamp on the last line of the log against the clock every time. If a trace flag was added during the last patch window and the service has not been restarted since, this is the first thing to suspect, and MS Docs is specific about the syntax that bites people: -T takes an uppercase T, no space before the number, and a lowercase t sets internal flags meant for support engineers.

On Windows the parameters live on the Startup Parameters tab in Configuration Manager, and MS Docs walks the dialog on Configure server startup options. Two of its notes are worth carrying: do not put double quotes around a parameter value even when it contains spaces, and when you start the service with net start the options take a slash rather than a hyphen, so it is net start MSSQLSERVER /f and not -f. On Linux the command line is not the place to do this at all. Passing -d directly to sqlservr there was rejected with the same “invalid startup option” message, because mssql.conf owns those paths.

When There Is Nothing in the Log at All

A log whose last entry predates your start attempt is a finding, not a dead end. It narrows the cause to a small set, because it means SQL Server either never ran or died before it opened the log:

• It could not open the log itself. Error 17058, and the message is in the Windows Application log or on the console.
• A startup parameter is malformed. No error number and console output only, so the log is untouched by design.
• The process never launched. A logon failure for the service account, or a missing dependency. Windows raises its own numbers for these, 1069 for the logon failure among them, and MS Docs routes each one from SQL Server startup errors.

In all 3 cases the next place to look is the Windows Application log filtered to the SQL Server source, taking the first error in the sequence rather than the loudest one. That part is documented here, not reproduced, for the same reason as 1067.

The Service Account and the Folder

Every “Access is denied” on this page is the same shape: the paths are right and the account running the service cannot use them. It is the failure mode that arrives without anybody touching SQL Server, because the thing that changed was a folder, a drive or a group policy.

What to check, in the order that finds it. Which account the service actually runs as, which is the first thing Get Services Information returns and is quicker than opening Configuration Manager. Then whether that account has rights on the folder named in the 17113 or 17058 line, rather than on the folder you expect it to be using. MS Docs sets out what the service account needs and how per-service SIDs are granted on Configure Windows service accounts and permissions, and it is the reference to use rather than granting Full Control to Everyone and moving on.

Two specifics that catch people out. Always change the service account with Configuration Manager and not with the Windows Services applet: MS Docs says plainly that other tools “can change the account name but doesn’t change all the required settings”, and names the Windows local security store that protects the service master key as one of the things Configuration Manager updates and they do not. That is how a service that worked yesterday stops starting today with nobody having touched SQL Server. The second is not a SQL Server behaviour at all: copying database files into a new folder in Windows Explorer gives them the new folder’s permissions, not the old folder’s, so a file move is a permissions change whether you intended one or not.

Starting With Minimal Configuration, and When

There is 1 category this page has not covered: the instance starts fine as far as the files are concerned and then dies on a configuration value. An over-committed max server memory is the classic. For that, and only that, -f is the way in. MS Docs describes it on Database Engine service startup options as starting with minimal configuration, and notes the part people forget: it also puts the instance in single user mode, so stop SQL Server Agent first or Agent will take the only connection.

# Minimal configuration. Note the slash, which is what net start expects.
net start MSSQLSERVER /f

# Then connect, fix the setting, and restart without the flag.
sqlcmd -S . -E -C -Q "EXEC sp_configure 'max server memory (MB)', 4096; RECONFIGURE WITH OVERRIDE;"

Documented, not reproduced here: this is a Windows service control path, and the single user mode half of it has its own page. If you are reaching for -m because nobody can get in as sysadmin rather than because the instance will not start, Locked Out of SQL Server: Regain Sysadmin When Nobody Has It is the page you want, and it treats the recovery as something to audit rather than a bypass.

Once it is up, 2 things are worth doing before you close the ticket. Confirm what actually came back and under which account, and find out how long it had really been down, because the start time in the log and the time the alert fired are often hours apart. Check When SQL Server Was Last Restarted answers the second in 1 query.

Frequently Asked Questions