Issues with an App Pool - ERROR_NETNAME_DELETEDRSS

5 replies

Last post Mar 20, 2019 02:49 AM by lextm

  • Issues with an App Pool - ERROR_NETNAME_DELETED

    Mar 11, 2019 01:20 PM|JuanMdP|LINK

    Greetings,

    I'm not 100% sure this is performance related but the other subforums felt even less adequate. We have a site that is accessed both at an intranet and a remote level via a static IP. At certain intervals of days (sometimes it's less than 5, sometimes it's up to three weeks) the site just crashes and until the app pool is restarted, IIS just can't serve the page.

    Trying to isolate issues, we separated the app pools, so we left one for the intranet access and another for the remote one, the intranet never crashed again (we are talking about 6+ months without a crash) whereas the remote one still faces the same issue mentioned above.

    IIS list this at the end of the line where things start going awry: 500 0 64 7 , the error 64 means ERROR_NETNAME_DELETED but for the life of me I couldn't find what it really means and how to deal with it. Initially I thought this happened because of rapid fail protection but the executable set to run when it triggers never does, so now I'm unsure about that. That executable restarts that one app pool, if I run it manually then everything goes back to normal.

    So... in a nutshell, anyone has any idea of how to deal with this situation? Is it related to rapid fail protection or not? If it is, why isn't the executable running? If it isn't, is there any way to get a better description of the situation / error? Moreover, why would this happen only with the app pool that serves the site remotely when they are the same version of the site with the exact same files loaded for use?

    Any kind of help will be greatly appreciated.

  • Re: Issues with an App Pool - ERROR_NETNAME_DELETED

    Mar 11, 2019 06:24 PM|lextm|LINK

    JuanMdP

    IIS list this at the end of the line where things start going awry: 500 0 64 7 , the error 64 means ERROR_NETNAME_DELETED but for the life of me I couldn't find what it really means

    There is a boundary between IIS and your web app, and 500.0 ("500 0") in the log shows the problem is in your web app. 64, on the other hand, is a code recorded by IIS itself, which can be completely irrelevant to the true problem.

    Debug your web app please (whatever the web framework is, ASP.NET/PHP).

    Lex Li
    IIS Consulting Services at https://support.lextudio.com/services/consulting.html
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Re: Issues with an App Pool - ERROR_NETNAME_DELETED

    Mar 11, 2019 06:39 PM|JuanMdP|LINK

    lextm

    There is a boundary between IIS and your web app, and 500.0 ("500 0") in the log shows the problem is in your web app. 64, on the other hand, is a code recorded by IIS itself, which can be completely irrelevant to the true problem.

    Debug your web app please (whatever the web framework is, ASP.NET/PHP).

    If it would be that easy I wouldn't be here. I check the PHP errorlog religiously and there are no errors when the hiccups on that specific pool happen, sometimes there are weeks without errors while this happens in the middle. And furthermore, if it'd be strictly a web app error then both apps would fail yet only the remote access one does, as I mentioned, the one for intranet purposes has never failed even though they share the same code. The pages where the error happens also seem to be random, so there's no pattern to follow there either.

    Now, I'm not saying maybe there isn't something on my end too; but clearly it's a bit more complex than debugging without adequate information to point me in the right direction as to what to look for. I wouldn't dismiss the error 64 either since every single occurrence of the app pool dying was always with that specific error.


    Thus why I wound up here, to see what more information I can use in order to pinpoint this cryptic issue.

  • Re: Issues with an App Pool - ERROR_NETNAME_DELETED

    Mar 11, 2019 06:58 PM|lextm|LINK

    JuanMdP

    there are no errors when the hiccups on that specific pool happen, sometimes there are weeks without errors while this happens in the middle.

    Occasional issues won't be caught in this way. Your only hope is that failed request tracing might reveal more when the 500 error happens again, https://docs.microsoft.com/en-us/iis/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis

    But since you are using PHP, you do need some PHP way out there. BTW, do yo use FastCGI to run PHP on IIS?

    JuanMdP

    I wouldn't dismiss the error 64 either since every single occurrence of the app pool dying was always with that specific error.

    That's useless at this very moment, as 64 is not an error. Even 200 responses can have 64 in that field.

    Lex Li
    IIS Consulting Services at https://support.lextudio.com/services/consulting.html
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Re: Issues with an App Pool - ERROR_NETNAME_DELETED

    Mar 19, 2019 06:54 PM|JuanMdP|LINK

    It runs on FastCGI, yeah. I configured the tracing to only catch error 500s and today, when it happened again, I checked the logs. All I have is that rapid failure protection was fired. What bugs me is that I've an exec file configured to fire if rapid failure protection goes into effect yet it never runs. But the worst part is that:

    1. 1. This only happens with the remote app pool, otherwise it'd be easier to isolate.
    2. 2. There's nothing giving me any kind of pointer as to where to look.
  • Re: Issues with an App Pool - ERROR_NETNAME_DELETED

    Mar 20, 2019 02:49 AM|lextm|LINK

    Please open a support case via http://support.microsoft.com and share the log files with Microsoft support. Without analyzing them, the troubleshooting cannot move on.

    Lex Li
    IIS Consulting Services at https://support.lextudio.com/services/consulting.html
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.