When a .NET Core Azure App Service won’t start: 502.5 Process Failure

In the process of testing Retrace with .NET Core I decided to use the example MusicStore app as a test application. Pulling down the source from GitHub and deploying it to Azure App Services is easy right? Correct, and totally wrong both as it turns out. After hours of headaches… I figured I needed to share how I finally solved my issue with the dreaded HTTP Error 502.5 – Process Failure.

So what exactly was my problem?

I deployed my app as an Azure App Service targeting the full .NET framework and immediately got hit with this error:

HTTP Error 502.5 – Process Failure

At first glance this error pretty much doesn’t make any sense. Why in the world would my web app not start up? I tested it locally and it worked perfectly. I deploy to Azure and I get a bizarre “HTTP Error 502.5 – Process Failure” error.

OK, so I decided to switch my target framework from full framework .NET 451 to netcoreapp. Now I get this instead…

At this point I started wonder if Azure doesn’t support the version of .NET Core I am using, or if I need to upgrade to 1.0.1 or something. I tried changing all my dependencies around and lots of other things. Nothing worked.

Let’s stop and remember how .NET Core works

It is important to remember that .NET Core works completely differently than previous versions of .NET. Normally we expect that if IIS is running, our app will work, or at least try to work and throw a 500 error, weird config error messages, or something.

.NET Core doesn’t work like that. We are still using IIS, but it starts our application up as a child process that is running Kestrel. IIS is now a reverse proxy and it tries to ensure our app is running.

It looks at our web.config which now just tells it how to start our app. It also uses a special AspNetCoreModule to pass the traffic through. Your web.config looks something like this:

<system.webServer>
	<handlers>
		<add name=”aspNetCore” path=”*” verb=”*” modules=”AspNetCoreModule” resourceType=”Unspecified” />
	</handlers>
	<aspNetCore processPath=”%LAUNCHER_PATH%” arguments=”%LAUNCHER_ARGS%” stdoutLogEnabled=”false” 
	    stdoutLogFile=”.\logs\stdout” forwardWindowsAuthToken=”false” />
</system.webServer>

So when IIS tries to start your app as a child process and it throws an error… your app literally is not running. That is what is happening on Azure and the 502.5 Process Failure app is absolutely correct.

OK, So how do we figure out why my app will not start?

This is what took me forever to figure out because Azure doesn’t tell you anything and you have no idea where to start even troubleshooting. The answer is actually really simple once you find the config setting needle in the haystack. In the example web.config above I posted what the default config is. What you need to do is enable “stdoutLogEnabled” so it will essentially log to a text file what is being displayed in the console window.

BTW, the default path for stdoutLogFile is “.\logs\stdout”, but when I did my deployment to Azure, the publish process changed it to “\\?\%home%\LogFiles\stdout” which does work in Azure and maps to D:\Home\LogFiles.

So all you need to do is redeploy your app with stdoutLogEnabled=true or go edit it your web.config via KUDU and restart your app. Then you will see files created in KUDU and this will help you find any exceptions that may be happening when the app starts up. For me, It ended up being a bad database connection string. 🙁

Good luck and I hope this helps save some people from the headaches I had trying to figure this out! I wish Azure somehow automatically collected part of stdout much like it does for WebJob logs. Also check out this blog post: Where to Find Azure App Service Logs for your App, IIS, FRT, etc

Author

mwatson

More articles by mwatson