How can I find the cause of 403.18 error in IIS?

I have installed a new application under IIS. The new app has a dedicated application pool like many other applications installed on the same server. There is the root web site which also has it's own dedicated app pool. All the previously deployed applications are working fine under this configuration, but the newest application causes a 403.18 error when I try to browse to it.

If I browse to it from an RDP session on the server I get the detailed error page which includes this information:

HTTP Error 403.18 - Forbidden

The specified request cannot be processed in the application pool that is configured for this resource on the Web server.

Most likely causes:

• An ISAPI filter or custom module changed the URL to run in a different application pool than the original URL.
• An ISAPI extension (or custom module) used ExecuteURL (or ExecuteRequest) to run in a different application pool than the original URL.
• You have a custom error page that is located in one application pool but is referenced by a Web site in another application pool. When the URL is - processed, it is determined by IIS that that it should have been processed in the first application pool, not the other pool.
• The Web site has multiple applications configured. The application this request is configured to run in is set to run in an application pool that does not exist.

Things you can try:

• If you have an application that is trying to process a URL in another application pool (such as trying to process a custom error), ensure that they both - run in the same application pool if appropriate.
• If you are trying to process a custom error URL that is located in another application pool, enable the custom errors Redirect feature.
• Verify that the application pool for the application exists.
• Create a tracing rule to track failed requests for this HTTP status code and see if ExecuteURL is being called. For more information about creating a tracing rule for failed requests, click here.

I ran the failed request trace but it basically repeated the same information and did not seem to provide any insight. I admit that I don't understand everything in that trace file.

I tried changing the application pool for the root site to the same pool as the newly deployed application. This clears the 403.18 error, so the difference in app pools between the app and root site seem to have something to do with it. However, the app does not load and the browser simply does a directory listing on the physical path contents.

The strange thing is that many other applications on this server are running just fine. The big difference with the new application is that is uses .NET 5 and Azure AD authentication. The others use previous versions of .NET Core or .NET Framework and Windows authentication. I have verified that the .NET 5 Hosting Bundle is installed.

I did try following the "Things you can try" list in the error page and they don't seem to apply.

Are there any other steps I can try or clues that might help me find the root cause on this? I'm happy to provide more details, but I'm not sure yet what details are relevant.

Well, I stumbled across the cause of this error finally. The name of the affected application had previously been configured as a virtual directory and there was still an entry for that in the applicationHost.config file.

The newest version was deployed as application. There were some other obsolete entries for the application name in applicationHost.config file.

What gave this away is that I tried deploying the app under a new name it worked. That seemed strange so I compared applicationHost.config between the server where the app was causing 403.18 and the dev server where it worked OK.

The real root cause of this error is the fact that we cloned a production web server and made it a test web server. These invalid entries were present in the production server. It kind of worked out for the best though, because otherwise we would not have hit that 403.18 error until we deployed to production.

So checking for invalid entries in applicationHost.config is at least one of the troubleshooting steps that can be done to solve for 403.18.