Troubleshooting Load Balancer Failures: Restoring SPRequestFilterModule in SharePoint

Symptoms

The load balancer (F5) stopped sending web traffic to one of its pool members (SharePoint frontend) because it detected that the server was down. 

Diagnosis

IIS logs show the load balancer probes as follows:

Note that the HTTP status code (sc-*) is recorded as 0.0.2. The Win32 status of 2 -- which commonly corresponds to ERROR_FILE_NOT_FOUND when a default page (such as default.aspx or index.html) is missing -- is misleading in a SharePoint context. SharePoint does not store a default page in the site's root directory, and the load balancer is not configured to query default files. 

What's more relevant here is that the server returned 0 bytes to the client and logged a 0 ms response time, indicating the request failed immediately in IIS before reaching the SharePoint/application layer. Therefore, the failure likely occurred earlier in the request pipeline during the native module handoff.

While multiple factors could cause such behavior (for example, a network-level reset or a DNS resolution failure affecting the IIS pipeline before the request reaches the application), the root cause I found here was an incorrect registration of SPRequestFilterModule in IIS. This module is used for Antimalware Scan Interface (AMSI) integration in SharePoint:

Note that the Code column for SPRequestFilterModule is blank. This is similar to what happened with the September/October 2023 SharePoint CU. The module is also not found when Get-WebGlobalModule is run on the server:

This explains why the failure occurred so early in the HTTP request pipeline that the IIS logging engine could not complete the handoff. Consequently, no associated log entries were generated in ULS, nor were any correlating events logged in the Windows Event Viewer.

How the server entered this broken state remains unknown, though it occurred during a maintenance window marked by some unexpected psconfig failures and server reboots. 

Remedy

To restore the SPRequestFilterModule, the following steps were taken:

1. Removal of the broken site-level module: At the site level (SharePoint web application),   SPRequestFilterModule was removed via Modules > Remove. After removal, "Configure Native Modules..." menu did not show SPRequestFilterModule in the selection list, so it could not be re-added directly at the site level: 
   
   
2. Registration of the module at the machine level: At the IIS machine level, Configure Native Modules... > Register Native Module was used to register the module with the following values:
       Name: SPRequestFilterModule
       Path: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\sprequestfilteringmodule.dll
   
   
3. Re-enabling the module at the site level: Switching back to the site level, Modules > Configure Native Modules... was opened and SPRequestFilterModule was selected.
   
   After the module was added to the site, the server was no longer detected as down by the load balancer and resumed sending traffic to the client. However, the site module's Entry Type was shown as Inherited, whereas SharePoint's default/original configuration is Local.
   
   Therefore, the web application's web.config was updated to explicitly declare the module under <modules>:
   
   <system.webServer>
       <modules runAllManagedModulesForAllRequests="true">
         <add name="SPRequestFilterModule" />

IIS was checked to confirm that SPRequestFilterModule's Entry Type was changed to Local for the site.

Once the IIS module was corrected, the IIS log entries for the load balancer probes started reporting HTTP 0.0.0 in lieu of  0.0.2, and the sc-bytes and time-taken fields populated with correct, non-zero values: