If you’ve encountered the 500.30 – ANCM In-Process Start Failure error when starting your ASP.NET Core application, you’re not alone. This issue can be frustrating because the application fails to start even though everything seems to be configured correctly.
In many cases, the root cause is that your ASP.NET Core application attempts to connect to SQL Server before the database service has fully initialized. This post explains why this happens and shows a simple, reliable solution using Windows service dependencies to ensure SQL Server starts before IIS.
Important Note: When Does This Problem Occur?
This issue typically only occurs when your ASP.NET Core web application and SQL Server are hosted on the same server.
If your application uses:
-
A separate database server
-
A cloud-managed database (Azure SQL, RDS, etc.)
then SQL Server is usually already running before the web application starts, and this problem is unlikely to happen.
This scenario is most common in:
-
Single-server deployments
-
On-premises IIS hosting
-
Development or staging environments
-
Servers where IIS and SQL Server start simultaneously during system boot
If both IIS and SQL Server are installed on the same machine, startup order becomes important—and that’s where the 500.30 error can appear.
The Cause of the 500.30 Error
The 500.30 error occurs when IIS starts your ASP.NET Core application, but SQL Server is not fully initialized yet.
At application startup, ASP.NET Core:
-
Loads configuration
-
Initializes services
-
Attempts to open a database connection
If SQL Server isn’t ready at that moment, the connection fails and the application crashes, resulting in a 500.30 error.
Interestingly, if you manually recycle the Application Pool or restart IIS after SQL Server is fully running, the application usually starts successfully. This confirms that the issue is related to service startup timing rather than application code.
However, relying on manual restarts is not a reliable or production-ready solution.
Solution: Configure Service Dependencies Using sc config
To permanently fix this issue, we need to ensure that IIS only starts after SQL Server is fully running.
In Windows, IIS is controlled by the World Wide Web Publishing Service (w3svc). By default, this service does not depend on SQL Server, which means it can start too early.
We can fix this by configuring w3svc to depend on:
-
HTTP
-
Windows Process Activation Service (WAS)
-
SQL Server (
MSSQLSERVER)
This ensures that IIS—and therefore your ASP.NET Core application—will not start until SQL Server is ready.
Steps to Configure Service Dependencies
1. Open Command Prompt as Administrator
-
Click Start
-
Type
cmd -
Right-click Command Prompt
-
Select Run as administrator
2. Configure the Dependency Using sc config
Run the following command:
Explanation:
-
w3svc– World Wide Web Publishing Service (IIS) -
http– HTTP Service -
was– Windows Process Activation Service -
mssqlserver– SQL Server (default instance)
⚠️ Important:
There must be a space after the = sign. Without it, the command will fail.
3. Restart the Services
After setting the dependency, restart the affected services:
Once restarted, Windows will enforce the correct startup order.
Why This Works
By defining service dependencies:
-
IIS will wait for SQL Server to be fully initialized
-
Your ASP.NET Core app will only start when its database is available
-
Startup race conditions are eliminated
As a result, your application no longer fails during startup, and the 500.30 error is resolved permanently.
Conclusion
The ASP.NET Core 500.30 error can be difficult to diagnose, especially when it only occurs after server restarts. When both IIS and SQL Server are hosted on the same machine, startup timing becomes critical.
By configuring service dependencies using the sc config command, you ensure that:
-
SQL Server starts first
-
IIS starts afterward
-
Your ASP.NET Core application starts reliably every time
This simple configuration change provides a stable and production-ready solution, eliminating the need for manual restarts or temporary workarounds.