Why "using" may play tricks on your WCF service host

Many of the examples that have been published on the web about hosting the WCF use the "using" block to initialize the service. This blog entry shows you why this can catch you.

The problem arises when you try to open your host and there is a problem with the configuration file, if you were coding with “using” and you try to catch an exception you will find the familiar meaningless message:

“The communication object, System.ServiceModel.ServiceHost, cannot be used for communication because it is in the Faulted state.”

The next step is to go to the configuration file and play around with the parameters until you find which one is causing the hassle. You fix it and life goes on... but what does this message mean?

Well, during this process we were missing an important piece of information, if you check the Output window you will find that actually are two exceptions:


Indeed, if you remove your error trapping and run the code you will get the first exception, and guess what? It contains the useful information regarding the problem with the configuration file. But why you don’t catch it with your try/catch block? The problem is on the “using” block.

The using block is a try/finally implementation, this means that if an exception occurs it will execute the finally and then it will be thrown to the next exception block. Reading this you should think “aha! But why is not appearing on my exception control?”

The answer to this is the nature of the second exception, this one is not thrown because of your configuration file, it is thrown because the finally statement of the “using” block is failing. If we write the same code as the “using” you will see:

ServiceHost Host = null;




       Host = new ServiceHost(MySingletonService);







       if (Host != null)



The configuration exception is thrown by the “Host.Open()” line, the code jumps into the finally block and tries to dispose the host. Here the host is not null but it is in a faulty state, this means that it cannot be disposed and this raises the second exception that you usually see on your application.

Comments (12)

  1. MichaelGiagnocavo says:

    Yes, this silly design led to quite a few lost hours. Also, having a try/finally everywhere in your code is just a mess. Fortunately C# makes encapsulating patterns easy.

    We define a method like this:

    public static void UseServiceClient<T>(Action<T> action)

    Which internally does the try/finally. Then you can make all your service calls like this:

    UseServiceClient<ISomeService>(delegate(ISomeService client)




    In C# 3, the syntax will be even nicer. Anyways, more details here:


  2. Jochen Zeischka says:

    Great post!

  3. Steve says:

    Great post! Spent ages trying to figure out why I wsn’t getting any exceptions even though the service was failing. Thank you!

  4. Cordell Lawrence says:

    Fantastic post. I didn’t think that the exception would be lost like this… they couldn’t even put it in the inner exception? … again, thanks for the post.

  5. Jader Dias says:

    I wrote a variation of Michael code:

       public static class CommunicationObjectExtensions


           public static void Use<TCommunicationObject>(this TCommunicationObject communicationObject, Action<TCommunicationObject> action) where TCommunicationObject : ICommunicationObject













  6. Ondrej says:

    Wow, thanks.

    This post was useful for me.

  7. Jeno says:

    Great post! Thank you

  8. Fuimus says:

    Great post, many thanks

  9. Shouldn't a faulted ServiceHost still be disposable?  Is this a design flaw?

  10. Leos says:

    Thanks, it solved my problem! (hidden app.config error)

  11. Bill says:

    Thanks for the post. It was the first article I found on Google and probably saved me a ton of time debugging the issue.

  12. Jukka Aakula says:

    Thank you very much!

Skip to main content