When deploying PHP applications on IIS 7.5 with FastCGI, developers often encounter HTTP 500 errors with the specific message: " scriptProcessor could not be found in application configuration". This typically occurs when accessing PHP scripts in subfolders beyond the second level (e.g., /site/subfolder/test.php), while scripts in root and first-level subfolders work normally.

The issue stems from IIS's handler mapping inheritance system. When FastCGI settings aren't properly propagated through the virtual directory hierarchy, IIS loses the script processor reference for nested paths.

<configuration>
  <system.webServer>
    <handlers>
      <add name="PHP_via_FastCGI" 
           path="*.php" 
           verb="*" 
           modules="FastCgiModule" 
           scriptProcessor="C:\PHP\php-cgi.exe" 
           resourceType="Either" />
    </handlers>
  </system.webServer>
</configuration>

First, check current handler mappings at different levels using PowerShell:

Get-WebConfiguration -Filter "/system.webServer/handlers/add[@path='*.php']" -PSPath "IIS:\"

For subfolders to inherit settings correctly, we need to enforce configuration inheritance in applicationHost.config:

<location path="Default Web Site" overrideMode="Allow">
  <system.webServer>
    <handlers>
      <add name="PHP-FastCGI" 
           path="*.php" 
           verb="*" 
           modules="FastCgiModule" 
           scriptProcessor="C:\PHP\php-cgi.exe" 
           resourceType="Unspecified" 
           requireAccess="Script" 
           allowPathInfo="true" />
    </handlers>
  </system.webServer>
</location>

For specific subfolder applications, create a web.config with explicit handler declaration:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers accessPolicy="Read, Script">
      <clear/>
      <add name="PHP-FastCGI"
           path="*.php"
           verb="*"
           modules="FastCgiModule"
           scriptProcessor="C:\PHP\php-cgi.exe"
           resourceType="Unspecified"/>
    </handlers>
  </system.webServer>
</configuration>

Enable failed request tracing to capture detailed logs:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/tracing/traceFailedRequests /enabled:"true" /commit:apphost

After fixing handler mappings, consider optimizing FastCGI settings for better throughput:

<fastCgi>
  <application fullPath="C:\PHP\php-cgi.exe" 
               arguments="-d open_basedir=none" 
               maxInstances="4" 
               idleTimeout="300" 
               activityTimeout="30" 
               requestTimeout="90" 
               instanceMaxRequests="10000">
    <environmentVariables>
      <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" />
    </environmentVariables>
  </application>
</fastCgi>

This IIS 7.5 FastCGI configuration issue typically occurs when the handler mapping fails to propagate through multiple directory levels. The Windows Web Platform Installer (Web PI) setup sometimes creates incomplete configurations for nested folder structures.

First, verify these critical elements in your applicationHost.config file (located in %windir%\system32\inetsrv\config):

<system.webServer>
    <fastCgi>
        <application fullPath="C:\PHP\php-cgi.exe" />
    </fastCgi>
    <handlers>
        <add name="PHP_via_FastCGI" 
             path="*.php" 
             verb="GET,HEAD,POST" 
             modules="FastCgiModule" 
             scriptProcessor="C:\PHP\php-cgi.exe" 
             resourceType="Either" />
    </handlers>
</system.webServer>

The issue frequently stems from one of these scenarios:

• Inherited handler mappings being blocked by parent folder web.config files
• Missing execute permissions on the specific subfolder
• FastCGI application configuration not properly propagating to child applications

1. Verify Handler Inheritance

Run this PowerShell command to check effective handler mappings:

Get-WebConfiguration -Filter "/system.webServer/handlers/add[@path='*.php']" -Recurse

2. Repair FastCGI Application Registration

Use this command to re-register the PHP FastCGI application:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='C:\PHP\php-cgi.exe']" /commit:apphost

3. Force Handler Inheritance

Add this to your root web.config:

<location path="." inheritInChildApplications="true">
    <system.webServer>
        <handlers>
            <add name="PHP_via_FastCGI" 
                 path="*.php" 
                 verb="GET,HEAD,POST" 
                 modules="FastCgiModule" 
                 scriptProcessor="C:\PHP\php-cgi.exe" 
                 resourceType="Either" />
        </handlers>
    </system.webServer>
</location>

If the issue persists, examine failed request tracing logs. Configure tracing with:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/tracing /+"traceFailedRequests.[path='*.php']" /commit:apphost
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/tracing /enabled:"true" /commit:apphost

Look specifically for FastCGI module initialization failures in the generated XML logs.