Fix OneDrive Error 0x8004de40 for Work or School Accounts

OneDrive error 0x8004de40 usually appears when a user tries to sign in to the OneDrive sync app and gets this message:

OneDrive Can't sign in. Error 0x8004de40
Login was either interrupted or unsuccessful. Please try logging in again. (Error Code: 0x8004de40)

Microsoft also documents 0x8004de88 in the same sign-in failure family. Treat this as a connectivity and authentication path problem first, not as a request to rebuild the user’s Windows profile. In enterprise environments the root cause is often TLS/cipher configuration, SSL inspection, a proxy allowlist gap, broken OneDrive client state, or Conditional Access blocking the sign-in after the OneDrive client hands off to Entra ID.

Use this runbook when multiple users suddenly cannot sign in to OneDrive, when a new network security rule was deployed, or when one managed Windows build fails while unmanaged devices can sign in.

Quick Fix checklist

Start with one affected device and one unaffected device on the same network, if possible.

1. Confirm the exact error code is 0x8004de40 or 0x8004de88 in the OneDrive sign-in window.
2. Check whether the failure follows the user, the device, or the network.
3. Test sign-in from https://www.office.com and the user’s SharePoint/OneDrive web URL.
4. Confirm the device can reach Microsoft 365 and SharePoint Online endpoints without TLS break-and-inspect on the Optimize/Allow traffic path.
5. Verify TLS 1.2 and supported cipher suites on the Windows device.
6. Check the proxy/PAC file, VPN tunnel, secure web gateway, and firewall logs for blocked OneDrive, SharePoint, or Microsoft authentication URLs.
7. Review Entra sign-in logs for the affected user at the same timestamp.
8. Reset the OneDrive sync app only after the network and sign-in path are proven healthy.
9. Update the OneDrive sync client if the device is on an old build.
10. Document the endpoint, proxy, and TLS changes so the error does not return during the next security policy rollout.

Root Cause

0x8004de40 means OneDrive is having trouble connecting to the cloud during sign-in. The OneDrive client is not just opening a storage connection. It needs a working chain across Windows networking, TLS, Microsoft authentication, SharePoint Online, OneDrive service endpoints, and sometimes tenant-specific Conditional Access requirements.

The most common enterprise causes are:

• TLS 1.2 or cipher suite settings are missing, weakened, or overridden by Group Policy.
• A proxy or secure web gateway is performing TLS inspection on Microsoft 365 traffic that should bypass deep inspection.
• Required Microsoft 365 endpoints are blocked or not matched by the current PAC file.
• VPN split tunneling sends OneDrive or SharePoint traffic through a path that cannot reach Microsoft 365 reliably.
• The OneDrive sync client has stale sign-in state after password reset, MFA registration, tenant move, or UPN change.
• Conditional Access blocks the OAuth flow because the device is not compliant, not hybrid joined, or not matching a named location.
• The device clock, root certificates, or Windows web account broker state is broken.

Microsoft’s support article for 0x8004de40 says the code indicates OneDrive is having trouble connecting to the cloud and calls out TLS deprecation and cipher suite requirements. Microsoft 365 endpoint guidance also warns admins to avoid TLS break-and-inspect and proxy authentication on key Microsoft 365 traffic paths.

Logs and where to check

OneDrive client logs

On the endpoint, start with the user’s OneDrive logs:

$OneDriveLogRoot = Join-Path $env:LOCALAPPDATA 'Microsoft\OneDrive\logs'
Get-ChildItem $OneDriveLogRoot -Recurse -File |
  Sort-Object LastWriteTime -Descending |
  Select-Object FullName, LastWriteTime, Length -First 20

The logs are not always friendly, but the timestamps help you correlate the user report with network, proxy, and Entra sign-in records. Also capture the installed sync client version:

$OneDrive = Get-Item "$env:LOCALAPPDATA\Microsoft\OneDrive\OneDrive.exe" -ErrorAction SilentlyContinue
if ($OneDrive) {
  $OneDrive.VersionInfo | Select-Object ProductVersion, FileVersion, FileName
}

If OneDrive is installed per-machine, also check:

Get-Item 'C:\Program Files\Microsoft OneDrive\OneDrive.exe' -ErrorAction SilentlyContinue |
  Select-Object FullName, @{Name='ProductVersion';Expression={$_.VersionInfo.ProductVersion}}

Entra sign-in logs

In the Entra admin center, check the affected user’s sign-ins:

Microsoft Entra admin center > Identity > Monitoring & health > Sign-in logs

Filter by the user and the failure time. Look for:

• Application names related to OneDrive, SharePoint Online, Microsoft Office, or Office 365 Shell.
• Conditional Access result.
• Failure reason and additional details.
• Client app and device information.
• IP address and named location.

If Entra shows a Conditional Access block, fix the policy condition instead of resetting OneDrive repeatedly.

With Microsoft Graph PowerShell, you can pull recent sign-in failures for a user. Sign-in log permissions are required.

Connect-MgGraph -Scopes AuditLog.Read.All, Directory.Read.All

$UserPrincipalName = 'adele@contoso.com'
$Since = (Get-Date).AddHours(-12).ToString('o')

Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$UserPrincipalName' and createdDateTime ge $Since" -Top 25 |
  Select-Object CreatedDateTime, AppDisplayName, Status, ConditionalAccessStatus, IPAddress, ClientAppUsed |
  Format-List

Network and endpoint checks

On the device, test the obvious endpoints before changing the profile:

$Targets = @(
  'login.microsoftonline.com',
  'www.office.com',
  'www.onedrive.com',
  'admin.onedrive.com',
  'officeclient.microsoft.com',
  'graph.microsoft.com'
)

foreach ($Target in $Targets) {
  Test-NetConnection $Target -Port 443 |
    Select-Object ComputerName, RemoteAddress, TcpTestSucceeded
}

Then test tenant SharePoint Online access. Replace the hostname with your tenant:

$TenantSharePoint = 'contoso-my.sharepoint.com'
Test-NetConnection $TenantSharePoint -Port 443

If *.sharepoint.com fails, OneDrive for Business sign-in and sync will fail even when general internet browsing works.

Fix 1: Verify TLS 1.2 and cipher suites

Microsoft’s 0x8004de40 article explicitly calls out TLS and Azure Front Door cipher suite support. On modern Windows builds, TLS 1.2 should be enabled, but enterprise hardening baselines or old registry settings can still break it.

Check the SCHANNEL protocol keys:

$ProtocolPaths = @(
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'
)

foreach ($Path in $ProtocolPaths) {
  Get-ItemProperty -Path $Path -ErrorAction SilentlyContinue |
    Select-Object PSPath, Enabled, DisabledByDefault
}

Check cipher suite availability and order:

Get-TlsCipherSuite |
  Where-Object Name -match 'ECDHE|DHE' |
  Select-Object Name, Exchange, Cipher, Hash |
  Format-Table -AutoSize

Microsoft lists Azure Front Door-supported TLS 1.2 suites such as:

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

Do not make cipher changes blindly on production devices. If Group Policy controls SSL Cipher Suite Order, fix the policy and test in a pilot ring.

Fix 2: Bypass TLS inspection for Microsoft 365 endpoint categories

If the error started after a firewall, proxy, VPN, or secure web gateway change, focus there. Microsoft recommends direct egress or bypass processing for Optimize and Allow category Microsoft 365 endpoints. Their endpoint documentation also includes SharePoint Online and OneDrive for Business entries such as *.sharepoint.com, *.sharepointonline.com, admin.onedrive.com, officeclient.microsoft.com, and www.onedrive.com.

For a quick workstation check, compare WinHTTP and user proxy settings:

netsh winhttp show proxy
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

If you use a PAC file, confirm the affected OneDrive and SharePoint hosts return the intended route. Many outages come from a PAC rule that sends *.sharepoint.com through inspection while the browser path looks fine for other Microsoft 365 sites.

Ask the network team to check logs for blocks or inspection failures against these destinations at the failure timestamp:

login.microsoftonline.com
*.sharepoint.com
*.sharepointonline.com
www.onedrive.com
admin.onedrive.com
officeclient.microsoft.com
graph.microsoft.com

The exact endpoint list changes. Use the Microsoft 365 endpoint web service or Microsoft’s endpoint page for the current allowlist instead of copying old static IP ranges from a ticket.

Fix 3: Reset OneDrive after the connection path is healthy

Only reset OneDrive after you have ruled out network and Conditional Access failures. Resetting first can hide the evidence and force the user to resync libraries unnecessarily.

Close OneDrive:

Stop-Process -Name OneDrive -Force -ErrorAction SilentlyContinue

Run the reset command from the common install paths:

$ResetPaths = @(
  "$env:LOCALAPPDATA\Microsoft\OneDrive\OneDrive.exe",
  "$env:ProgramFiles\Microsoft OneDrive\OneDrive.exe",
  "${env:ProgramFiles(x86)}\Microsoft OneDrive\OneDrive.exe"
)

foreach ($Path in $ResetPaths) {
  if (Test-Path $Path) {
    Start-Process $Path -ArgumentList '/reset'
    break
  }
}

Wait two minutes, then start OneDrive again:

$StartPath = $ResetPaths | Where-Object { Test-Path $_ } | Select-Object -First 1
Start-Process $StartPath

If the user had many synced libraries, warn them that the client may take time to rebuild status. Do not delete synced folders unless you have confirmed data is safely in OneDrive or SharePoint.

Fix 4: Separate user, device, and network scope

Use a simple matrix before escalating:

Test	Result	What it means
Same user, different network	Works	Local network, proxy, VPN, or firewall path is suspect.
Same user, different managed device	Fails	User policy, license, Conditional Access, or account state is suspect.
Different user, same device	Works	User profile, token cache, or user-specific policy is suspect.
Different user, same network	Fails	Shared network or Microsoft 365 endpoint path is suspect.
Browser sign-in works, sync app fails	OneDrive client state, WAM/token broker, or endpoint difference is suspect.

For device-local token issues, sign out of OneDrive, restart the device, and test again. If all Office apps are broken, broaden the investigation to Windows Web Account Manager and Office activation state.

Prevention

Prevent recurring 0x8004de40 incidents with change control around the connection path:

• Subscribe to Microsoft 365 endpoint changes and review them before firewall rule freezes.
• Keep a documented proxy/PAC test for *.sharepoint.com, *.sharepointonline.com, and Microsoft sign-in endpoints.
• Exclude Microsoft 365 Optimize and required Allow endpoint categories from TLS break-and-inspect where Microsoft recommends bypass.
• Pilot secure web gateway and VPN rule changes with OneDrive sync tests, not only browser tests.
• Keep the OneDrive sync client current through Microsoft 365 Apps servicing or your endpoint management tool.
• Monitor Entra sign-in failures after Conditional Access changes that affect device compliance, named locations, or MFA strength.
• Avoid old TLS hardening templates that disable suites Microsoft 365 still needs.

Admin summary

For OneDrive 0x8004de40, do not start with profile deletion. Prove the sign-in path first: TLS, cipher suites, proxy inspection, Microsoft 365 endpoints, and Entra sign-in logs. If those are clean, reset the OneDrive client and rebuild the token state. The fastest fix is usually in the network/security path, not in the user’s Documents folder.