Output session autoclose error message ??? whats that RRS feed

  • Question


    dear all,


    I have a set of service running under IIS as WAS.

    After a certain time I get an error on my service as follow :


    "This chanel can no longer be used to send message as the output session was auto-closes due to a service-initiated shutdow.Either disable auto-close by setting the DispatchRuntime.AutomaticinputSessionShutdown to false or consider modifying the shutdown protocol with the remote server"


    What that all about, where are thsoe settings ?


    In addition from the client side I receive a cascade of error as follow :


    1 - Unable to decrypt or encrypted data block. Please verify that the encryption algorithm and keys by sender and receiver match.


    2- The request for security token has invalid or malform elements.


    my client is runing under XP and my service are runing under a remote vista machine


    Does those 3 errors are linked ?


    Note that I am using TCP binding with following settings :


    Code Snippet


    <binding name="netTcpBinding_Secure"











    enabled="false" />

    <security mode="Transport">




    <message clientCredentialType="Windows"/>






    What is going on ?


    thnaks for your help¨



    Thursday, January 31, 2008 10:59 AM

All replies

  • Read up on AutomaticInputSessionShutdown here. This should explain the feature. If you have any further questions about the msdn description, feel free to ask.


    It is possible those 3 errors may be linked. Are you using the same binding on both client and server? Can you post the full exception (type, message, and callstack)?

    Tuesday, February 19, 2008 5:34 PM
  • What is strange is that when I get this error message, I have no idea what does it comes then if it close the session by itself, I should be able to reconect normally...:-(?

    But when a client try to reconnect then this erro raise, in similar way as chanel is faulty in  away..


    How to handle this then in real life ?




    Wednesday, February 20, 2008 8:13 PM
  • Please copy and paste the exception you are seeing into this forum. Can you also show us your contract. Does it have any methods marked IsTerminating?


    How are you trying to reconnect? You should be aborting your old proxy, creating another one and using the newly created one.

    Thursday, February 28, 2008 12:58 AM
  • I have no contract with method marked IsTermnating

    When I try to reconnect I am closing the old proxy and create a new one all the time but no help...


    I have turn on Tracng on my server side but all what it returns is pur chineese for me and If I open it with the tracing tool, I can sse on it only information, but no information on the exeption.. :-(


    How can I post here the tracing file, if you could help me to dig it?


    Saturday, March 1, 2008 11:22 AM
  • Hello margaret,


    I am still facing the same issue and error message from this initial post.

    So far not able to catch the exception properly but I have activated the log on all my WCF service.

    Should I normally see this exception in my service log file using the Trace Viewer tool ?


    In which form can I filter exception in those huge log file, becasue so far I can only see Infomeation status as the Level..


    Thnaks for your help dig in out that trouble.

    I need to point out at least which of my service is causing this r if it comes from my client application....


    by the way I did not catch the use of this autoclosee in MSDN, what was the reason of this ?



    Tuesday, March 4, 2008 8:16 AM
  • I have cross check the link explaining this autoclose session and I point to this :


    By default when a client closes an output session and the service has finished processing any remaining messages the server closes the session. Setting AutomaticInputSessionShutdown to false prevents the server from automatically closing the session and enables custom control of session lifetimes.


    What does it means that a client close an output session ?


    The way I am doing is that the client application in m y case is a simple WinForm application which used my service as follow:


    First of all my Client application is listen on callback event from my services:


    Code Snippet

    public void NewAlarm(System.Object[] args)


    SendOrPostCallback callback = delegate(object state)

    { this.RefreshRequested((DataSet) args[1]); };

    m_syncContext.Post(callback, null);




    From the code below when my service has finished to process an alrm object it raise a callback through a callback interface. Then the call back information is pass to the main UI thread


    Then the RefreshRequested method is call and process following code :

    Code Snippet

    private void RefreshRequested(DataSet ds)





    AlarmClientHistory = new WcfProxies.Alarm.AlarmClientHistory(ad2);

    m_Active = AlarmClientHistory.ReadActive();


    if (m_Active.Tables.Count != 0)


    //all active alarms

    dv.Table = m_Active.Tables[0];

    dvOff.Table = m_Active.Tables[0];

    dv.RowFilter = "OffStatus='False'";

    dataGridView8.DataSource = dv;






    catch (TimeoutException timeout)


    //MessageBox.Show(timeout.Message, "Operation time out from service: " + AlarmClientHistory.Endpoint.ListenUri.ToString());

    label24.Text = timeout.Message;



    catch (FaultException<Maillefer.Nomos.Types.Common.Error> Error)


    string msg = Error.Detail.Message;

    //MessageBox.Show(msg, "Service Error: " + AlarmClientHistory.Endpoint.ListenUri.ToString());

    label24.Text = msg;



    catch (FaultException unknown)


    //MessageBox.Show(unknown.Message, "Unknown fault from service: " + AlarmClientHistory.Endpoint.ListenUri.ToString());

    label24.Text = unknown.Message;



    catch (CommunicationException comm)


    //MessageBox.Show(comm.Message, "Communication fault from service: " + AlarmClientHistory.Endpoint.ListenUri.ToString());

    label24.Text = comm.Message;






    As you can see from code above, I ma creating a new service instance each time I need a request from my service and then Close the instance when I have finish.


    So is tehre a place in my code here that could close the output session ? I do not see any ...

    Or dos this outpout session closeing is a timeout parameter fro the session inside config file that I need to change ?

    Once again I ma using tcp binding (as seen in first message ) and my sercvice si host under IIS as WAS


    thnaks for your information...I am tuck here for weeks






    Tuesday, March 4, 2008 8:33 AM
  • Anyone coul help me solving this issue ? I fingthing for longtime with it and no idea where to dig it out.

    The error message occurs only when I get my client application running.. and after 2 or 3 hours of work then it stop working and error from initial message :


    "This chanel can no longer be used to send message as the output session was auto-closes due to a service-initiated shutdow.Either disable auto-close by setting the DispatchRuntime.AutomaticinputSessionShutdown to false or consider modifying the shutdown protocol with the remote server"




    My application and Services are using callback in OneWay mode

    I have no exception information from service side in logs :-(

    And the only exception information I get from the client application is messge above :-(


    Thnaks for give me tips...



    Wednesday, March 5, 2008 8:07 AM
  • Hi Serge,


    It sounds like your service channel (what I would call a stub) is closing itself even though you do not want it to. I was not familiar with the AutomaticInputSessionShutdown, but I suppose you could try setting that to false to see if that makes a difference. In fact, I might try that too.


    Apart ça, I have placed "Closed" and "Faulted" event handlers on all of my service instances. That way, if one of my channels closes without permission, I just open a fresh channel to take its place. Kind of messy, but it does seem to work because my services are always available (no thanks to WCF).


    As to the trace log, don't even waste your time. You will never find anything useful in there. See if you can catch the closed or faulted events and re-create the service, and I'd recommend logging those cases so that you know how often you are cycling your channels.




    Wednesday, March 5, 2008 3:30 PM
  • Thanks charles,

    I will give a try and let you know

    Thursday, March 6, 2008 7:47 AM
  • HI charles,


    I have tried catching Closed and Fault eventhandler of the channels.


    is it correct to do it as follow :


    This code is from my clinet WinForm application


    Code Snippet

    //Creating service instance

    AlarmClientHistory = new WcfProxies.Alarm.AlarmClientHistory(ad2);


    //register to eventhandler

    AlarmClientHistory.ChannelFactory.Closed +=new EventHandler(Alarm_Closed);

    AlarmClientHistory.ChannelFactory.Faulted +=new EventHandler(Alarm_Faulted);


    //Call service request



    //remove handler before closing the channel

    AlarmClientHistory.ChannelFactory.Closed -= new EventHandler(Alarm_Closed);

    AlarmClientHistory.ChannelFactory.Faulted -= new EventHandler(Alarm_Faulted);


    //Closing the chanel





    Then from my delagate methods I have

    Code Snippet

    private void Alarm_Faulted(object e, EventArgs args)


    AlarmClientHistory = new WcfProxies.Alarm.AlarmClientHistory(ad2);

    System.IO.StreamWriter str = new System.IO.StreamWriter("c:\\debug.txt", true);

    str.WriteLine("Alarm client recycled (Faulted)");






    So if I undertand corercetly trying to catch the fault state or close state is only whinin a request to the service

    So then if it happen I should resubmit the request somehow no ?


    If I do as above my client crash with erro message "cannot open dispose object"


    In all my client call, when I want a requet from the service I create new instance, call the service, and then close it when not needed anymore.


    is that correct or did I cacth something wrong ?


    By the way could not find any real info where and how to use this AutomaticInputSessionShutdown

    Config file ? inside each service ? Service contract attribute ?





    Thursday, March 6, 2008 2:07 PM
  • I have try an other way around by creating my services instance only once at form load.

    and then register to eventhandler as follow :


    On form load:

    AlarmClientHistory = new WcfProxies.Alarm.AlarmClientHistory(ad2);

    AlarmClientHistory.ChannelFactory.Closed += new EventHandler(Alarm_Closed);

    AlarmClientHistory.ChannelFactory.Faulted += new EventHandler(Alarm_Faulted);


    And then from the Delegate I do same as before, recreate the instance


    This is ok like this from my client application..but now what are the rules for creating instance when a service call an other service as follow :


    I have here for instance service Alarm which is a client of service Publisher :


    Code Snippet

    WcfProxies.Notification .PublisherClient m_Publisher = new WcfProxies.Notification .PublisherClient(m_instanceContext, "EndPoint_Publisher");

    m_Publisher.RaiseTrigger(TriggerType.NewReel, new object[] { dsReel });





    In the code just above, is there any rules on when to call the CLose method of a service istance ? becasue if it is close inside the service here then the client application will jump inside Chanel_Close delegate if we catch it ?


    thnaks for help

    Thursday, March 6, 2008 2:41 PM
  • Serge,


    You're on the right track (as far as kludges go). You are right that you need to do something else when it is time to intentionally close the service, because right now it will re-start itself. You can do one of two things:


    1) set an internal variable (like "bool closing;"), set it when you want to actually close the service and then check it in your event handler, or

    2) remove the event handlers before you explicitly close the service.


    Either way would be fine, but without looking at your entire code, I can't see which would be easier to implement. I haven't found out anything more about AutomaticinputSessionShutdown either.

    • Proposed as answer by JoJoJoJoJoJo Wednesday, January 18, 2012 3:38 PM
    Thursday, March 6, 2008 7:21 PM
  • Yep , this AutomaticinputSessionShutdown

    maybe again an unclear undocumented feature :-(


    I have implemented point 2 for eventhandler..


    By the way are you using VS2008 and frw 3.5 ib your daily work or did you remain on 2005 ? I was wondering if any improvement in WCF part under fwrk 3.5


    Let you know if I can catch something



    Thursday, March 6, 2008 7:53 PM
  • Using 2005 for the big project that I've been working on for a while now, but I've started using 2008 for new stuff. I don't have enough time on it yet to say if there's a difference in WCF.
    Thursday, March 6, 2008 8:07 PM
  • Hello,


    Here is some results of my test this morning based on trying to catch those faulted and closed chanel..

    I have intentionnly generate a time out issue on my client requet to my service in a way that the service is not able to answer to the client..Then client applciatin receive a time out error message back from the service. Then I resubmit the request and then I get a message back to the client daying that the channel is in fault state, so seems to be that when a channel goes to its fault state is not capable either to raise the faulted state event in ordeer to be catch from client side...


    So my Faulted channle event handler routine is never called.. :-(


    Souds messy in that sense if its teh case... :-(





    Friday, March 7, 2008 7:27 AM
  • Serge,

    Welcome to the wonderful world of WCF. Like I've been saying, exceptions crash channels and faults are only sometimes reported. If you really want a laugh, take a look at your trace log when that happens (hint: you won't learn anything).

    OK, enough bashing. Let's see if I can think of something useful. Hmm. OK, when you are causing the timeout, you are intentionally hanging the server function, correct? Then, if the server function does not answer in time, you get a timeout exception on the client. That seems like the faulted channel is on the client side, not the server side. That's why the next time you attempt an operation, you get the faulted message even though there is no fault on your server.

    I would recommend the same methodology on the client as you use on the server: catche the faulted and closed events and have the channel auto-re-created. It's a pain, but you may not have any choice (that's what we do). If you want to test the server side fault process, you should probably not try to time an operation out. I would say, just throw a good old exception inside the function call and watch what happens.
    Friday, March 7, 2008 11:17 AM
  • Hi charles, I am back with this stuff.

    So I have run my all testing environement during the week end with client application. and I get again after few hours the error message of this initial post "Output session close...."


    I guess that it comes somehow from the client application because, all my service are still running well and records data properly.

    Ok I thing is that my client is using callback with my services...thta might be the source of troubles but I do not see any reason why it should be...

    When they are talking about Output and Input channel, output means from client or server side ?


    What could make this closing stuff ?


    As explain earlier in my code sample, the way I am creating a proxy is that I ma always creating an instance and then imeediatly close it after I using it...





    Monday, March 10, 2008 7:47 AM
  • Hello,


    I get soem,thing new right now based on my test.


    So from my client application now I have created a single instance of my service at the form load as follow:


    AlarmClientHistory = new WcfProxies.Alarm.AlarmClientHistory("myServiceEndpoint");


    Then I am recording to file exception of type TimeOut, communication that I could get during processing my request in order to know if my chanel gets closed form one of thsoe exception.


    Then as you suggest I have register for the Faulted and Closed channel event handler.


    Based on that, when it fails, It jumps to the Closed handler routine as shown below :

    Code Snippet

    private void Alarm_Closed(object e, EventArgs args)


    AlarmClientHistory = new WcfProxies.Alarm.AlarmClientHistory("myServiceEndpoint");

    System.IO.StreamWriter str = new System.IO.StreamWriter("c:\\debug.txt", true);

    str.WriteLine(DateTime.Now.ToString() + "Alarm client recycled (Closed)");






    So as we suspected from the begining, ffrom no reason, the chanel get close. But what is strannge is that event if I am recreating the service instance in code above ( line in red), my channel is definitly dead nad I get this error from the begining mentionning about the AutomaticShurtdwon stuff.


    Did I recreta the chanel not correctly ?

    I guess that using

    AlarmClientHistory = new WcfProxies.Alarm.AlarmClientHistory("myServiceEndpoint");


    should recreate a new chanel on my service right ?


    Thnaks for comments



    Tuesday, March 11, 2008 1:51 PM
  • Serge,

    Sorry I didn't answer sooner -- I've had a busy day. It looks to me like your line of code to create the new channel should work fine. My only question would be about the original channel. I almost wonder if you should explicitly dispose of your old proxy, even though it is already closed.

    I've found this sort of strange behavior myself, and I had to go to great lengths to make sure my old channels were getting disposed before I was creating new ones. I also remember that sometimes the process of disposing of old channels took the full 30-second timeout period! This meant that my new channel wouldn't be ready until it was too late to answer the next client request. I'm afraid you may not have any recourse for this.

    Maybe WCF tries to recycle channels, and so it tries to re-use the original (closed) channel when you careate the new proxy. Without being able to look at WCF's source code, we are all in the dark, especially since Microsoft doesn't seem to be talking. I haven't seen them answer any of our threads satisfactorily, and I'm starting to get angry. We pay thousands of dollars for their development software and they can't even figure out how their own technology works.

    Let me know if you have any luck disposing of your old proxy before creating the new one.

    Tuesday, March 11, 2008 8:20 PM
  • hello,


    The thing that I have found around is that Dispose is roughly similar as a Close and it has some work to do in order to close the chanel in a properway.

    Then in many places it is mention for instance that as soon a chanel gets faulty or through an exception, then from the client application we should catch those exception and then use the Abort of the client instance.. Things what I do actually but no effect at all.


    Other test I have made is trying to host my service in a simple console in order to see if it was comming from the host in a way but no luck..


    Hmmm seems we are all stuck unless someone gets a new real idea.





    Monday, March 17, 2008 8:29 AM
  • Have you read the contents of the page at that link? It merely states that the "AutomaticInputSessionShutdown" exists and is an accessor in System.ServiceModel.Dispatcher.DispatchRuntime. Thanks. We know that.

    Serge's question, and mine, is "Where is that setting?" You can't instantiate a DispatchRuntime, and there are so many components involved that it's just about impossible to track down where the damn thing lives.

    Monday, December 19, 2011 3:20 PM
  • Exactly...here it is almost one year later from this last post and still there is no answer to where this damn thing lives. Every says read this page...but that page is just about worthless. It gives no usefull information on how to actually toggle this mysterious property. GRRRRRRRRRRRRR....
    Friday, October 12, 2012 11:10 PM
  • Try this code:

    ServiceHostBase host = new ServiceHost(typeof(<service_type>));
    foreach (ChannelDispatcher channelDipsatcher in host.ChannelDispatchers)
        foreach (EndpointDispatcher endpointDispatcher in channelDipsatcher.Endpoints)
            endpointDispatcher.DispatchRuntime.AutomaticInputSessionShutdown = false;

    Tuesday, October 23, 2012 11:53 AM