Fix: Word 'Command Failed to Execute' Inserting Excel Chart

You're in Word, you go to Insert > Object > Create from File (or you paste an Excel chart with Paste Special > Microsoft Excel Chart Object), and Windows slaps you with "The command failed to execute." No chart. No clue. It happens most often after a Windows Update, a Microsoft 365 Click-to-Run update, or when Excel and Word are on different build channels — say Word 16.0.17328 and Excel 16.0.17231. The dialog gives you a single OK button and zero diagnostic info, which is genuinely maddening when you've got a deck due in an hour.

I've seen this on Windows 11 23H2 with Office 365, on Windows 10 22H2 with Office 2019, and even on a fresh Surface Pro 9 out of the box. The good news: it's almost never Word itself. It's the OLE plumbing between Word and Excel.

What's Actually Broke

OLE (Object Linking and Embedding) is the ancient COM-based glue that lets one Office app host another app's object inside it. When you drop an Excel chart into Word, Word doesn't render the chart — it asks the Excel OLE server to do that, using registry entries under HKEY_CLASSES_ROOT\CLSID and HKEY_CLASSES_ROOT\Excel.Chart. If those keys are missing, corrupted, or point at the wrong LocalServer32 path, Word calls out, nobody answers, and you get "The command failed to execute."

Three things break this most often:

Excel is set to run as a different user or elevated. If Excel is running as admin (common if you launched it from an elevated shortcut), Word can't talk to it because of UIPI (User Interface Privilege Isolation).
The Excel.Chart ProgID is unregistered. A botched Office update or a third-party uninstaller can strip this key.
DDE is disabled by policy. Some enterprise hardening guides tell admins to block DDE. That kills OLE embedding for Excel objects.

There's also a fourth, sneakier cause: the file you're inserting into is protected by Information Rights Management or is in a folder synced by a cloud provider that's holding a lock on the temp OLE file. That one drove me nuts for two days on a client's machine before I spotted it.

The Fix (Numbered, In Order)

Do these in order. Stop when it works.

Close everything. Word, Excel, Outlook, Teams. All of it. Check Task Manager for stray EXCEL.EXE or WINWORD.EXE processes and kill them. OLE registration changes won't take while the apps are running.
Make sure Excel isn't elevated. Right-click Excel in the Start menu and check if "Run as administrator" is ticked. If your shortcut has that flag, untick it. Same for Word. Both apps must run at the same integrity level.
Re-register the OLE servers. Open Command Prompt as Administrator and run:

regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s stdole2.tlb

Repair Office. Go to Settings > Apps > Installed apps, find Microsoft 365 (or Office 2019/2021), click the three dots, Modify > Quick Repair. If that doesn't fix it, run Online Repair — it takes 15–20 minutes but it rewrites the OLE registry entries from scratch. This is the fix that works 80% of the time, in my experience.
Verify the Excel.Chart key exists. Open Registry Editor (regedit) and check:

HKEY_CLASSES_ROOT\Excel.Chart
HKEY_CLASSES_ROOT\Excel.Chart\CLSID
HKEY_CLASSES_ROOT\CLSID\{00020821-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\CLSID\{00020821-0000-0000-C000-000000000046}\LocalServer32

The LocalServer32 default value should point at your Excel EXE, something like C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE /automation. If that folder doesn't match where Office actually lives, Word can't launch Excel as an OLE server. Fix the path or reinstall.

Check DDE policy. If you're on a managed machine, ask IT whether DisableUserDefinedDDE or any DDE-blocking GPO is applied. In gpedit, it's under User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security. If your org blocks DDE, OLE insertion of Excel objects simply won't work — no workaround exists except asking them to whitelist it or using a different insertion method.
Test with a clean doc. Open a brand-new blank Word doc and try inserting an Excel chart. If it works there but not in your original file, the file itself is the problem — likely IRM protection or a corrupted embedded object. Copy your content into a fresh doc.

If It Still Fails

At this point you've eliminated the common causes. What's left:

Antivirus / EDR blocking COM. CrowdStrike Falcon, SentinelOne, and even some Bitdefender configs hook OLE calls and silently kill them. Temporarily disable and retest. If it works, get an exclusion added for EXCEL.EXE and WINWORD.EXE.
Cloud sync lock. If the .docx is inside a OneDrive, Dropbox, or SharePoint folder that's actively syncing, the OLE temp file can't be created. Copy the doc to C:\Temp and try inserting there.
Windows user profile corruption. Create a fresh local Windows user, log in, test. If it works, your main profile's COM registration is hosed and you're looking at a profile rebuild or a HKCR hive repair.
Office bitness mismatch. A 32-bit Word and 64-bit Excel can't share OLE objects reliably. Check File > Account > About Word — it'll say 32-bit or 64-bit. Both apps must match.
Old .NET or VC++ redistributables. Yes, really. The OLE automation layer leans on msvcp140.dll and friends. Install the latest Visual C++ Redistributable (2015–2022, both x86 and x64) and reboot.

If none of that works, uninstall Office with the Microsoft Support and Recovery Assistant (it scrubs the registry, unlike a normal uninstall), reboot, and reinstall. I know that sounds like a sledgehammer. It's also the fastest path when you've burned a day on this error.

Workaround That Always Works

If you just need the chart in the doc and you don't need it to stay live, skip OLE entirely. In Excel, select the chart, copy it, then in Word use Paste Special > Picture (Enhanced Metafile). It's a static image — no OLE handshake, no error, no dependency on Excel being installed. For 90% of business documents, that's actually the better choice anyway. Live Excel objects inside Word files have been a stability headache for decades.