When 500 Internal Server Error Shows up With Missing Logs in Event Viewer and IIS Logs.
When it comes to publishing Dotnet core APIs on IIS, 500 Internal server errors are a pain in all the wrong places.
What's most annoying about them is that most of the times, the IIS logs say nothing about what's wrong. And neither does the event viewer. In most cases these are not even logged on the event viewer. This is what makes internal server errors so difficult to debug.
Turns out that most of these can be debugged locally just fine and you can see the exact issue on the browser if you can manage to RDP into the server and hit the URL using localhost.
But there are many a times when running the application using localhost is not an option in production. Maybe because the application uses static routing. My blog for instance, always routes to a URL even if you access it using localhost.
In cases like these, you can 'temporarily' configure IIS to spit out the exact issue and even the stack trace rather than the generic "500 - Internal server error" page even when testing things remotely.
You do this by modifying the Error Pages for your website:
Once here you can pick the error code 500 and modify it's feature settings:
The default here is configured in a way where you can see the errors when testing locally but when you test remotely using a simple browser from a client you will get a generic 500 error page. But you can change this to always show the detailed error messages:
This should make the relevant changes to the underlying web.config and once you do this you should see the exact issue on the page even when you hit it remotely over a web URL instead of the typical 500 error page.
Once you debug the issue and fix it, you can revert the configuration back to "custom error pages" for a more secure experience but this should allow you to debug those pesky 500 internal server errors rather easily and quickly. Worth noting that this makes a change to web.config of your application so if you push the codebase again or overwrite that file you may have to make the same change all over again using IIS.
This configuration has always been around but most of us spend so much time looking at logs and fiddling around event viewer whenever these issues occur in production that sometimes we forget the obvious.
Hope this helps someone struggling with debugging their very own 500 Internal server error.
Comments are closed.