I've been developing with Visual Studio on a Windows 10 PC for the last year. I have a ASP.NET web application and a SQL Server 2014 database installed on the same computer.

enter image description here

I've got the site running in IIS while I'm working on it:

enter image description here

I also have a connection string with integrated security:

<add name="WebsiteEntities" connectionString="metadata=res://*/websiteModel.csdl|res://*/websiteModel.ssdl|res://*/websiteModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=.;initial catalog=website;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" />

I connect to the sql database using my regular windows account. There is no active directory or domain on the network or anything:

enter image description here enter image description here

This all started to break yesterday afternoon. Suddenly I started getting a error 503 when attempting to access the website on IIS:

enter image description here

Inspecting the application pool in IIS, I noticed that it's not started:

enter image description here

Whenever I access any of the web applications attached to this application pool, the pool immediately crashes (I say crashes, but it just stops running).

I make sure it's running:

enter image description here

Then accessing the website gives me the 503 and the application pool is stopped.

Over the last hours, nothing I've tried enables the application pool to keep running. There is nothing to debug in the application in Visual Studio, because it never starts there. The crash does not generate any logs in inetpub. I've tried to change my windows account password and updating this in the application pool, but I still get the same issue.

enter image description here

How can I effectively debug the app pool in order to figure out why it keeps crashing?

  • @PimpJuiceIT - thanks for looking it up for me. The app uses .NET 4 and the app pool in IIS is set to use .NET 4.0. I will see if I can find the relevant event viewer logs
    – Carel
    Apr 25, 2018 at 13:52
  • @PimpJuiceIT - I've restarted a few times throughout today while working with this issue. Could not find anything in the event viewer application logs. I cleared the logs and tried starting + accessing the app pool a few times. This did not generate any logs
    – Carel
    Apr 25, 2018 at 14:00
  • Last but not least for now if you can, run Wireshark on a TCP/IP sniff of equivalence on the machine and make the problem happen then see if the packets of relevance indicate anything potentially. Apr 25, 2018 at 14:23
  • found a log that looks very promising: The identity of application pool WindowsAuth is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. [1/2]
    – Carel
    Apr 26, 2018 at 7:29
  • If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number. [2/2]
    – Carel
    Apr 26, 2018 at 7:29

1 Answer 1


Debug Steps

  • Restart the computer if you've not already in case there is a pending update, fragmented memory, etc. just to rule out common issues a simple power cycle eliminates.

  • Check the Event Viewer logs for both Application and System logs for anything relevant to this issue to see if there's something in there are indicates what the issue may be.

  • Turn on debug logging to the screen in the config file, restart the app pool, and then try again to see if it displays anything to the screen you may see before the app pool stops.

  • Turn on more advanced or verbose IIS logging to see if that shows anything relevant.

  • Set the top/main site to .NET 4.0 or the higher .NET and then set the sites/apps beneath to be the 2.0 or lower framework explicitly. Doing with the higher .NET Framework version and lower implicitly can cause problems like this

    • If this web app is within "a main/the default" site of IIS (like a subfolder in the hierarchical IIS structure) see what the top or main site is set to use .NET version wise. If the top level is set to 2.0 or something less than the .NET Framework this app uses, then this could crash the app pool potentially.
  • Create a new app pool with applicable settings and then set the app to use it and see if that makes any difference.

  • Run a Wireshark or a TCP/IP sniff of equivalence on the machine see if there are any packets of relevance indicating what the issue may be.

Further Resources

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .