.net – How to avoid CommunicationObjectFaultedException when hosting a WCF service in IIS

wsHttpBinding defaults to using Windows credentials for authentication, which is fine as long as you are on the same domain, or on domain with full trust relationships.

The error message seems to point to a timeout - maybe you need to tweak those. Once an exception happens on your server which is not handled properly and turned into a SOAP fault, then the channel (the connection between client and server) is "faulted", e.g. it goes into a state of error, and cannot be used anymore. All you can do is abort the channel (you can't even close it anymore at that point), and re-create it from scratch.

Or maybe this timeout happens because you have wrapped your client proxy's usage into a using(......) {......} block? That's usually a great idea - but not in the case of a WCF client proxy.

The problem occurs because of the fact that once a channel is faulted, you can't even close it anymore. If you wrap your client proxy usage into a using() statement, when something goes bad on the server and isn't handled properly, the channel will fault, and at the end of the using() block, the .NET runtime tries to close it, which then throw another exception since the channel is faulted....

So for WCF clients, the recommended best practice is something like this:

YourClientProxy proxy = new YourClientProxy();

try
{
   ... use it

   proxy.Close();
}
catch(TimeoutException exception)
{
   proxy.Abort();
}
catch(CommunicationException exception)
{
   proxy.Abort();
}

Marc

The stack trace shows that the client-side WCF channel stack failed when trying to derive from the service URL the actual name of the named pipe being used by the service. The service publishes the pipe name (which is a GUID which changes each time the service restarts) by placing a small structure in a named shared memory section which contains the GUID as one of its fields. The name used for the shared memory section is derived from the service URL by applying an algorithm which is compiled into both the server-side and client-side WCF code for the NetNamedPipeBinding.

The exception reported in the question really means that having applied the algorithm to the service URL to come up with a name, the client side code could not open a handle to a shared memory section of that name. This may mean, as the exception message states, that there is no service listening on the service URL used to derive the name. But it can instead mean that the memory section is there, and so is the service, but the client-side code is not running in a security context which allows it to access the shared memory.

On Windows platforms prior to Vista it is fairly unlikely that a WCF client would ever lack the security permissions to open the shared memory, read the pipe name GUID from it, and then successfully connect to the service's pipe. But on Vista and later platforms there are new security mechanisms which make this a much more common failure scenario.

Vista introduced a concept of different namespaces for named kernel objects: there is a Global (machine-wide) namespace, and a Private namespace for each logon session. The NetNamedPipeBinding client code will try both namespaces when looking for the shared memory section which advertises the pipe name. If the server has created the shared memory using a Global name, or if the service and the client are running in the same logon session, then the client will find what it is looking for. If, though, the service cannot create an object in the Global namespace (it always tries to do this first) then it will fall back to creating it the private session namespace, and then only clients running in the same session will be able to see it. Creating Global namespace kernel objects requires a special privilege in Vista and later platforms, which typically only Windows Service processes and applications running "As Administrator" will have. A common pitfall is to try to create a client in a Windows Service attempting to connect to a WCF NetNamedPipe service hosted in an application running in the interactive user session.

The Vista Mandatory Integrity Mechanism can also prevent a putative client connecting to a WCF NetNamedPipeBinding service, if the client code is running in a lower integrity context (e.g. a browser plug-in) than the code hosting the service.

I would imagine that the symptoms reported in the question, with test clients working but real clients not working, are almost certainly caused by the security context of the real clients being inconsistent with that of the service host, for one or other of these reasons.