This article is going to help you to figure out why your ASP.NET Core is throwing 500.30 – ANCM error for an application hosted in Azure App Service. I’m not going to explain the cause of the issue, because as you’ll see later, it is not possible. But I will guide you so you can find out by yourself.
First of all, let’s start with why and when you get 500.30 - ANCM In-Process Start Failure error.
Every ASP.NET Core application has a Program.cs file which contains the default code
public static IWebHostBuilder CreateWebHostBuilder(string args) => WebHost.CreateDefaultBuilder(args) .UseStartup<startup>();
The above is the part of the code where you configure what is happening when your application starts up. Usually, you would add code for your app configuration, like logging, Azure Key Vault, EF Core tooling, etc. This is the part of the code where you get 500.30 error. The error could happen because of a multitude of events. You may get the error without changing this code at all and it could be because of the server configuration where you host your application.
Next step, let’s see how we can figure out the cause of the exception. One way of doing this is to add logging. You’ve likely taken care of the logging already, but you can’t see any logs yet. The reason for that is because the error happens before the code gets to the logging configuration. In this case, we need to rely on the Azure logging. Open your Azure app service application and open Kudu Services by click on the Advanced Tools in App Service Development Tools. In Kudu, navigate to the location of your deployment web site. Usually, that will be home\site\wwwroot
There you find web.config file.
NOTE: if you can’t save the web.config file after you edit, please look at the end of the article on how to deal with that.
You may need to restart your App Service after updating web.confg file.
Below is a typical example of a web.config file
<configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\MyRestApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" /> </system.webServer> </location> </configuration>
You need to enable logging by changing logging to true
I find that in some cases that will not work so you can update it to the home directory, like
That should be enough to get you some logs, but if this step didn’t help, please read on.
We can improve the logging by providing ASP.NET Core handlers. Add the following inside the aspNetCore tag
<handlerSettings> <handlerSetting name="debugLevel" value="file"/> <handlerSetting name="debugFile" value="d:\home\logs\ancm.log"/> </handlerSettings>
The entire web.confg will look like this
<configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\MyRestApp.dll" stdoutLogEnabled="true" stdoutLogFile="d:\home\logs\stdout" hostingModel="InProcess"> <handlerSettings> <handlerSetting name="debugLevel" value="file"/> <handlerSetting name="debugFile" value="d:\home\logs\ancm.log"/> </handlerSettings> </aspNetCore> </system.webServer> </location> </configuration>
Armed with the log file, you should be able to find more details about the error.
It may happen that you are not able to save web.config file after you edit it. One reason for that is if you use the Azure DevOps Release pipeline, you have the Deployment method set as Run From Package. This Deployment method is the default configuration at the time of this article.
One solution is to change it to Web Deploy or Zip Deploy. You can change it back later after you identify your issue.
Another solution is to check your Azure App Service Configuration Settings. You should have WEBSITE_RUN_FROM_PACKAGE which has value 1. Change that to 0 and try again.