You're mid-task—maybe firing off an email in Outlook, or kicking off a PowerShell script that talks to Exchange—when the screen freezes for a second and then throws RPC_E_INVALID_DATAPACKET (0x80010009): "The data packet with the marshaled parameter data is incorrect." Infuriating, right? This one usually shows up right after a Windows feature update (like 22H2) or after you reinstall an app that uses COM/DCOM components. I've seen it most often in Outlook connecting to Exchange Online, but it also hits custom in-house apps that rely on remote COM calls.
What's actually happening here?
Let's strip away the jargon. Your app wants to call a function in another process—maybe on the same machine, maybe on a server. It packs up the parameters into a data packet (that's the "marshaling") and sends it over the wire. The receiving end unpacks it and says, "This doesn't look right." The packet structure is off—maybe a version mismatch, maybe a corrupted registry entry, or sometimes a broken proxy/stub DLL that's supposed to handle the unpacking.
The most common trigger I've seen is a Windows update that changes the RPC runtime but doesn't properly refresh the COM registration for older apps. Another one: you've got two versions of the same component (like an Office add-in) and they're stepping on each other's toes. The result is the same—garbage in, error out.
The fix that works 90% of the time
Skip the advice about "repairing your Office installation" first—that's a sledgehammer and it often doesn't touch the real issue. Here's what I do, in order:
- Identify the exact COM/DCOM component. Check the Windows Event Log under
Applications and Services Logs > Microsoft > Windows > RPC. Look for an event ID that references the CLSID. That GUID is your golden ticket. If you don't see it, you're shooting in the dark. - Re-register the COM component. Open Command Prompt as admin and run:
regsvr32 /i "C:\Path\To\Your\Component.dll"If you don't know the path, use the CLSID from the event log and search in regedit under HKEY_CLASSES_ROOT\CLSID\{your-clsid}. Look for the InprocServer32 key—that tells you the DLL. Re-register it. This often fixes the marshaling mismatch because it refreshes the proxy/stub definitions.
- Reset the RPC runtime. Sometimes the whole RPC service gets its knickers in a twist. Restart it:
net stop RpcSs && net start RpcSsNote: Only do this when you're not in the middle of a critical operation—it'll drop any active RPC connections.
- Check for proxy/stub DLLs. If your app is custom, make sure the proxy/stub DLL (often named something like
ps.dllordlldata.c) is present in the system PATH. If it's missing, the receiver can't decode the packet—hence your error. - Force a DCOM permission reset. Open
dcomcnfg, expandComponent Services > Computers > My Computer > DCOM Config. Find the component (by CLSID if you can't spot the name), right-click, Properties, and reset the Launch and Activation Permissions to "Default." Sometimes a stale custom permission entry blocks the marshaling call.
Still failing? Here's the deeper cut
If none of that works, you're likely dealing with a version mismatch between the client and server. For example, you've got Outlook 2016 on a machine that got updated to Windows 11, and the COM interfaces changed. In that case, you need to update the app itself. For Outlook, run Windows Update and Office Update together. For custom apps, yell at your dev team to redeploy with matching proxy/stub DLLs.
One more thing—check if you've got any third-party antivirus that hooks into RPC. I've seen McAfee and Cylance break RPC marshaling by intercepting the packet. Temporarily disable the AV, test, and if it works, exclude your app's executable from the scan.
The last resort is the nuclear option: sfc /scannow followed by DISM /Online /Cleanup-Image /RestoreHealth. That's saved my bacon twice when system files were corrupt.
You got this—the fix is usually a five-minute job once you know where to look.