Outlook 0x8004010F: Fix the 'Object Cannot Be Found' Error

You hit Send/Receive, Outlook throws 0x8004010F, and now you're staring at "The operation failed. An object cannot be found." Annoying, but this one's fixable in about ten minutes.

The Fix (Do This First)

Nine times out of ten, the offline address book (OAB) is hosed or Outlook's local cache is out of sync with Exchange. Here's the sequence that clears it:

1. Force a manual Send/Receive. Hit F9. If the error only shows on the OAB sync step, continue below.
2. Delete the local OAB cache. Close Outlook completely. Then nuke these folders:

%LOCALAPPDATA%\Microsoft\Outlook\Offline Address Books
%USERPROFILE%\AppData\Local\Microsoft\Outlook\Offline Address Books

Both paths resolve to the same place on most systems — the second is just the expanded version. Delete everything inside.

3. Clear the OST cache too if the error persists. Same drill, close Outlook, then:

%LOCALAPPDATA%\Microsoft\Outlook\*.ost

Rename the .ost to old.ost instead of deleting — Outlook will rebuild it on next launch. If you're on Exchange, this pulls everything fresh from the server.

4. Kill Outlook, restart it. Let it sync. That first sync can take 10–30 minutes depending on mailbox size.

If step 2 fixes it, you're done. Don't touch the OST — that's a bigger hammer and costs you a full resync.

If That Didn't Work — Rebuild the Profile

Still seeing 0x8004010F? Your Outlook profile is likely corrupted. This happens on Windows 10/11 machines after a botched Office update, or when the user roamed between two Exchange servers without a clean logoff.

1. Control Panel → Mail (Microsoft Outlook) → Show Profiles.
2. Click Add, name it something like Outlook-New.
3. Enter the same email account. Autodiscover should do the rest.
4. Under "When starting Microsoft Outlook, use this profile" pick the new one.
5. Launch Outlook. Walk away for 20 minutes.

On Windows 11 you might not see the Mail applet in Control Panel. Run this instead:

control mlcfg32.cpl

Or if you're on 64-bit Office:

control mlcfg64.cpl

Why This Works

0x8004010F is a MAPI error. Translation: "I tried to open an object by ID and it's not there." Outlook keeps a local copy of the OAB in a .oab file, and a local copy of your mailbox in the .ost. When either of those gets truncated — say, from a hard shutdown mid-sync, a disk write that didn't flush, or antivirus locking the file during a Send/Receive — the next sync references object IDs that no longer exist.

Deleting the OAB forces Outlook to pull a fresh copy from the Exchange server. Renaming the OST forces a full mailbox resync. Rebuilding the profile wipes the MAPI store's registry pointers that map your account to the broken cache.

The OAB directory is at the top of the list because it's the smallest file, resyncs fastest, and is the actual failure point in 80% of the tickets I've worked.

Less Common Variations

Error appears only when you open the Address Book

That's the OAB again, but the sync schedule might be the culprit. In Outlook, Send/Receive tab → Send/Receive Groups → Define Send/Receive Groups → Edit. Make sure "Download offline address book" is checked and the schedule isn't set to "Never."

Error on a shared mailbox or delegate

Remove the delegate permission and re-add it. Shared mailboxes mounted as additional accounts can leave orphaned references in the profile. Go into Account Settings → double-click the shared account → More Settings → Advanced → uncheck "Download shared folders" then re-check it. That forces a remount.

Error after migrating to Microsoft 365

Classic. Your old on-prem Exchange OAB is still referenced. In Account Settings, verify Autodiscover is hitting the right endpoint. Run this to check:

nslookup -type=SRV _autodiscover._tcp.yourdomain.com

You should see an SRV record pointing to autodiscover.outlook.com. If you're still seeing your old Exchange CAS server, DNS is stale. Flush it with ipconfig /flushdns and confirm your DHCP is handing out the right DNS servers.

Error in Outlook 2013 specifically

There's a known bug where Outlook 2013 SP1 and earlier won't sync the OAB over MAPI/HTTP. Install KB4011626 or later, or just upgrade — 2013 is past end of support anyway.

Error only for one user, everyone else is fine

Check their Windows user profile. If the local AppData\Local\Microsoft\Outlook folder has permissions issues (SID mismatch after a domain migration), Outlook can't write to the cache. Recreate the Windows profile as a last resort — it's a pain but it fixes the weird ones.

Prevention

• Don't kill Outlook with Task Manager. Alt+F4 or File → Exit. Hard-killing during sync is the #1 cause of a corrupted OAB.
• Exclude Outlook cache folders from antivirus scanning. Real-time scanners locking .ost and .oab files mid-write cause this error constantly. Add exclusions for %LOCALAPPDATA%\Microsoft\Outlook and %USERPROFILE%\AppData\Local\Microsoft\Outlook.
• Cached Exchange Mode in Outlook 2016+ defaults to 12 months. That's fine, but if you're on a slow link, set it to 3 months. Less to corrupt, less to resync.
• Keep Office patched. The OAB sync stack gets bug fixes every few months. Enable automatic updates or push via WSUS.
• For laptops that hibernate a lot, consider forcing a full Send/Receive on resume. Group Policy can trigger this.

One last thing — if you're still getting 0x8004010F after all of this, check the Exchange server's OAB generation schedule. If the OAB hasn't been regenerated in weeks, every client is syncing a stale file. On Exchange 2016/2019 that's under Organization → Mailbox → Offline Address Book → right-click → Update. Then restart the File Distribution service on the mailbox server.