Fix HTTP Error 500.35 in ASP.NET Core (App Pool Conflict)

You deploy a second ASP.NET Core app under the same IIS site (or point a new application at an existing app pool), hit the URL, and instead of your app you get a stark error page: HTTP Error 500.35 — ANCM Multiple In-Process Applications in same Process. Nothing in your code changed; the app ran fine on its own. The cause is an IIS hosting rule that catches almost every .NET team eventually: an IIS application pool can host exactly one in-process ASP.NET Core application — no more. This guide explains why 500.35 happens, how to confirm it, and the one-app-per-pool fix.

What HTTP Error 500.35 actually means

When you host ASP.NET Core on IIS using the default hostingModel="inprocess", the ASP.NET Core Module (ANCM) loads the .NET runtime directly inside the IIS worker process (w3wp.exe) for that application pool. In-process hosting is fast precisely because there is no separate Kestrel process and no proxy hop — your app code executes inside the IIS worker itself.

That speed comes with a hard constraint: only one in-process .NET runtime can live in a single worker process. The moment IIS tries to start a second in-process ASP.NET Core application in the same app pool — the same w3wp.exe — the module refuses and returns HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process. It is a guardrail, not a crash: two managed runtimes cannot safely coexist in one process, so ANCM stops you before undefined behaviour sets in.

Why you only see this in-process

The error is specific to the in-process hosting model. The two models behave very differently when more than one app shares a pool:

Hosting modelWhere your app runsMultiple apps in one pool?

In-process (default)Inside w3wp.exeNot allowed — second app throws 500.35

Out-of-processSeparate dotnet / Kestrel process per appTechnically possible, but apps still compete for the pool's CPU and memory

Because in-process is the modern default (it ships that way from the Visual Studio and dotnet new templates), most teams hit 500.35 the first time they try to run two apps under one pool — often without realising the apps were sharing a pool at all.

Confirm it's 500.35 (and not 500.30 or 500.31)

The 500.3x family looks similar but points at completely different problems. Read the exact sub-code before you change anything:

ErrorANCM meaningTypical cause

500.30In-Process Start FailureYour app threw during startup (config, DB, DI)

500.31Failed to Find Native DependenciesThe targeted .NET runtime isn't installed on the host

500.35Multiple In-Process Applications in same ProcessTwo in-process apps assigned to one app pool

If you see 500.31, the runtime is missing — a host problem, not a pool problem. On Adaptive Web Hosting's ASP.NET Core plans, the current LTS runtimes (.NET 8 LTS and .NET 10 LTS) are pre-installed side-by-side, so 500.31 is rare. For a startup-failure 500.30, see our guide to why an ASP.NET Core app won't start on IIS.

How to confirm two apps share a pool

In IIS Manager, expand the site, select each application, and read the Basic Settings → Application pool value. If two applications show the same pool name, that's your 500.35. From the command line, list which app pool each app is assigned to:

%windir%\system32\inetsrv\appcmd list app

Watch for nested applications too: a sub-application (for example /api configured under your root site) inherits the parent site's app pool by default. Two in-process apps under one site — root plus a sub-app — is the most common accidental trigger.

The fix: one app pool per application

The supported, production-correct fix is simple: give every in-process ASP.NET Core application its own dedicated app pool.

Create a new app pool for the second application. Set .NET CLR version to "No Managed Code" (this is correct for every ASP.NET Core app — the runtime is loaded by ANCM, not the CLR host):

appcmd add apppool /name:"MySecondApp" /managedRuntimeVersion:""

Assign the application to its own pool:

appcmd set app "Default Web Site/secondapp" /applicationPool:"MySecondApp"

Recycle / restart both pools and re-request the URL. Each app now starts in its own w3wp.exe, and 500.35 is gone.

In Plesk for Windows the same change is point-and-click: each site (and each sub-application) has its own Dedicated IIS Application Pool toggle — enable it per app and Plesk provisions a separate pool for you, no command line required.

If you genuinely need apps in one pool

Occasionally you actually want several apps consolidated. The only supported way to run more than one app in a single pool is to switch them to out-of-process hosting, where each app runs in its own Kestrel process behind IIS:

<aspNetCore processPath="dotnet" arguments=".\MyApp.dll"

hostingModel="outofprocess" />

This removes the 500.35 limit, but it trades it for a slower proxy hop and apps that still share the pool's CPU and memory budget. For almost every deployment, a dedicated pool per app is the better answer.

Why shared app pools cause more than just 500.35

500.35 is the loud, obvious symptom of a quieter problem: apps sharing an app pool share a fate. When two applications live in one pool, one app's memory leak, crash, or recycle takes the other down with it. A run-away request in App A starves App B of worker threads. A configuration change that recycles the pool restarts both. Even where IIS permits sharing (out-of-process), it's a reliability anti-pattern. The one-app-per-pool rule isn't just about avoiding an error code — it's the isolation boundary that keeps one app's bad day from becoming every app's bad day. For the related symptom of pools recycling unexpectedly, see our app pool recycling diagnostic guide.

How Adaptive Web Hosting prevents 500.35

On a lot of shared Windows hosting, the platform packs multiple customer sites into shared application pools to save resources — which is exactly the configuration that produces 500.35 and the noisy-neighbour problems above. Adaptive Web Hosting is built the opposite way:

Dedicated IIS Application Pool per site — every application runs in its own pool and its own worker process by default. Your app never shares a w3wp.exe with a neighbour, so the platform itself never causes a 500.35.

Per-app pools for your own sites too — host several apps on one plan (2 sites on Developer, 5 on Business, 10 on Professional) and each gets its own dedicated pool through Plesk. No accidental consolidation.

Current LTS runtimes pre-installed — .NET 8 LTS and .NET 10 LTS side-by-side on Windows Server 2022 + IIS 10, so the sibling 500.31 "missing runtime" error doesn't happen either.

Real SQL Server 2022 included — the database that backs your app sits on the same machine, so startup-time connection failures (a common 500.30 trigger) are far less likely.

If you're running multiple ASP.NET Core apps and want each isolated in its own pool without managing IIS by hand, that isolation is the default here — not an upgrade.

Frequently asked questions

Can I host two ASP.NET Core apps under one IIS site?

Yes — but each application (the root and any sub-applications) must be assigned to its own app pool when using in-process hosting. Two in-process apps in the same pool is what produces 500.35. Separate pools, or one site per pool, resolves it.

Does switching to out-of-process hosting fix 500.35?

It removes the restriction — out-of-process apps each run in their own Kestrel process, so several can share a pool. But you lose the performance of in-process hosting and the apps still compete for the pool's resources. A dedicated pool per app is the recommended fix.

Why does my app work locally but throw 500.35 on the server?

Locally, dotnet run launches a single app in its own Kestrel process — there's no shared IIS app pool, so the condition can't occur. On the server, IIS assigned your new app to a pool that already hosts another in-process app. The environment differs, not your code.

Is in-process or out-of-process the right default?

In-process is the modern default and is faster and lower-memory for the typical single app per pool. Keep in-process and give each app a dedicated pool. Reach for out-of-process only for specific cases (AOT-compiled executables, or genuinely needing several apps in one pool).

What .NET versions does this apply to?

The in-process one-app-per-pool rule applies across modern .NET (formerly ASP.NET Core) — .NET 6, 7, 8 LTS, 9, and .NET 10 hosting. The error text and fix are identical regardless of the runtime version you target.

Will more memory or a bigger plan fix 500.35?

No — 500.35 isn't a resource problem, it's a configuration rule. The fix is one app pool per application, not more RAM. That said, a plan with dedicated app pools per site means the platform never creates the shared-pool condition in the first place.

Bottom line

HTTP Error 500.35 means two in-process ASP.NET Core applications were assigned to a single IIS application pool, and the ASP.NET Core Module won't run two managed runtimes in one worker process. The fix is always the same: one dedicated app pool per application (set the pool's managed runtime to "No Managed Code"), or switch to out-of-process if you truly need consolidation. It's a five-minute change once you've confirmed which apps share a pool.

On Adaptive Web Hosting's ASP.NET hosting plans, a dedicated IIS application pool per site is the default, so the platform never causes 500.35 — and current LTS runtimes are pre-installed for .NET 10 hosting down to legacy ASP.NET 4.8. Every plan includes a 30-day money-back guarantee. Compare hosting plans, read our HTTP 502 Bad Gateway guide, or talk to an ASP.NET specialist.