WCF activation error on IIS 7 RRS feed

  • Question

  • Hi

    I keep seeing this error on few of our environments:

    System.ServiceModel.ServiceActivationException: Request to the service at '~/TmpServ.svc' cannot be dispatched because the virtual application at '/TmpServ' is shutting down.

    --- End of inner exception stack trace --- at System.ServiceModel.ServiceHostingEnvironment.HostingManager.FailActivationIfRecyling(String normalizedVirtualPath) at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity) at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath, EventTraceActivity eventTraceActivity)

    We are using IIS 7; the load on the Web server is low, but the error still appears a few times a day.

    The IIS settings are all the default ones except:

    Idle time-out - 2 hours (the error appears much more frequently than this timespan)

    Any suggestions would be appreciated. 

    PS I was redirected to this forum from the IIS one, basically I don't know why the application pool is being recycled when (as it seems) it shouldn't to. 

    Monday, March 9, 2015 6:17 PM


All replies

  • Is this error message coming from WCF or IIS in some form? Have you looked in the IIS logs or the Event log for further error messages?
    Monday, March 9, 2015 8:54 PM
  • This error is taken from the Windows Event Log, same response gets the client application when calling the service. I can see no other related error messages (all options for Generate Recycle Event Log Entry are on). 
    Monday, March 9, 2015 11:20 PM
  • Hi,

    For this scenario, in IIS, you could increase Process Model / Idle Time-out or set Idle Time-out Action to Suspend. Set Recycling / Regular Time Interval (minutes) to 0.


    Tuesday, March 10, 2015 5:53 AM
  • Maybe, you need to do a try/catch on the service side and dump it to a log, because WCF swallows the real exception and throws out a catch 22 generic exception that hides the true exception. 
    Wednesday, March 11, 2015 2:55 AM
  • There is a global exception handling and corresponding logic for its processing on the WCF side, otherwise the client wouldn't receive the real exception.

    And any way, the error description says the service is shutting down, so at least from this description I believe the request doesn't even get to the WCF endpoint. 

    Adding WCF tracing is the only idea I have at the moment (although I think there could be also issues in the code itself - e.g. memory issues)

    • Edited by aly13 Wednesday, March 11, 2015 11:28 PM
    Wednesday, March 11, 2015 11:28 PM
  • There is a global exception handling and corresponding logic for its processing on the WCF side, otherwise the client wouldn't receive the real exception.

    The bottom line is this. I don't think you are getting the real exception that was thrown out from the WCF service. You got some kind of a catch 22 excpetion that was thrown back to the client. The real exception was swallowed by the WCF servcie that may be due to there is no viable exception handling on the WCF service side to catch and log the excpetion. The WCF service is most likely blowning up, you don't know what the excpetion is other than the service throwing something about it's sutting down.

    It is what it is for you until you come to the conclusion that you are not getting the real exception.

    Thursday, March 12, 2015 2:49 PM
  • I have the global exception handling on the WCF side, something similar to this implementation:


    I obviously log the original exception on the service itself and also on the client, I can add additionally that I receive exceptions like 'Object reference...' etc error on the client side. 

    Thursday, March 12, 2015 8:42 PM
  • http://www.remondo.net/wcf-global-exception-handling-attribute-and-ierrorhandler/

    I looked at the link. To be honest, I wouldn't put all my eggs in that basket.  Myself, I wouldn't use it at all -- that's just me. I would much rather go to the Service.cs and put try/catch and logging in the methods that the Service.cs is calling.

    • Marked as answer by Shawn Zhao Friday, March 20, 2015 1:45 AM
    Friday, March 13, 2015 3:47 PM