Recently I experienced a situation where one of the apps I am working on stopped working.
There were no new deployments to the server, nor configuration or database-related changes.
When requesting the web site immediately receive – 500 internal server error.
OK, HTTP error code 500 means something’s wrong with the server:
“The server encountered an unexpected condition that prevented it from fulfilling the request.“
So I began to think of the possible reasons and started to check things on the server:
- Is the server started
- Are the IIS and all the needed app pools working properly
- Check the application logs
- Are there multiple servers, and if so:
- are all of them functioning correctly (IIS, firewall accesses, needed services, etc.)
- is the load balancer working properly – check its logs
- try to connect to every single server separately
- Check for expired certificates (this will generate a different error code as a response, but still it can lead to HTTP 500 with combination with other configurations, so it’s worth checking that)
- Check the application pool users – their password could be expired or their access rights modified
- Check for events logged in the Event Viewer (Windows users)
- Check the server logs
- For IIS (On Windows Server), the default/standard location of the log files is under %SystemDrive%\inetpub\logs\LogFiles (C:\inetpub\logs\LogFiles)
The problem and the according resolution could be in any of the above points.
But if your system infrastructure looks good, the system is working fine, you do not have application logs, and no useful information in the Event Viewer like it was in my case, then the key point was the last one in the list.
So I examined the IIS logs.
You can find the following information for every request:
- s-port cs-username
The red ones are important.
In my case this values were (sc-status: 500, sc-substatus: 19, sc-win32-status: 5).
You can find the statuses and corresponding sub-statuses meaning here:
And the information of the Win32 statuses can be found here:
My readings (respectively what helped me with the problem) were that there was “Access is denied.” error logged from IIS. So that means the Application Pool user doesn’t have access to the application folder. Which causes the termination of the request and the response with 500.