How to Fix ASP.NET Core 502.5 Process Failure on Windows Hosting

The 502.5 Process Failure error means IIS started your ASP.NET Core app, and the app stopped before it could answer. It is different from a 500 error, which means the app ran and failed on a request. A 502.5 is almost always a startup problem: the wrong DLL name, a missing runtime, a configuration value that is required and absent, or a file the app cannot read. The error page itself does not say which, so this guide shows where the real message is, how to read it, and the fix for each common cause.

On SiteHarbour’s Windows hosting, the runtimes are installed for you, so most 502.5 errors come from the application and its configuration. The steps below work on any Plesk Windows server.

Step 1: Confirm the error is a startup failure#

Open the site and look at the status code and the page. A 502.5 page says the process failed to start, and it names the ASP.NET Core Module. A 500 error with a stack trace is a different problem, covered in the request-level checks in Step 5. Note the exact code. The two need different fixes.

Step 2: Turn on stdout logging#

The app’s startup error is written to a log file, but only when stdout logging is on. In the web.config file in the website folder, find the aspNetCore element and set the logging attribute:

<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

Create the logs folder in the website folder, and give the website’s user write access to it. Reload the site. Expected: a file in logs that starts with the startup message. Turn logging back off once you have the cause, because the log can grow and it may hold details you do not want public.

Step 3: Read the Windows event log#

The ASP.NET Core Module also writes to the Windows Application event log. Open Event Viewer on the server, or ask your host for the entries, and look at the Application log for events from the source named IIS AspNetCore Module V2. The event names the module, the process and the reason in plain words. Compare its time with the time of your request.

Step 4: Fix the common causes#

Match the message in the log to one of these causes:

• The DLL name is wrong. The arguments value in web.config must name the app’s DLL exactly, with the same capital letters. A file called MyApp.dll is not the same as myapp.dll on a case-sensitive path. Check the folder listing and correct the name.
• The runtime does not match. The app targets a .NET version the server does not provide. Check the TargetFramework in the project and the version the plan supports, and publish again for the right one.
• A required setting is missing. The app reads a connection string or a key at startup, and the value is absent in production. Add it as an environment variable in the website’s settings, as described in how to connect ASP.NET Core to MS SQL Server.
• A file is missing from the publish output. A dependency or a configuration file was not uploaded. Publish again, and upload the complete output folder.
• The app cannot read or write a file. The website’s user lacks permission on a folder the app needs, such as the data or logs folder. Grant read access to the app folder, and write access only where the app writes.
• The app throws in its startup code. A database connection or a dependency fails before the app listens. The exception in the stdout log names the call that failed. Check the connection string and the database user.

Step 5: Test after each fix#

After each change, reload the site and check the status code. Do not change three things at once, because the error will go away without you knowing which change fixed it. Once the site returns a page, check the logs again: a warning at startup can become an error on the first request that uses the failing feature.

Step 6: Turn logging off and confirm#

Set stdoutLogEnabled back to false, delete the log files, and reload. Then test a page that uses the database or a file, not only the home page. A site that starts and fails on the first real request has the same root cause, and this check finds it.

Common mistakes#

• Reading the page, not the log. The error page says what failed to start, not why. The log says why.
• Leaving stdout logging on. Turn it off after the fix.
• Changing the runtime without republishing. The published output is built for one version.
• Uploading only the DLL. The app needs its dependencies and its configuration files.

Frequently asked questions#

Is 502.5 the same as 502 Bad Gateway?#

No. A 502 Bad Gateway usually means the proxy could not reach the app. A 502.5 means IIS reached the app’s process, and the process failed to start. The sub-code narrows it.

Why did the app work before and fail after a deploy?#

The deploy changed a DLL name, a runtime version, a setting or a file. Compare the deploy output with the previous one. A rollback to the earlier commit confirms the cause.

Can I restart the app without a deploy?#

Yes. Touching web.config restarts the app. Use this after a settings change, not as a fix for a real error.

Where is the error log on Plesk?#

The file is the one named in stdoutLogFile, inside the website folder. The Windows event log holds the module’s message as well.

A 502.5 error is a startup problem with a clear message in the log. Turn on stdout logging, read the event log, match the message to the cause, and fix one thing at a time. Turn logging off afterwards. For the deploy steps that avoid most of these causes, read how to deploy ASP.NET Core on Plesk Windows hosting.