Microsoft’s new Outlook desktop client for Windows has been failing to launch for a subset of users, producing immediate crashes or silent no‑window launches — but there is a practical, low-risk workaround that has restored service for many affected machines: resetting per‑user local state by renaming or removing two folders, Olk and OneAuth, under %localappdata%\Microsoft. This article walks through what’s known about the failure, why the two‑folder reset generally works, precise, safe instructions for end users and IT pros, and the operational risks and mitigation steps you should plan for when applying the fix at scale.
Background and overview
Since early December 2025 (reports clustered around December 5–9), community and enterprise users began reporting that the new Outlook for Windows would not open on some Windows 11 and Windows 10 machines. Symptoms include clicking the Outlook icon and seeing nothing, immediate application process termination, or Event Viewer entries showing exception codes such as
0xc0000409 referencing OUTLOOK.EXE or olk.exe. Standard troubleshooting — Safe Mode, app repair/reset, uninstall/reinstall — often failed to resolve the problem. Web/Outlook on the web (OWA) typically continued to work, so mail access was not universally lost. Community troubleshooting converged quickly on a repeatable remediation: remove (or preferably rename to keep a backup) two per‑user runtime folders:
- %localappdata%\Microsoft\Olk
- %localappdata%\Microsoft\OneAuth
Renaming these folders forces the Outlook client to recreate runtime caches and re-acquire authentication tokens at the next launch, which has unlocked the UI for a large portion of affected users. Several community threads and Microsoft community advisors have confirmed and recommended this approach as a remediation step while the underlying root cause remains under investigation.
Why the Olk + OneAuth reset tends to work
What those folders contain
- The Olk folder holds per‑user runtime artifacts for the new Outlook client: caches, temporary WebView/embedded browser resources, local logs, and other transient state that speeds startup and enables offline behaviors.
- The OneAuth folder houses short‑lived authentication artifacts — cached tokens, credential handshakes, and local sign‑in state used by the client so it doesn’t have to reauthenticate from scratch on every launch.
When either cache or auth state becomes corrupted, inconsistent, or incompatible with a new client update, the app can fail very early in its startup sequence — sometimes before a visible window is drawn. Removing these artifacts forces a clean rebuild and fresh token negotiation, often bypassing whatever corrupt or invalid state was causing the crash. This is consistent with the crash signatures and the fact that web/OWA remained functional (server‑side data is intact; the client’s per‑user runtime state is the likely trouble spot).
Technical plausibility
The new Outlook uses a more web‑centric architecture and relies heavily on embedded web components (WebView2) and token‑based authentication. If a WebView resource or a cached token is malformed, a startup call can throw a fast exception (0xc0000409 is consistent with certain access/stack corruption or early fail scenarios). Resetting the per‑user state targets precisely the items most likely to be implicated: stale WebView data and corrupted auth blobs. That is why conventional reinstall/reset operations that only operate at the machine or package level can leave the per‑user local state untouched and ineffective for this problem.
Confirming the problem on your machine: triage checklist
Before you change anything, gather evidence. A short triage sequence reduces risk and gives you the detail you’ll need if escalation to Microsoft or your internal helpdesk is required.
- Reproduce the symptom and note the time.
- Open Event Viewer: Windows Logs → Application and filter for recent Error/Crash events.
- Look for entries that reference OUTLOOK.EXE or olk.exe and note the Exception code (0xc0000409 is commonly reported) and the faulting timestamp.
- Confirm whether Outlook opens in Safe Mode:
- Win+R → outlook.exe /safe
- If Safe Mode opens the app, suspect add‑ins; if Safe Mode fails, the issue is deeper (per‑user state, profile, or runtime component).
- Check whether Outlook Web Access (OWA) works — this distinguishes client runtime issues from account/server outages.
Record OS build, Outlook client build/version, and whether the account is managed (Microsoft 365/Exchange Online) or a consumer account. This data helps later when you escalate or search for build‑specific advisories.
Step‑by‑step: the safe user‑level fix (recommended first approach)
Use the rename pattern first so you can quickly revert if needed. Renaming preserves the original data and is reversible.
- Close Outlook and any Office apps. Confirm no Outlook.exe process is running in Task Manager.
- Press Win + R, paste:
%localappdata%\Microsoft
and press Enter.
- Locate the folders named Olk and OneAuth.
- Right‑click each and select Rename. Add a clear suffix such as “.bak” (Olk.bak and OneAuth.bak). Alternatively, copy each folder to a backup location on another drive before deleting.
- Start Outlook normally.
- If prompted to sign in, follow the sign‑in flow. Allow a few minutes for the client to recreate caches and sync mail.
- Confirm mail flow and that the app is stable for a session or two. Once confident, you may delete the .bak backups to reclaim disk space.
PowerShell alternative for one‑off renames (run as the affected user):
$path = "$env:LOCALAPPDATA\Microsoft"
Rename-Item "$path\Olk" "$path\Olk.bak" -ErrorAction SilentlyContinue
Rename-Item "$path\OneAuth" "$path\OneAuth.bak" -ErrorAction SilentlyContinue
This approach is the community‑validated first step and is the least invasive because it preserves a restorable backup. If it works, you’ll see Outlook launch and re‑synchronize accounts.
Risks, gotchas, and important cautions
- Local PST/OST files: The Olk/OneAuth reset targets transient caches and authentication state. It should not delete PST or OST mail stores that live in Documents or other user locations, but administrators should still confirm where any locally stored PST/OST files live before mass operations. If a profile uses locally stored PSTs that aren’t synced with the cloud, back them up first.
- User re‑authentication: Deleting OneAuth forces reauthentication. If users don’t remember secondary authentication methods, MFA prompts, or corporate SSO, they may be temporarily locked out until they can complete sign‑in steps.
- Temporary UI differences: Some users report cosmetic or configuration differences until the client fully re‑syncs account settings. These typically stabilize after a short period.
- Not a guaranteed permanent fix: For some users the reset is temporary; the underlying cause (a defective client update, a server‑side change, or an intermittent corruption) may cause recurrence until Microsoft issues a patch. Track recurrence and escalate if widespread.
- Enterprise scale hazards: Do NOT run a machine‑wide deletion on %localappdata% without scoping. That risks data loss for multi‑user machines or shared profiles and can produce a support nightmare. Use per‑user scripts executed in user context (Intune Proactive Remediations, sign‑in scripts, or scheduled tasks run as the user) and prefer rename over delete initially.
What to do if the fix doesn’t work
If renaming Olk and OneAuth does not bring Outlook back:
- Try creating a new Windows user profile and test Outlook there (if it opens, the issue is confined to the original profile).
- Run the Microsoft Support and Recovery Assistant (SaRA) which can detect configuration problems with Office/Outlook.
- Repair Office (Control Panel → Programs → Microsoft 365 → Modify → Online Repair).
- Collect Event Viewer logs and timestamps, and escalate to Microsoft support or your tenant administrator with the logs.
- Inspect the WebView2 runtime and update it if it is severely out of date — the new client relies on WebView2 in many scenarios.
- If the environment uses third‑party add‑ins or legacy sync tools (Google Workspace Sync, third‑party add‑ins), verify compatibility and update them; plugin incompatibilities have caused other Outlook startup problems historically.
Enterprise guidance: controlled rollout and telemetry
If you are an IT admin facing multiple impacted users, follow this recommended workflow.
- Triage and evidence collection (Event Viewer, Outlook build, Windows build).
- Sandbox the rename approach on a single affected workstation.
- If successful, create a user‑context remediation package (Intune Proactive Remediations or ConfigMgr run as user) that renames Olk and OneAuth to .bak rather than deleting them.
- Push the remediation to a pilot group (10–50 users) and monitor for:
- Repro rate
- Reauthentication failures
- Recurrence within 24–72 hours
- If the pilot is successful, widen the rollout. Maintain the renamed backups for at least one business day in case rollback is necessary.
- Prepare a communications plan explaining that users will need to sign in again and might see temporary UI differences. Provide step‑by‑step assistance for MFA reconfirmation if necessary.
Sample Intune PowerShell snippet (user context) — rename only, no deletion:
$path = "$env:LOCALAPPDATA\Microsoft"
If (Test-Path "$path\Olk") { Rename-Item "$path\Olk" "$path\Olk.bak" -ErrorAction SilentlyContinue }
If (Test-Path "$path\OneAuth") { Rename-Item "$path\OneAuth" "$path\OneAuth.bak" -ErrorAction SilentlyContinue }
Return 0
Always test the script at the scale you intend before broad deployment.
What Microsoft has (and hasn’t) said
Microsoft Support documents confirm that Outlook can fail to start for a range of reasons and that Event Viewer entries with exception codes such as
0xc0000409 are a valid diagnostic artifact to examine for crashes. Microsoft’s published troubleshooting guidance includes Safe Mode, add‑in removal, profile recreation, and data file repair as standard steps. However, Microsoft has not always issued a formal public advisory tying every new Outlook “won’t open” wave to a specific update or server change; community reports and Microsoft community advisors have independently recommended the Olk/OneAuth reset as an effective remediation. That combination — official guidance on general startup failures plus community‑confirmed targeted remediation — is the basis for the steps outlined in this piece. Note: community reporting and vendor blogs (Windows Forum, Reddit threads, third‑party help pages) are currently the primary public sources documenting the Olk/OneAuth remediation pattern. Users and admins should continue to watch Microsoft’s official support pages and Known Issues portal for any formal root‑cause statement or patch announcement.
Longer‑term considerations and hardening
- Advocate that Microsoft harden startup logic to handle corrupted per‑user caches gracefully (either by auto‑rebuilding on failure or by routing to an automated repair flow).
- For organizations, include per‑user local state resets as a documented remediation play in runbooks for critical productivity app outages.
- Keep device inventories and telemetry in place so you can quickly correlate an app rollout with the appearance of startup errors (build numbers and timestamps matter).
- Test updates in rings: maintain pilot rings for Outlook or Office updates to catch client regressions before broad deployment.
- Maintain backups for local PST/OST files outside of %localappdata% locations to avoid risk when remediation touches user profiles.
Quick reference — trimmed checklist for end users
- Close Outlook fully; confirm no Outlook.exe in Task Manager.
- Win+R → %localappdata%\Microsoft → rename Olk → Olk.bak and OneAuth → OneAuth.bak.
- Reopen Outlook; follow sign‑in prompts.
- If Outlook opens and mail syncs, leave it running for a few minutes and delete backups later if all is well.
- If problem persists, collect Event Viewer logs and escalate to IT or Microsoft support.
Final analysis: strengths, limitations, and risk assessment
The community‑recommended Olk + OneAuth rename is a low‑risk, high‑reward remediation: it targets precisely the per‑user runtime artifacts most likely to cause an immediate startup failure, is reversible, and restores service without needing a full OS or app reinstall. That makes it an attractive first‑line fix for both consumers and enterprise helpdesks.
However, the approach is a stopgap. It does not replace the need for Microsoft to identify and fix the underlying defect if the cause is a client regression or server‑side change. Administrators should be cautious when scaling the remediation, have a tested rollback plan, and ensure users have the credentials needed to reauthenticate. In environments with strict authentication tooling or where users rely on locally stored PST data, extra safeguards are mandatory. Finally, because the new Outlook increasingly uses WebView2 and tokenized auth, organizations should keep the WebView2 runtime and Microsoft 365 libraries patched and current to minimize exposure.
This episode also underlines a broader truth about modern client apps: per‑user local state is both a performance enabler and a fragile surface area. Good operational hygiene — pilot rings, telemetry, and actionable runbooks — reduces blast radius when those fragile surfaces fail.
Every organization should now have a concise remediation playbook in place for this issue: evidence collection, a reversible Olk/OneAuth rename, pilot automation for user context, and escalation to Microsoft with logs if failures persist. That combination will get most users back to work quickly while protecting data and minimizing disruption.
Source: Windows Latest
New Outlook won't launch on Windows 11 for some users, but there's a fix if you ever run into the issue