How to Fix HTTP Error 500.35 in ASP.NET Core on Plesk Windows: Application Pool and IIS Troubleshooting

What Is HTTP Error 500.35 in ASP.NET Core?

HTTP Error 500.35 indicates that multiple ASP.NET Core applications are attempting to run in the same IIS application pool when using the in-process hosting model. To fix this error, assign each application its own dedicated IIS application pool, verify the ASP.NET Core Module configuration, and confirm that the deployed application matches the installed .NET runtime. Microsoft identifies application-pool sharing as unsupported for in-process ASP.NET Core hosting.

Why Does HTTP Error 500.35 Occur on Plesk Windows Hosting?

HTTP 500.35 usually results from an IIS application-pool configuration conflict rather than a DNS or network connectivity problem. IIS receives the incoming HTTP request, processes the site configuration, and uses the ASP.NET Core Module (ANCM) to load or forward requests to the ASP.NET Core application. When multiple applications share a pool under the in-process model, the hosting configuration violates the application’s isolation requirements.

On a Plesk Windows server, this issue can appear after deploying a new ASP.NET Core website, moving an application between domains, or changing its IIS configuration. A website may work before a deployment and fail afterward if the deployment changes its application-pool assignment or hosting model. Administrators should verify the actual IIS configuration before assuming that the application code, database, or server hardware has failed.

How Does IIS Host ASP.NET Core Applications?

IIS hosts ASP.NET Core applications through the ASP.NET Core Module, a native IIS module that supports both in-process and out-of-process hosting. In-process hosting runs the application inside the IIS worker process, w3wp.exe, while out-of-process hosting forwards requests to a separate application process running Kestrel. Microsoft uses in-process hosting by default for ASP.NET Core applications unless the application configuration specifies otherwise.

The hosting model determines how IIS manages the application process and whether the site can share an application pool with another ASP.NET Core application. For in-process hosting, Microsoft requires a separate application pool for each application. Administrators should therefore confirm the hosting model before changing application-pool assignments or editing the application’s web.config file.

How Do You Confirm That HTTP 500.35 Is an Application Pool Conflict?

The exact error message provides the first diagnostic clue. If the browser displays “ASP.NET Core does not support multiple apps in the same app pool,” investigate the IIS application-pool assignments before changing permissions, disabling security controls, or reinstalling .NET.

In Plesk, identify the affected domain and determine whether it has a dedicated IIS application pool. Review the website’s hosting configuration and, if you have administrator access, open IIS Manager to inspect the site’s application-pool assignment. Check whether another ASP.NET Core application uses the same pool, particularly when both applications use in-process hosting. A separate pool for each application is the required configuration for this hosting model.

How Do You Fix HTTP Error 500.35 in Plesk Windows?

The most direct fix is to give the affected ASP.NET Core application a dedicated IIS application pool. In Plesk, open the affected domain and look under its hosting or IIS-related settings for the dedicated application-pool option. The exact menu labels can vary by Plesk version and hosting permissions. If the subscription does not expose this setting, ask the hosting provider or server administrator to configure the pool in IIS.

After creating or enabling a dedicated pool, assign the affected application to it and confirm that no other ASP.NET Core application using in-process hosting shares the same pool. Apply the configuration change and recycle the affected pool if necessary. Test the website again and confirm that the 500.35 error no longer appears. Avoid restarting all IIS services unless the change requires it, because a server-wide restart can interrupt unrelated websites.

Should You Set the IIS Application Pool to No Managed Code?

Setting the IIS application pool’s .NET CLR version to No Managed Code is the recommended configuration for ASP.NET Core applications hosted through IIS. ASP.NET Core uses its own CoreCLR runtime rather than relying on the traditional .NET Framework CLR setting in the IIS application pool. Microsoft describes this setting as optional but recommended.

In IIS Manager, open Application Pools, select the pool assigned to the website, and choose Basic Settings. Set the .NET CLR version to No Managed Code, then confirm that the application uses the correct pool and hosting model. Do not confuse this setting with installing the required .NET runtime: No Managed Code does not install .NET, repair a missing Hosting Bundle, or resolve an application-pool conflict by itself.

How Do You Verify the .NET Hosting Bundle and ASP.NET Core Module?

The .NET Hosting Bundle installs the runtime components and ASP.NET Core Module required to host ASP.NET Core applications behind IIS. If the required module or runtime is missing, incompatible, or incorrectly installed, the website can produce a different startup error even after you resolve HTTP 500.35.

Confirm that the server has the runtime version required by the deployed application and that the ASP.NET Core Module is installed. Check the application’s target framework and deployment type before installing or updating server components. A framework-dependent deployment requires a compatible runtime on the server, while a self-contained deployment bundles its runtime with the application. Avoid installing or upgrading server-wide components without checking the other applications hosted on that server.

How Do You Check the Application’s Architecture and Permissions?

The IIS application pool’s process architecture must be compatible with the application’s deployment architecture and runtime. For example, an in-process application published for a specific architecture can fail to start if the application-pool bitness and installed runtime do not match.

Verify whether the application requires 32-bit or 64-bit execution, confirm the application-pool setting, and check the identity used by the pool. That identity must have the required access to the application’s deployment directory and any files or resources the application needs to read or write. Do not grant broad write permissions to the entire website directory as a shortcut; apply only the access the application actually requires.

What Should You Check If HTTP 500.35 Persists After the Fix?

A persistent 500.35 error means you should recheck the effective IIS configuration rather than repeatedly restarting the website. Confirm that the affected application is assigned to its own pool, that the pool is running, and that no parent or child application configuration reintroduces an unintended shared assignment. Check the application’s hosting model in web.config and verify that the deployed configuration matches the intended hosting architecture.

If the error changes after correcting the pool assignment, diagnose the new error separately. A 500.19 response can indicate invalid IIS configuration, while startup failures can point to a missing runtime, a Hosting Bundle issue, application permissions, or a problem in the application itself. Use the Windows Event Viewer and relevant IIS or ASP.NET Core Module diagnostics to correlate the failure with the time of the request. Enable detailed application output only when needed, protect diagnostic files from public access, and disable temporary diagnostic logging after collecting the required evidence.

Can HTTP 500.35 Cause a Website to Become Completely Unavailable?

HTTP 500.35 can prevent an ASP.NET Core application from serving requests successfully, making its main website unavailable to visitors. The impact depends on the site’s deployment and architecture. If the affected application handles the main site or its critical endpoints, users may be unable to log in, load content, or complete transactions.

However, HTTP 500.35 does not prove that the entire Windows server is down. Other sites and services may continue working normally. Test the affected domain separately, inspect the response returned by IIS, and verify other hosted websites before declaring a server-wide outage. This distinction helps support teams resolve the specific application problem without disrupting unrelated customers.

What Can Administrators Learn From a Plesk Windows Hosting Incident?

A support incident involving an ASP.NET Core application on Plesk Windows illustrates why administrators should distinguish application-pool failures from static-resource and security-rule failures. In one reported case, an educational Blazor Server platform displayed HTTP 500.35 with the message that ASP.NET Core does not support multiple applications in the same application pool. The customer also reported HTTP 403 responses for CSS files, a Blazor stylesheet, blazor.server.js, and the favicon. Support later reported that updating the WAF settings restored the site at that stage.

These symptoms should not be treated as proof of one shared root cause. HTTP 500.35 points to an ASP.NET Core hosting configuration conflict, while HTTP 403 indicates that a request was forbidden and requires a separate investigation into IIS restrictions, security rules, permissions, or other access controls. The appropriate engineering approach is to resolve the application-pool conflict, retest the site, and investigate any remaining static-resource failures independently. The incident did not provide verified performance measurements, so assigning a percentage improvement or claiming a measured reduction in downtime would be misleading.

How Can You Prevent HTTP 500.35 During Future Deployments?

Preventing HTTP 500.35 starts with treating IIS application-pool assignments as part of the application’s deployment configuration. Before publishing a new ASP.NET Core application, confirm its hosting model, target framework, runtime requirements, and assigned application pool. For in-process hosting, provision a dedicated pool for each application rather than reusing a pool simply because two sites belong to the same customer.

Document the existing pool assignment before changing IIS settings, and test the deployed application before closing the maintenance task. For hosting providers that manage many customer websites, deployment checks should verify that a new application does not inherit an incompatible pool assignment. These checks reduce configuration mistakes without requiring unnecessary server-wide restarts or security-policy changes.

Which Microsoft and Plesk Resources Should You Consult?

Microsoft’s official documentation explains the hosting model, application-pool requirements, and the role of the ASP.NET Core Module. Start with ASP.NET Core Module for IIS, then review advanced IIS configuration and the ASP.NET Core Hosting Bundle documentation. For Plesk-specific configuration, consult the Plesk for Windows ASP.NET documentation.

How Can You Resolve Persistent ASP.NET Core Hosting Issues?

Correcting HTTP 500.35 requires more than restarting IIS: the application must use a compatible hosting configuration, its own application pool when running in-process, and the correct runtime and permissions. If the error persists after these checks, an infrastructure engineer should review the effective IIS configuration and application startup diagnostics before making broader changes.

If your business hosts production applications on Windows or Plesk and needs help with IIS configuration, ASP.NET Core deployment failures, or recurring website outages, contact ActSupport to discuss infrastructure troubleshooting and managed server support.

Frequently Asked Questions About HTTP Error 500.35