Common WWSAPI errors: addressing version mismatch

WWSAPI supports two WS-Addressing versions: the existing W3C recommendation version (1.0) and the older 2004/08 version (0.9). WS-Addressing defines a set of SOAP headers to describe the message recipient, targeted action and some other basic messaging information. When HTTP transport is used, WWSAPI also supports a mode that does not use WS-Addressing. This is called transport addressing mode, where the recipient and action information is carried in HTTP headers. The addressing mode can be set through WS_CHANNEL_PROPERTY_ADDRESSING_VERSION, which defaults to WS-Addressing 1.0. When a WWSAPI client using the default addressing version (1.0) communicates with a WCF endpoint using BasicHttpBinding (transport addressing), you will see the following error messages in the client side trace or in the WS_ERROR object if you use it:


The server returned a SOAP envelope fault: ‘One or more mandatory SOAP header blocks not understood’.

The fault reason was: ‘The header ‘Action’ from the namespace ‘’ was not understood by the recipient of this message, causing the message to not be processed.  This error typically indicates that the sender of this message has enabled a communication protocol that the receiver cannot process.  Please ensure that the configuration of the client’s binding is consistent with the service’s binding. ‘.


In this case, since the client sends a WS-Addressing Action header that is marked with mustUnderstand=”1”, the server sends back a fault complaining the Action header is not understood. The actual WWSAPI error code returned is WS_E_INVALID_FORMAT (0x803d0000) since the SOAP fault does not contain the required infrastructure (WS-Addressing) information the client is looking for.


If the WCF server is using WS-Addressing 1.0 but the WWSAPI client is using transport addressing, the error code will be WS_E_ENDPOINT_FAULT_RECEIVED (0x803d0013). The error messages will look like the following:


The body of the received message contained a fault.

The fault reason was: ‘The SOAP action specified on the message, ”, does not match the HTTP SOAP Action, ‘Add’. ‘.


To fix the error in either case, you’ll need to set the channel properties on the WWSAPI client to use the right addressing version (as well as the right SOAP version) as described in my previous post.

Comments (1)

  1. lilyli says:

    Hi Hao, I got 0x803d0000 when trying to access a web service through the proxy generated by wsutil.exe. I read the post you mentioned about the fix, but the fix seems to be in the WsCreateServiceProxy.. level, which is hidden by WsCreateServiceProxyFromTemplate. So it is not clear to me how I can fix the issue without going under the proxy. Any insight? Thanks!