Fix STATUS_NETLOGON_NOT_STARTED 0xC0000192

You rebooted a domain controller (or a member server that caches domain creds) and now nobody can log in. Local accounts work, but anything backed by AD throws 0xC0000192. Or it happens right after you ran a hardening script, applied a CIS benchmark GPO, or tweaked services on a VM template. The screen says: An attempt was made to logon, but the NetLogon service was not started. Everything else looks fine — DNS is answering, the NIC is up, no purple screens. That's because the real problem is one service, and it's sitting there in a stopped state while the rest of the machine pretends nothing's wrong.

What's actually happening

NetLogon does two jobs. On a domain controller it registers SRV records, handles the secure channel between the DC and other DCs, and processes authentication traffic. On a member server or workstation it maintains the secure channel to a DC so cached domain credentials work and machine account password changes succeed.

When NetLogon isn't running, every call that needs that secure channel fails fast. The LSA can't complete the logon, and Windows surfaces STATUS_NETLOGON_NOT_STARTED. The service itself is either:

Set to Disabled in the registry or Services MMC — usually from a template or a hardening baseline.
Crashing on start because a dependency (Workstation, RPC, TCP/IP) isn't running or is failing.
Failing to start due to a corrupted secure channel password or a missing machine account on the DC.

The hardening-script scenario is the most common one I see. Some CIS and STIG baselines mark NetLogon as "Disabled" in their Level 2 profile because the author assumed standalone servers. On a domain-joined box that's an instant outage the next time the machine reboots.

The fix

1. Confirm the service state

Open an elevated PowerShell or Command Prompt and run:

sc query netlogon
get-service netlogon | format-list name, status, starttype

If Status is STOPPED or StartType is Disabled, you've found the culprit.

2. Check the dependencies are running

NetLogon needs RPC and Workstation. If either is down, starting NetLogon will fail with a dependency error.

sc query rpcss
sc query lanmanworkstation

Start anything that's stopped before moving on.

3. Set NetLogon back to Automatic

From an elevated prompt:

sc config netlogon start= auto

Mind the space after the equals sign — it's required. In the Services MMC you'd set Startup type to Automatic instead. Do not use Automatic (Delayed Start). On a DC that can cause SRV record registration to miss the boot window and break clients that already have cached DNS.

4. Start the service

net start netlogon

If it starts clean, try logging in with a domain account. You should be back in business.

5. If it refuses to start, check the registry value directly

Sometimes the Services MMC shows Automatic but the underlying registry value is still 4 (Disabled) because a GPO or policy is overwriting the UI.

reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon /v Start

Valid values: 2 = Automatic, 3 = Manual, 4 = Disabled. If it reads 4, set it with:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Netlogon /v Start /t REG_DWORD /d 2 /f

6. On a domain controller, verify SRV records

Once NetLogon is running on a DC, force it to re-register its service records so clients can find it:

nltest /dsregdns
dcdiag /test:dns /v /e

If SRV records are missing from DNS, clients will still fail to authenticate even with NetLogon healthy.

If it still fails

Work through these in order — they cover 95% of what's left:

Check the System event log. NetLogon startup failures log Event ID 5719 ("This computer was not able to set up a secure session with a domain controller") and usually a companion 5723. The text points at the actual blocker.
Test the secure channel. Run nltest /sc_query:YOURDOMAIN. If it returns access denied or a trust failure, the machine account password is out of sync. Reset it with Test-ComputerSecureChannel -Repair -Credential (Get-Credential) from PowerShell, or netdom resetpwd on older builds.
Rejoin the domain if the secure channel repair fails on a member server. Unjoin, reboot, rejoin. It sounds heavy-handed but it's faster than chasing a corrupted machine account.
Audit your GPOs. Run gpresult /h gpo.html and look for anything touching the Netlogon service. CIS Level 2 and some DoD STIG profiles disable it. Exclude domain controllers and member servers from that particular setting.
Check for a corrupted service binary. Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth. It's rare, but a bad patch cycle can leave the Netlogon DLLs in a broken state.
On a DC, check the time. Kerberos is unforgiving about clock skew. If the PDC emulator is more than 5 minutes off from a reliable NTP source, NetLogon will refuse to establish secure channels. w32tm /query /status and fix the source.

Quick reality check: if you're fixing this on a VM template, fix the template too. I've watched admins fix a single server, then watch a dozen new deployments inherit the same broken service config three weeks later.

Once NetLogon is back to Automatic and running, reboot the box and confirm it survives a restart. If it does, you're done. If it doesn't, something is actively changing the Start value at boot — and that's almost always a GPO or a configuration management tool like SCCM, Intune, or Ansible.