Fix ERROR_SERVICE_LOGON_FAILED (0X0000042D) – Step by Step
A service won't start because the password or account it runs under is wrong. Here's how to fix it fast, from a 30-second check to a full rebuild.
What triggers this error
You see this error when a Windows service tries to start but the account it's configured to run under — usually a domain user — has a bad password, an expired password, or the account is locked out or denied logon as a service. I've seen it most often on Windows Server 2019 and 2022 after a domain password policy change or when an admin rotates a service account password but forgets to update every service using it.
The error code 0X0000042D is the same as ERROR_SERVICE_LOGON_FAILED. It shows up in the System event log with source Service Control Manager and event ID 7000 or 7034. The message says something like: “The [Service Name] service failed to start due to the following error: The service did not start due to a logon failure.”
Here are three ways to fix it. Start with the first one — it takes 30 seconds. If that doesn't work, move to the next.
Quick fix (30 seconds) – Check and update the service password manually
This is the fix I try first. Most of the time, the password is just out of sync.
- Press Windows Key + R, type
services.msc, and press Enter. The Services window opens. - Find the service that's failing. You can look in the Application event log or System event log for the exact service name. Sort by Status to see Stopped services first.
- Right-click the service and choose Properties.
- Go to the Log On tab. Under “This account,” you'll see the account name — something like
DOMAIN\ServiceAccount. - In the two password fields — Password and Confirm password — type the current, correct password for that account.
- Click Apply. You should see no error message. If you get an “Access Denied” or “Logon failure” message, skip to the moderate fix — the password is still wrong or the account lacks the “Log on as a service” right.
- Click OK to close the window.
- Right-click the service again and choose Start. If it starts without error, you're done. If not, move to the next fix.
One thing to watch: If the service account's password expired yesterday, typing the old password won't help. Make sure you have the new password from whoever manages that account.
Moderate fix (5 minutes) – Use sc config to reset the password from command line
This is my go-to when the GUI method doesn't work — maybe because the service is protected or the password field in Services.msc is greyed out. It also saves time if you have multiple services using the same account.
- Open Command Prompt as Administrator. Click Start, type
cmd, right-click Command Prompt, and choose Run as administrator. - Type this command, replacing the placeholders:
For example:sc config "ServiceName" password= "NewPassword"
Important: There's a space aftersc config "MSSQL$SQLEXPRESS" password= "MyNewP@ssw0rd"password=before the opening quote. That's not a typo —screquires it. - Press Enter. You should see
[SC] ChangeServiceConfig SUCCESS. If you get Access Denied, run the command prompt elevated. If you get a different error, check that the service name is exactly right — usesc queryto list all services and their names. - Now start the service:
sc start "ServiceName" - If it starts, you're good. If it still fails, run
net helpmsg 42Dat the command prompt. That will show “The service did not start due to a logon failure.” — confirming the problem is still account-related.
If sc config succeeds but the service still won't start, the account might be locked out or denied logon as a service. Jump to the advanced fix.
Advanced fix (15+ minutes) – Reset the account rights and check domain policy
This is for the stubborn cases — password is correct, account isn't expired, but the service still won't start. Usually it's a permissions or group policy issue.
Step 1: Verify the account isn't locked out or disabled
Open Active Directory Users and Computers on a domain controller. Find the service account. Right-click it and choose Properties. On the Account tab, make sure:
- Account is locked out is unchecked.
- Account is disabled is unchecked.
- Password never expires is checked (only if your policy allows it — otherwise set a reminder to rotate the password).
- User cannot change password is checked (it's a service account, not a human).
If you find the account locked out, unlock it. Then try starting the service again. If it locks out again, you have a service or script hitting it with the wrong password repeatedly — track down that source.
Step 2: Grant “Log on as a service” right
Even if the account has this right, group policy can strip it. Here's how to check and fix it — this is the part most guides skip, but it's often the real fix.
- On the server where the service runs, open Local Security Policy. Press Windows Key + R, type
secpol.msc, and press Enter. - Go to Security Settings > Local Policies > User Rights Assignment.
- Find Log on as a service in the right pane. Double-click it.
- If your service account isn't listed, click Add User or Group, type the account name (like
DOMAIN\ServiceAccount), click Check Names, then OK. - Click Apply and OK.
- Close the Local Security Policy window. No reboot needed, but you can force a policy update with
gpupdate /forceif you want.
Step 3: Reapply the service account configuration
Now go back to Services.msc and repeat the Quick fix steps. Set the password again. Start the service. If it still fails, there's a good chance the service has a corrupt token or the account SID was removed. In that case, the nuclear option is to change the service to run as Local System, start it, then switch back to the domain account. But that's rare. I'd say 9 out of 10 times, the password reset or the “Log on as a service” right resolves it.
If none of this works, check the System event log for event ID 4625 (logon failure). The details will tell you whether it's a bad password, a disabled account, or a locked-out account. That's the fastest way to pinpoint the exact reason.
Was this solution helpful?