locked
Random 500s / timeouts - New issue in the last month RRS feed

  • Question

  • User-895148684 posted

    I have an older Web Forms site with SQL Express on the same VM (Server 2016) which was working very well for many months leading into December. Over the holidays something changed and now I get occasional non-response hangs to a GET or POST for an .aspx page. I see this issue on two similar but separate VMs. Logs show a HTTP 500, win32-status of 64 with time-taken of ~120s. SQL Server checks show no issues. I can remote in during a non-response and see very low CPU use. After a few minutes it seems to recover. I've scanned with the MRT. There were some Windows server updates over the holiday break to both servers, and that is the only thing that I can think of that was changed on either one. I cannot replicate it in a local dev environment.

    The fact that both instances of the same VM setup suffer the same problem, and neither were altered other than Windows Updates, seems very significant. I'm considering uninstalling those updates, but not keen on losing the security fixes they include.

    Any suggestions on where to look most appreciated!

    Monday, January 18, 2021 3:27 PM

All replies

  • User1120430333 posted

    The 500 usual means an exception was thrown that was unhandled. You need to implement some kind of global exception handling to catch all error, particularly all unhandled exceptions, logging the exception message, stack trace and inner exception message if not null in an attempt to discover the exception to a log file using Log4Net or some other logging framework.

    How to Catch All Exceptions in C# & Find All Application Errors – Stackify

    Tuesday, January 19, 2021 6:13 AM
  • User-895148684 posted

    Thanks, DA924. Good advice. I spent some time filling in some gaps in our use of log4net, but found nothing through additional error handling in our code.

    However close inspection of the server logs showed that the problems are linked to sc-win32-status values of:

    • 64: The specified network name is no longer available. or,
    • 995: The I/O operation has been aborted because of either a thread exit or an application request.

    Apparently these are quite hard to troubleshoot with https connections, but from my limited reading something like an ACK is getting dropped so a transmission is occasionally not closed properly. The interesting thing is that I only get them over my home fiber service (either Wifi or Cat 5) but not when tethered via WiFi to my mobile. No VPN involved.

    So my question now is: Is there anything about a WebForms site that would make it more susceptible to network disruptions than other web pages? I'm wondering if there is simply much more back & forth making for more opportunity for (sensitivity to?) disruption? 

    Sunday, January 24, 2021 1:09 AM
  • User409696431 posted

    "So my question now is: Is there anything about a WebForms site that would make it more susceptible to network disruptions than other web pages? I'm wondering if there is simply much more back & forth making for more opportunity for (sensitivity to?) disruption? "

    No.  The server prepares the HTML page, and sends it down the wire.  Posting sends data up the wire.  The same would happen with an HTML only site, a PHP site, etc., assuming the same functionality.

    Is there something about your site itself?  Sending way too much data up and down the wire (are your pages slow, using too much viewstate)?  Does it happen to other users, or just to you over your home fiber service?  That it doesn't happen over your wifi/mobile makes me suspicious of your home fiber connection.

    Tuesday, January 26, 2021 9:59 AM