Fix ERROR_TRUST_FAILURE (0x000006FE) network logon

The 30-second check: test basic connectivity

Most of the time, 0x000006FE shows up because the machine lost contact with the domain controller. Not a deep trust failure yet — just a network hiccup. Here's what to do first.

1. Press Windows + R, type cmd, and hit Enter.
2. In the black window, type ping yourdomaincontroller — replace with your actual DC name or IP. Hit Enter.
3. If you get replies, your network is fine. Move to the next step.
4. If you get Request timed out or Destination host unreachable, check your network cable or Wi-Fi. Also check that the DC is turned on and reachable. A quick ipconfig /flushdns and ipconfig /registerdns can help.

After that, try logging off and back on. You should see the login screen again. If it still fails with the same error, move to the moderate fix.

The moderate fix (5 minutes): reset the secure channel

This is the real fix for 9 out of 10 trust failures. The machine's password in Active Directory got out of sync with what Windows has stored locally. 0x000006FE means the domain controller won't accept the machine's credentials.

Step 1: Open PowerShell as admin

1. Right-click the Start button (or press Windows + X).
2. Choose Windows PowerShell (Admin) or Terminal (Admin).
3. Click Yes on the UAC prompt.

Step 2: Check the current trust status

Type this command and hit Enter:

Test-ComputerSecureChannel -Verbose

You'll see output like True (channel is good) or False (broken). If it's False, you'll also see the error we're chasing. If it's True, then restart the machine and try logging in again — sometimes a fresh boot clears a transient glitch.

Step 3: Reset the secure channel

Run this command:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

A popup will ask for domain admin credentials. Enter a username like DOMAIN\AdminUser and the password. This forces Windows to renegotiate the machine password with the domain controller.

After it finishes, you'll see either True (success) or False (failure). If it fails, the advanced fix is your next stop.

Step 4: Verify and restart

Run Test-ComputerSecureChannel -Verbose again. You should see True. Restart the machine. Log in with a domain account. The error should be gone.

The advanced fix (15+ minutes): leave and rejoin the domain

If the moderate fix didn't work, the trust failure is deeper. Maybe the computer object was deleted from AD, or the machine got moved to a different OU, or the machine password hash got corrupted beyond repair. You'll need to break the trust manually and rebuild it.

What you need

• Local admin credentials (or the password for a built-in local account like .\Administrator).
• Domain admin credentials.
• The exact domain name (like contoso.com).

Step 1: Log in with a local account

On the login screen, type .\Administrator (or another local admin username) and its password. If you don't have a local admin account, use the password reset disk or boot into safe mode with networking to enable the built-in Administrator account.

Step 2: Remove the machine from the domain

1. Press Windows + I to open Settings.
2. Go to Accounts > Access work or school.
3. Click the domain connection that shows your domain name. Then click Disconnect.
4. When asked for credentials, use local admin (not domain). Confirm you want to disconnect.
5. Restart the machine when prompted.

Alternatively, you can do it via System Properties:

1. Press Windows + R, type sysdm.cpl, hit Enter.
2. Click the Computer Name tab.
3. Click Change.
4. Under Member of, select Workgroup. Enter any name, like WORKGROUP.
5. Click OK. You'll be prompted to reboot. Do it.

Step 3: Rejoin the domain

1. Boot up and log in with the local admin account again.
2. Open sysdm.cpl again.
3. Under Computer Name, click Change.
4. Select Domain and type your domain name (e.g., contoso.com).
5. Click OK. Enter a domain admin username and password when prompted.
6. You'll get a welcome message. Restart.

Step 4: Log in and verify

After restart, log in with a domain account. Run Test-ComputerSecureChannel -Verbose — it should show True. The trust failure is gone.

One more thing: check for DNS issues

I've seen 0x000006FE appear when the client's DNS points to a wrong server. Make sure your network adapter's DNS is set to the domain controller (or the company DNS server). Don't use a public DNS like 8.8.8.8 — that breaks domain discovery. Check with ipconfig /all.

Pro tip: If you're in a hurry and have another working domain-joined machine, you can use netdom reset pdc-ok /d:domainname /ud:domain\admin /pd:* from that machine to reset the trust remotely. But that's a whole other article.