| Previous | Next |
| RPC_X_BYTE_COUNT_TOO_SMALL | ERROR_INVALID_USER_BUFFER |
RPC_X_BAD_STUB_DATA
What “bad stub data” means
RPC_X_BAD_STUB_DATA is a broad RPC/NDR unmarshaling failure. The receiving stub could not accept the serialized data for the interface and procedure it was processing. The failure occurs at the boundary where an NDR octet stream is decoded into the parameter values expected by the generated or custom stub; the manager routine may never receive the application request.
It should not be diagnosed as “network corruption” by default. Common causes include incompatible client and server stubs, a wrong interface/procedure contract, malformed custom marshaling, invalid correlation values, and input rejected by strict NDR/NDR64 consistency checks.
Investigate in this order
- Identify the interface UUID, interface version, procedure number, transport, and negotiated transfer syntax for the failing call.
- Verify that proxy and server-stub binaries were generated from compatible IDL and MIDL settings; remove stale registered proxy/stub components from the deployment path.
- Audit custom marshal, unmarshal, FFI, and packet-rewrite layers for incorrect alignment, pointer, union-discriminant, or array-correlation handling.
- For a controlled test environment, compare a known-good request with the failing request at the RPC boundary while avoiding capture of secrets or private payloads.
Security and recovery
A malformed request should be rejected rather than “repaired” by guessing values. For a trusted client, correct the client-side contract or rebuild compatible artifacts. For an untrusted or unexpected caller, preserve the status, enforce normal RPC authentication and authorization, and investigate whether the input represents a compatibility error or a probing attempt.
References
Microsoft: strict NDR/NDR64 consistency checks · Microsoft: RPC NDR Engine · The Open Group: DCE NDR transfer syntax
Looking for a different code? Search another status or error code.