OneDrive and Office Sign-in Error 0x8004DE40: Login Was Interrupted or Unsuccessful

Fix it now

Microsoft’s published cause for 0x8004DE40 and 0x8004DE88 is that the client is having trouble connecting to the cloud. The documented fixes are about TLS – which protocol versions and cipher suites the machine will negotiate – and then about device registration, not about the account.

Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" -Position 0
dsregcmd /leave
dsregcmd /join

1. Confirm the device is actually on the internet, which is the first check Microsoft lists.
2. Confirm the machine supports and prioritises the TLS 1.2 cipher suites the service expects. The four Microsoft names are TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
3. Check the TLS protocol checkboxes: run inetcpl.cpl, open the Advanced tab, and confirm the TLS options are enabled.
4. If the device is joined to Entra ID, leave and rejoin with the two dsregcmd commands above, then restart the computer.
5. If none of that helps, reset the OneDrive client and let it re-synchronise.

The message users see for 0x8004DE40 is “Login was either interrupted or unsuccessful. Please try logging in again.” For 0x8004DE88 it is “We can’t sign into your account, please try again later.” Both point at the same cause.

If the client signs in and stays signed in after a reboot, you are done. The next section explains what has to line up for a token exchange to complete.

Why it happens

A modern sign-in is a token exchange, not a password check. The client sends the user to the identity service, receives tokens back, caches them, and refreshes them silently from then on. Several separate things have to work: name resolution and a clear path to the identity endpoints, a TLS connection both ends can agree on, a clock inside the accepted window, a writable place to keep the token cache, and an account that is enabled and licensed.

Microsoft’s published cause for 0x8004DE40 and 0x8004DE88 is the second of those. The article says the codes indicate the client is having trouble connecting to the cloud, and its resolutions are almost entirely about TLS: whether the machine supports the cipher suites the service front door expects, and whether the TLS protocol versions are enabled at all. That is why hardened machines and old builds fail here while everything else on them looks fine.

The failure is easy to misread because it presents as a sign-in problem, so people look at the account. A machine that cannot negotiate a current TLS version fails here rather than anywhere obviously TLS-shaped, and a long time gets spent checking licences before anyone checks a protocol setting.

The other four codes in this family have no published meaning. Microsoft has dedicated articles for 0x8004de40, 0x8004de88, 0x8004de80, 0x8004de86 and 0x8004deef, and none for 0x8004DEF0, 0x8004DEB4, 0x8004DEED or 0x8004DEF7. Treat any of them as sign-in did not complete, and work the same list in the same order.

Full reference

Splitting client problems from account problems

The cipher suites Microsoft names

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

These have to be supported and prioritised on the client. Enable-TlsCipherSuite -Name "<suite>" -Position 0 puts one at the top of the list; run it for each suite you need to promote, and check the result before rebooting. On older platforms Microsoft’s guidance also covers adding the TLS 1.1 and 1.2 registry keys and, where connectivity errors persist, disabling DHE cipher suites.

Which codes are documented

Resetting the client

A reset stops the OneDrive client, clears its local configuration and starts it again, after which it re-synchronises. Files in the cloud are untouched and files already on disk are not deleted; the client re-checks them, which takes a while on a large synced folder. Do it after the TLS and device checks rather than before, because a reset that appears to work can mask a protocol problem that returns a week later.

When everything on this list is clean

• Check the clock. Token validation is time-sensitive and a large offset produces sign-in failures with no obvious clock symptom.
• Check the service health page in the admin centre before spending longer on one machine.
• Compare against a second machine on the same network with the same account. Two machines behaving differently is a machine problem; two behaving identically is a network or account problem.
• Check whether an endpoint security product is intercepting HTTPS on this machine, because inspection produces exactly this class of failure and hides the real certificate.
• For a machine that has been off the network for a long time, apply updates before anything else. Protocol support and root certificates both age.

Every code this article covers

Confirm the fix worked

1. The application signs in without prompting after a restart.
2. OneDrive shows the correct account and a completed sync in its activity centre.
3. File, Account in Word shows the expected account and product.
4. A second reboot leaves sign-in silent rather than prompting again.
5. The cipher suite change is still in place after a policy refresh, not reverted by a hardening baseline.

Questions people ask about this