Fix ERROR_INVALID_SERVICE_ACCOUNT 0x00000421

You're Staring at Error 0x00000421

Yeah, I've been there. A service won't start, Event Viewer shows this hex code, and you're wondering why your app just died. Nine times out of ten, the service account's password expired or the account got locked out. Here's the fix.

The Quick Fix: Reset the Service Account Password

Open Services (run services.msc as admin).
Find the failing service. Right-click → Properties.
Go to the Log On tab.
You'll see This account: with a domain\username or local account. That's your culprit.
Type the correct password in both password fields. If you don't know it, reset it in Active Directory or Local Users and Groups first.
Click Apply → OK.
Right-click the service → Start.

That's it. Service starts? Great. You're done. If not, read on.

Why This Works

Windows stores service account credentials — hashed, but they expire. When a domain password changes, the service doesn't automatically update. You get ERROR_INVALID_SERVICE_ACCOUNT. The same happens with local accounts if you set a password expiration policy (which you shouldn't for service accounts). Resetting it forces the service to re-authenticate with the domain controller.

Common scenario: SQL Server Reporting Services fails after a domain-wide password reset policy kicked in. The service account was set to a domain user, password expired overnight, and nobody updated the service config. This fix resolves it in 30 seconds once you know the password.

Less Common Variations

1. Account Is Locked Out

If you reset the password and it still fails, check if the account is locked. Run this on the domain controller:

Get-ADUser -Identity ServiceAccountName -Properties LockedOut | fl LockedOut

If it returns True, unlock it:

Unlock-ADAccount -Identity ServiceAccountName

Then restart the service. Lockouts happen when multiple servers try authenticating with a bad password — typically after the first failure.

2. Account Is Disabled or Expired

Check the account status in ADUC. A disabled account won't authenticate, period. Also verify the account's Account expires setting isn't set to a past date. For service accounts, always set it to Never.

3. Wrong Account Type — Managed Service Account

If you're using a Group Managed Service Account (gMSA), you can't just type a password. The service must be configured to use the gMSA identity. Verify the service is set to NT SERVICE\ServiceName or DOMAIN\gMSAName$. If you see a manual password field, you've got the wrong account type.

To check if gMSA is the issue:

Test-ADServiceAccount -Identity ServiceName

If it fails, re-register the gMSA on that server:

Install-ADServiceAccount -Identity ServiceName

4. Local Service vs. Network Service

If the service is set to Local System, Local Service, or Network Service, error 0x00000421 shouldn't appear — those are built-in accounts. If it does, the service executable might be corrupted. Reinstall the application or run sfc /scannow to check system files.

Prevention: Stop It From Happening Again

Use Managed Service Accounts (MSAs/gMSAs) for services. Windows handles password rotation automatically. You'll never see this error again for those services.
Set service account passwords to never expire if you must use regular domain accounts. In ADUC, check Password never expires. Just be aware this is a security trade-off — you'll need to rotate manually during maintenance windows.
Document service accounts. Keep a spreadsheet or use a tool like Get-Service | Where-Object {$_.StartType -eq 'Automatic'} to list all services with custom logon accounts. Audit them quarterly.
Set up monitoring. Use something like PRTG or Nagios to alert when a service stops unexpectedly. A simple check on service status catches this error within minutes instead of hours.

I've seen this exact error on everything from Windows Server 2012 R2 to Server 2022, and even Windows 10 Pro machines running local services. Don't overthink it. Reset the password. If that fails, check the account lock. Nine out of ten cases are that simple.