We are excited to announce that the IIS.NET Forums are moving to the new Microsoft Q&A experience. Learn more >

ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace LogRSS

8 replies

Last post Jan 26, 2018 10:42 AM by sortitout

  • ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Mar 05, 2009 05:21 PM|dlevine|LINK

    We had migrated a calssic ASP application from IIS 5.0 to IIS 7.0 a little while back. As time goes on, I am seeing greater system utilization as a whole on the IIS 7 box than we ever really did on the IIS 5 box. I also have ASP error being logged to the Windows Event log, and have been noticing a fair number or errors on a regular basis - on top of which, every now and again we will start to get strange random errors from ASP pages... like DB connections failing for no apparent reason, etc. 

    So, I am starting to take a close look at all of this to try and determine root causes.

    I have enabled Failed Request Trace Logging, and have been reviewing these logs all day today. One thing I am seeing quite a bit of is :

    ASP_CLIENT_DICONNECTED
    ASP_LOG_ERROR   LineNumber="", ErrorCode="ASP 0147", Description="500 Server Error"

    This seems to happen for random ASP pages with random querystrings... I am not able to see any patterns to it...

    Anyway, I have not found too much information on this error and how to properly interperet it. TechNet says: "The client disconnected while the request was on the ASP queue." which is great, but not all that verbose. 

    What could cause clients to disconnect so frequently in this manner? Networking in general seems to be fine on the server - NIC / drivers / cables / switch, etc. all seem good.

    If anyone has any advice or experiences I would greatly appreciate it...

     D

    ASP Classic ASP classic 500 error IIS7 classic asp 500 error ASP

  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Mar 05, 2009 10:01 PM|steve schofield|LINK

    Sounds like a random application pool recycle issue.  I'd adjust the app pool settings and see if you can determine the pattern.  

    http://blogs.iis.net/ganekar/archive/2008/12/12/iis-7-0-application-pool-recycles-log-a-event-in-windows-event-log.aspx

    Steve Schofield
    Windows Server MVP - IIS
    http://iislogs.com/steveschofield
    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget

  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Mar 05, 2009 10:39 PM|dlevine|LINK

    Thanks for the reply Steve.

    I have been keeping a pretty close eye on our logs and everything the past little while  - and especially the past day or so since enabline freb - and I have not notived that many application pool / worker process recycles. I mean, I did see maybe two of them today, but the ASP_CLIENT_DISCONNECT has been happening on a more frequent basis for sure.

    However... I am curious what types of settings I might look at for tuning the Application Pool...? Should I set some limits (CPU/RAM) limits on it, or schedule more frequent recycles, or...?

    Best

    D

  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Mar 09, 2009 11:56 AM|piekarski|LINK

    i recently upgraded to iis 7 from iis 6 running in iis 5 mode. high volume, 94 sites, sqlserver2005 backend. In iis 6 every few days the server would start blowing an ssl security error, error code was related to db even though we dont use ssl for db connectivity. had to restart iis and everything was fine. now im on iis 7 with 3 identical servers load balanced by a server iron appliance. not one failure in 4 weeks even when i just leave one server on, but, we get this exact symptom. more of an annoyance really, as it is only affecting a few users. im guessing they get our friendly error page once or twice and then keep going. of course im sure it chases some people away. whenever it happens there is almost always yahoo ad crawler on there but that might not be the cause. it just might reflect the fact that crawler is there a lot. also  i just reproduced the scenario by manually recycling the pool.  when it happens by itself though, there is no logging of an app pool recycle even though i have all app pool logging on. i think this all points to a memory leak, unfortunately we a have a lot of asp pages. i have also tried different application pool configurations, one pool per site, various settings. the fact that we use sessions makes recycling a poor option. Sorry about the verbosity of this post, a lot of info, no solution.

  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Mar 12, 2009 01:10 PM|dlevine|LINK

     Interesting... thanks for the post...

     I am continuing to monitor our werb server for these asp_client_disconnected errors. I am trying to find additional ways to gain insight into what is actually happening with limited success...

    Aside from looking at the FREB logs, I am looking at permon counter data for Active Server Pages\Requests Disconnected. I am not sure if this is something completely different though. Our server is not accessed by nearly the number of concurrent users as yours is though. For example, looking at perfmon, right now I can see we have:

    Active Server Pages
       Request Execution Time: 1,500ms (just a sample of what was up right now)
       Requests Disconnected:  333
       Requests Queued:           0
       Sessions Current:            293

    W3SVC_W3WP
       Active Requests:             4 (total)

    Web Service
       Current Anonymous Users: 4 (total)

    This is a Windows 2008 SP1 system with Xeon 3GHz and 2GB RAM (1.70 used on average)

    I am a little uncomfortable with the RAM usage (need 4GB maybe, but its only a 32 bit OS). I am also interested in the number of current sessions... seems a little high, but I am not sure if or how this may effect me...

    Anyway, just spouting off... for now...

  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Nov 04, 2011 11:34 AM|PConlan|LINK

    We get this error as well.  For us is happens when a user's request gets queued behind another long running request.  When we look at the Failed Request Tracing logs for these errors, the event immediately before the error is always ASP_DEQUEUE_REQUEST, and the elapsed time is always multiple seconds.  If the queued user gets impatient and either closes the browser, hits refresh, or anything like that, his connection gets closed.  However, the request is still sitting in the queue.  When ASP finally gets around to processing the request, the first thing it does is check to see if the client is still connected (no reason to process it if the client is gone).  If the client has disconnected, this error is thrown and the request is not processed.    We try our best to not have long running pages, but due to the nature of our app, it is unavoidable.    I will probably open a case to see if we can tell ASP/IIS to stop reporting this as a 500 error.
  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Nov 04, 2011 12:14 PM|dlevine|LINK

     Thanks for the response... This is what we found as well. There was/is some functionality in our web site that would create some long running requests essentially mucking up the works...

    To work around the issue, we ended up breaking out some of this functionality and placing it into independent application pools. 

  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Oct 31, 2017 05:27 PM|Tappy|LINK

    Did you get a solution for this? We are facing the exact same issue on IIS 7.5. Would appreciate any pointers.

  • Re: ASP Error Code 0147 & ASP_CLIENT_DISCONNECTED in IIS7 Trace Log

    Jan 26, 2018 10:42 AM|sortitout|LINK

    We are also having similar issues. Classic ASP site was running fine on a server 2008 iis6.0 install. Moved to server 2012 iis8.5 and now website keeps crashing every so often. We have to restart the instance to get the website back up but cannot find a common cause. Very annoying and cannot find any answers anywhere and log files not that helpful. If we cannot get this fixed we will end up migrating the application to LAMP which we'd rather not have to do. Any further pointers appreciated.