What might cause a WCF NamedPipe Channel to become faulted (at the server end?)

Question

I apologise if this seems a little basic, but I'm new to WCF - and also to interprocess communication in general.

Details of my Setup

I'm using a NetNamedPipeBinding in my WCF "server", which is part of an application that runs as a windows service.

I have two clients that communicate with the WCF server, using a channel created by a DuplexChannelFactory. One is an ASP.Net MVC 3 web application, which creates a channel (and then closes it**) with each page request. The other is a WPF application (used as a sort of monitoring console / diagnostic tool for the service).

Everything runs along fine - often for a week or more - with lots of people accessing the web application, but just occasionally something breaks inside the WCF "server" and the clients begin reporting an exception "The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in a Faulted state" whenever they try to create a channel proxy.

Once the server "faults", every attempt to connect results in that error. Even new instances of the console application will report it. This leads me to believe it's not an issue at the "client" end.

** NOTE: I think the channel is closed with each page request. It is instantiated as a member of the MVC controller, which to my knowledge falls out of scope and is disposed at the end of the request. Perhaps I'm wrong?

The Question(s):

Does anyone have any suggestions on where to look - and even how I might be able to reproduce this issue in my test environment.

Can this sort of thing be eliminated entirely? Or should I resort to having a thread inside the "server" which attempts to connect to the named pipe service every few minutes and restart the service if it fails?

Addtional Information

It may be helpful to include the code that I'm using (in the WCF "Server") to listen to requests on the Named Pipe

host = new ServiceHost(
    this,
    new Uri[] {
        new Uri("net.pipe://localhost")
    }
);
host.AddServiceEndpoint(
    typeof(IStationDirectory),
    new NetNamedPipeBinding(),
    "StationDirectory"
);

host.Open();

/* Some logging code here */


Thread.Sleep(Timeout.Infinite);

More Questions

Assuming I understand correctly each NamedPipe "Channel" is effectively the same thing as a TCP connection (unique to each client/server pair). If I keep seeing the channel faulted error with new clients, then presumably every new channel that is being created by clients is somehow broken from the start. Does this mean that the failure is somewhere inside the ServiceHost? Would there be any benefit in catching host.Faulted events here?

Update on Resolution (2013)

I know it's been a very long time since I asked this question - but I just noticed it in my history here on SO and I thought I should add that Nick had hit the nail on the head. I believe it was the message payload size that was causing the problem. Included in the messages were a list of "report" objects, that each linked to the previous report. Over time this list would grow. Pruning off the old reports and keeping the WCF messages at a more-or-less fixed size stopped the faults. The application has been running very reliably for the last couple of years.

Answer 1

I'd start by doing some WCF tracing.

http://msdn.microsoft.com/en-us/library/ms733025.aspx

If they're faulting with absolutely no events logged anywhere you can see (in Event Viewer) then it's probably either

1. Message payload is too big for your binding. If you're returning large result sets, and it's intermittent, I'd start here. Check your maxItemsInObjectGraph binding configuration as well.
2. Unhandled exceptions on the service start. That doesn't seem to be your problem.