How to Fix Outlook ClientTOC Errors & Folder Issues
Why This Is Happening
You open Outlook. The loading bar creeps to about 80% and just… stops. Or your folder pane is completely blank. Maybe Outlook keeps looping on "Trying to connect…" even though your internet is fine, your VPN is connected, and literally every other app has full network access. Sound familiar?
What you're dealing with is almost certainly a corrupted or stale ClientTOC cache , Outlook's local Table of Contents file that maps your entire mailbox folder hierarchy. Most users have never heard of it, and Microsoft's error messages certainly don't mention it by name. Instead you get the ever-helpful "Something went wrong" or a silent freeze that forces a hard kill via Task Manager.
Here's what the ClientTOC actually does. Every time Outlook connects to an Exchange Online or on-premises Exchange mailbox, it needs to know the structure of your folders , Inbox, Sent Items, Archives, any custom folders you or your IT admin created. Downloading that entire hierarchy from the server on every launch would be painfully slow, especially with large mailboxes or slow corporate WAN links. So Outlook caches that folder tree locally in a set of .toc cache files, stored under your AppData profile directory. On next launch, Outlook reads the cached structure first and syncs any delta changes from the server.
The problem? These files get corrupted. They go stale after server-side mailbox moves, Exchange migrations, Microsoft 365 tenant changes, or even a poorly-timed Outlook crash mid-write. When that happens, Outlook tries to read an invalid structure map, fails silently or loudly, and refuses to load your folders.
I've seen this exact scenario play out most often in four situations: after an organization migrates from on-premises Exchange to Exchange Online, after an IT team renames or restructures shared mailboxes, after a forced Windows profile roaming sync overwrites a good local cache with a stale copy from another machine, and after a Windows Update forcibly reboots a machine while Outlook is still open. None of those are your fault, but you're the one who has to fix it.
Who sees this most? Corporate Outlook users on Microsoft 365 or Exchange, particularly anyone on a domain-joined machine whose AppData folder is roamed via Group Policy. Home users on personal Microsoft accounts can hit it too, but it's far more common in enterprise environments. The classic symptom fingerprint is: Outlook opens, shows the splash screen, gets to "Loading profile…" or "Updating folder list…" and then either freezes indefinitely or crashes with Event ID 1000 in Windows Event Viewer pointing to OUTLOOK.EXE.
The Quick Fix, Try This First
Before diving into anything complex, let's delete the ClientTOC cache files. Outlook will rebuild them automatically on the next launch, pulling a fresh folder hierarchy directly from the server. This single action resolves the problem in roughly 70% of cases I've worked through.
First, make sure Outlook is completely closed. Don't just hit the X button, check Task Manager (Ctrl+Shift+Esc), click the Processes tab, and verify there's no OUTLOOK.EXE running. If there is, right-click it and choose End Task.
Now open File Explorer and paste this path directly into the address bar:
%LOCALAPPDATA%\Microsoft\OutlookPress Enter. You'll land in a folder full of Outlook data files. Look for any files with a .toc extension, they're typically named something like Outlook.clienttoc, or you may see multiple .toc files with GUIDs in their names. You might also spot files named extend.dat and views.dat in the same directory, leave those alone for now.
Select all .toc files and delete them. Don't be nervous, these are pure cache files. Deleting them causes zero data loss. Your emails, calendar entries, contacts, and folder rules are stored either on the server or in your .ost/.pst files, which you're not touching.
Also check this second location, especially if you're on a roaming profile setup:
%APPDATA%\Microsoft\OutlookDelete any .toc files there too. Then relaunch Outlook. On first open it will spend 30–90 seconds rebuilding the folder cache from the server, you'll see "Updating folder list…" in the status bar at the bottom. That's completely normal. Once it finishes, your folder pane should be fully populated and functional.
.toc.bak instead of outright deleting them. If something goes sideways (rare, but possible on older Outlook 2016 builds), you can rename them back. Once Outlook is confirmed working, delete the .bak files for good.
The quick fix above gives you the short path, but let me walk through this more carefully so you know exactly what you're dealing with. The ClientTOC cache in Outlook can live in two profile directories depending on how your machine is configured and which version of Outlook you're running.
Open PowerShell (search "PowerShell" in Start, no admin rights needed) and run this command to find every .toc file associated with your Outlook profile in one shot:
Get-ChildItem -Path "$env:LOCALAPPDATA\Microsoft\Outlook", "$env:APPDATA\Microsoft\Outlook" -Filter "*.toc" -ErrorAction SilentlyContinue | Select-Object FullName, LastWriteTime, LengthThis lists every .toc file, its full path, when it was last written to, and its size. A corrupted file often shows an abnormally small size (under 1 KB when it should be several KB) or a LastWriteTime that matches exactly when your Outlook last crashed, a clear tell.
To delete them all automatically via PowerShell (with Outlook closed):
Get-ChildItem -Path "$env:LOCALAPPDATA\Microsoft\Outlook", "$env:APPDATA\Microsoft\Outlook" -Filter "*.toc" -ErrorAction SilentlyContinue | Remove-Item -ForceAfter running that, relaunch Outlook. Watch the status bar at the bottom of the Outlook window. You should see it cycle through "Connected to Microsoft Exchange," then "Updating folder list…", give it up to two minutes on large mailboxes. If your folder pane populates normally, you're done. If Outlook still freezes or the folder pane stays blank, move to Step 2.
Add-ins are the second most common culprit behind Outlook ClientTOC loading failures. A broken or outdated COM add-in can intercept the folder initialization sequence and cause it to hang before the cache even gets a chance to rebuild. I know, the error looks like a cache problem, but the real blocker is an add-in that's wedged into the startup chain.
Launch Outlook in Safe Mode by holding Ctrl while clicking the Outlook shortcut, or run this from the Run dialog (Win+R):
outlook.exe /safeSafe Mode disables all COM add-ins. If Outlook loads cleanly and your folder pane works normally in Safe Mode, you've confirmed an add-in conflict. Now you need to find the specific offender.
Exit Safe Mode and relaunch Outlook normally. Go to File > Options > Add-ins. At the bottom, where it says Manage: COM Add-ins, click Go…. You'll see a list of all active add-ins. Uncheck them all and click OK. Restart Outlook, if it loads fine, re-enable add-ins one at a time, restarting Outlook between each, until you find the one that breaks folder loading.
Common offenders I've seen repeatedly: older versions of the Cisco Webex Meetings add-in, Adobe Acrobat PDF Maker, legacy CRM connector add-ins, and any add-in that hasn't been updated in 12+ months. If you find the culprit, either update it from the vendor's site or leave it disabled.
If clearing the ClientTOC cache and disabling add-ins didn't fix the problem, the issue has likely moved deeper, into the Outlook profile itself. The mail profile stores your account settings, cached credentials, server connection strings, and synchronization state. A corrupted profile can produce exactly the same symptoms as corrupted TOC files.
Do not delete your .ost file yet, that's a more drastic step we'll cover in Step 4. For now, create a brand new Outlook profile while keeping the old one intact as a fallback.
Close Outlook completely. Open Control Panel, search for it in Start, or press Win+R and type control. In Control Panel, set the view to Large Icons and click Mail (Microsoft Outlook). In the Mail Setup dialog, click Show Profiles….
Click Add, give the new profile a name like "Outlook-Fresh", and walk through the account setup wizard. Enter your email address, if you're on Microsoft 365, Outlook will auto-discover the server settings via Autodiscover. Once setup completes, back in the Profiles dialog, change the option from "Use this profile" to "Prompt for a profile to be used" and click OK.
Launch Outlook. When prompted, choose your new "Outlook-Fresh" profile. If Outlook loads cleanly and your folder pane populates correctly, your old profile was the issue. You can safely delete it after confirming the new one is stable for a day or two.
The .ost (Offline Storage Table) file is Outlook's local copy of your mailbox, everything synced down from the Exchange or Microsoft 365 server for offline access. When it gets corrupted, or when the sync state mismatches what the server expects, you can get folder pane failures that look identical to ClientTOC corruption but won't respond to cache clearing alone.
Before deleting the OST file, understand this: your data is not permanently stored in the OST if you're on Exchange Online or Exchange Server. It's a sync cache. Deleting it forces a full re-download from the server, which takes time but loses nothing. The exception: if you have local draft emails not yet sent, or calendar items created offline that haven't synced, save or send those first.
Close Outlook completely. Navigate to:
%LOCALAPPDATA%\Microsoft\OutlookYou'll see one or more .ost files, often named with your email address. Before deleting, rename the file:
yourname@company.com.ost → yourname@company.com.ost.oldRelaunch Outlook. It will detect the missing OST and create a new one automatically, then begin a full re-sync from the server. On a large mailbox (50GB+), this can take several hours. You can use Outlook normally while it syncs in the background, the status bar shows sync progress. Once complete, if everything looks good, delete the .ost.old file to reclaim disk space.
When the above steps haven't resolved the Outlook ClientTOC problem, the issue may be with the Office installation itself, missing or corrupted DLL files, a failed update that left Office in a partially-updated state, or registry entries that got mangled. The Office repair tool targets exactly these scenarios.
Open Settings (Win+I), go to Apps > Installed apps (or Apps & features on Windows 10). Search for "Microsoft 365" or "Microsoft Office" in the list. Click the three-dot menu next to it and choose Modify. You may get a UAC prompt, click Yes.
In the repair wizard, you'll see two options: Quick Repair and Online Repair. Start with Quick Repair, it takes about 5 minutes, doesn't require internet, and fixes most file corruption issues by replacing damaged Office binaries from the local installation cache. If Quick Repair doesn't fix Outlook after a restart, run Online Repair. This fully re-downloads the Office suite from Microsoft's servers and does a clean reinstall while preserving your data files and account settings. Online Repair takes 20–45 minutes depending on your connection.
After repair completes, relaunch Outlook without doing anything else first. Go through the normal startup sequence and see if the folder pane loads. If it still fails after Online Repair, you're in advanced territory, move to the next section.
Advanced Troubleshooting
Still stuck? Let's go deeper. These techniques are what I reach for when the standard fixes don't work, they're appropriate for IT professionals, sys admins, or technically confident home users.
Reading Event Viewer for Outlook ClientTOC Crash Signatures
Open Event Viewer: press Win+R, type eventvwr.msc, press Enter. Navigate to Windows Logs > Application. Filter by Source = "Application Error" or source containing "Outlook". Look for Event ID 1000 (application crash) with OUTLOOK.EXE as the faulting application. The faulting module name is key, if you see mso.dll, olmapi32.dll, or outlmime.dll, the Office installation itself needs repair. If you see a third-party DLL name, an add-in is crashing Outlook.
Also check for Event ID 26 under Application source "Outlook", this specifically logs folder synchronization failures and cache write errors, which map directly to ClientTOC corruption events.
Group Policy and Cached Exchange Mode Settings
On domain-joined machines, Group Policy can force Outlook into configurations that conflict with ClientTOC caching. Open the Registry Editor (Win+R, type regedit) and navigate to:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Cached ModeIf you see a value named Enable set to 0, Group Policy is forcing Outlook into Online Mode, which can conflict with cached profile configurations. Check with your IT admin before modifying policy-set values, but knowing this is the cause is half the battle.
Clearing the Autodiscover Cache
A stale Autodiscover cache can cause Outlook to connect to the wrong Exchange endpoint, resulting in server-side folder hierarchy responses that Outlook can't map to its local ClientTOC structure. Delete the Autodiscover cache by removing this registry key entirely (export it first as a backup):
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscoverNetwork-Level and Proxy Issues
If Outlook can authenticate but hangs on folder list loading specifically, the issue may be an SSL inspection proxy or firewall that's mangling the MAPI over HTTPS connection used by modern Outlook. Run this from an elevated PowerShell prompt to test direct connectivity to Exchange Online:
Test-NetConnection -ComputerName outlook.office365.com -Port 443If TcpTestSucceeded is False, the network path is blocked. Work with your network team to ensure *.outlook.office365.com and *.office365.com are excluded from SSL inspection.
Enterprise: Mailbox Move Aftermath
If your organization recently completed an Exchange mailbox move, either on-premises to on-premises, or on-premises to Exchange Online, the ClientTOC cache will contain folder GUIDs that are now invalid on the destination server. The fix is to delete all TOC files and the OST file simultaneously, then let Outlook reprovision from scratch against the new mailbox location. This is expected behavior after migrations and not a sign of deeper problems.
Prevention & Best Practices
Once you've fixed the ClientTOC problem, the last thing you want is to go through all of this again three months from now. Here's what actually works to keep Outlook running cleanly long-term.
The single biggest thing you can do: never force-kill Outlook while it's syncing. I know that's not always possible, sometimes the machine freezes and you have no choice. But Outlook's cache files, including the ClientTOC, are written in an append/commit cycle. A hard kill mid-write leaves them in a half-written, unreadable state. If Outlook is slow or hung, try Ctrl+Alt+Del > Task Manager and use End Task rather than holding the power button. End Task at least lets Windows close file handles gracefully.
Keep your Office installation on the Current Channel update track (for Microsoft 365 subscribers) rather than Semi-Annual Enterprise Channel if your IT policy allows it. Microsoft regularly ships Outlook fixes on Current Channel weeks before they reach Semi-Annual, and several notorious ClientTOC-related bugs have been patched in Current Channel updates. Check your update channel via File > Office Account > Update Options > About.
If you're an IT admin managing Outlook across a fleet, set up a scheduled task to automatically clear TOC cache files during off-hours once a month. It's a low-impact, zero-data-loss operation that prevents stale cache accumulation from becoming a problem. A simple PowerShell script scheduled via Task Scheduler handles this cleanly.
Roaming profiles in enterprise environments deserve special attention. If your organization uses roaming profiles (AppData gets synced to a network share), work with your AD team to exclude %APPDATA%\Microsoft\Outlook\*.toc and %LOCALAPPDATA%\Microsoft\Outlook\*.toc from the roaming profile scope. TOC files are machine-specific, roaming them between workstations is a guaranteed way to spread cache corruption across every machine a user logs into.
- Schedule monthly TOC cache clearing via a PowerShell scheduled task to prevent stale accumulation
- Exclude
*.tocfiles from roaming profile sync in Group Policy to prevent cross-machine cache corruption - Keep Microsoft 365 / Office on Current Channel to receive Outlook cache bug fixes faster
- Always use End Task rather than a hard power-off when Outlook is unresponsive, it preserves file handle integrity
Frequently Asked Questions
Will deleting the ClientTOC .toc files delete my emails?
No, not even close. The .toc files are pure navigation cache. They contain folder structure metadata, not email content. Your actual emails live either in your .ost file (for Exchange/Microsoft 365 accounts) or on the server itself. Deleting .toc files just forces Outlook to re-download the folder map from the server on next launch. It's the equivalent of clearing a browser's tab thumbnail cache, cosmetic data only, nothing substantive is lost.
Outlook says "Trying to connect" forever and won't open folders, is this a ClientTOC problem?
It could be, but "Trying to connect" can also mean a genuine network or authentication failure. First, test that your internet is working and try opening Outlook Web App (OWA) in a browser. If OWA works fine, then yes, the issue is almost certainly a corrupted local cache, start by deleting the .toc files as described in Step 1. If OWA is also broken, the problem is upstream: check your Microsoft 365 service health at the Microsoft 365 Admin Center, or contact your Exchange admin.
Where exactly are the Outlook ClientTOC files on Windows 11?
They live in two possible locations. The primary location is %LOCALAPPDATA%\Microsoft\Outlook\, which expands to C:\Users\YourUsername\AppData\Local\Microsoft\Outlook\. The secondary location is %APPDATA%\Microsoft\Outlook\, which expands to C:\Users\YourUsername\AppData\Roaming\Microsoft\Outlook\. You should check both. The AppData folder is hidden by default, in File Explorer, go to View > Show > Hidden items to make it visible, or paste the path directly into the address bar.
My Outlook folder pane loads but some folders are missing, is that also a ClientTOC issue?
Yes, partial folder list issues are a classic symptom of a partially-corrupted or stale ClientTOC cache. The cache loaded successfully but reflects an outdated folder structure, typically after a mailbox migration, server-side folder rename, or shared mailbox permission change. Clearing the .toc files and restarting Outlook forces a fresh hierarchy download that picks up all the current folders. If specific shared mailboxes are missing after the fix, also check that your account still has the correct permissions on those mailboxes in your admin center.
How long does it take Outlook to rebuild the folder cache after I delete the TOC files?
For a typical Microsoft 365 mailbox with 20–50 folders, rebuilding takes 30–90 seconds. You'll see "Updating folder list…" in the Outlook status bar at the bottom while it's working. For large enterprise mailboxes with hundreds of folders, shared mailboxes, and delegated calendars, it can take 3–5 minutes. Just let it run, don't close Outlook partway through or you risk corrupting the new cache file before it finishes writing.
I'm an IT admin, how do I fix this for multiple users at once without touching each machine?
The cleanest enterprise approach is a PowerShell script deployed via Microsoft Endpoint Configuration Manager (MECM/SCCM) or Intune as a remediation script. The script kills the Outlook process if running, removes all *.toc files from both AppData locations, then optionally logs the action to a central share. You can also push a Group Policy Preference that deletes TOC files on user logon, use a Files preference item targeting %LOCALAPPDATA%\Microsoft\Outlook\*.toc with the action set to Delete. This runs silently at each logon and keeps the cache fresh across your fleet without any user interaction.