SQL Server starts and stops after a few seconds: using ERRORLOG, service accounts, master and tempdb

When SQL Server stops during start-up, read ERRORLOG and Windows events first, then check the service account, start-up parameters, system databases, storage and patching.

1. Conclusion and scope

Service Control Manager reports only that start-up failed; the actual cause is normally in SQL Server ERRORLOG. Do not repeatedly start or reinstall the instance and overwrite evidence. Locate the log and first fatal error, then determine whether the cause is permissions, paths, system databases, ports, resources or updates.

This issue involves SQL Server, ERP, database recovery or version migration. Preserve a verified backup before any high-risk action.

2. Risk signals that deserve priority

• The service reports that it started and then stopped, with events such as 17058, 17113, 17204 or 945.
• The failure began after a service-account, drive-letter, database-path, antivirus or patch change.

3. Pre-change assessment checklist

1. Use SQL Server Configuration Manager to confirm instance, service account and start-up parameters.
2. Read the current ERRORLOG and Application log and find the first fatal error rather than the final stop message.
3. Check master, model, msdb and tempdb paths, directory permissions, free space and file integrity.
4. Check port conflicts, certificates, TLS, service-account password and Log on as a service rights.

sc query MSSQLSERVER
Get-WinEvent -FilterHashtable @{LogName="Application"; ProviderName="MSSQLSERVER"} -MaxEvents 30
netstat -ano | findstr :1433

4. Recommended implementation sequence

1. Correct the identified path or permission and change only one condition before each restart.
2. If the tempdb path is invalid, restore it to a usable location; handle damaged system databases through backup or controlled rebuild procedures.
3. Change service accounts through Configuration Manager rather than editing services.msc without SQL permissions handling.
4. Preserve ERRORLOG, events and change records, and copy database files before high-risk recovery.

5. Validation, rollback and common mistakes

• The service remains stable through repeated restart tests.
• All databases are online and SQL Agent, backup, application connections and listeners work.
• Logs contain no persistent I/O, permission, recovery or assertion errors.

Common mistakes

• Deleting master or transaction-log files.
• Assuming free disk space rules out every storage problem.
• Reinstalling SQL Server repeatedly without analysing the fatal error.

Frequently asked questions

Does start-and-stop always mean database corruption?

No. Accounts, permissions, paths, ports, certificates and updates can all cause start-up failure.

Can tempdb files simply be deleted?

Confirm the configured path and recovery plan first; do not delete files blindly in an unknown state.