Trending Issue: Module “SPRequestFilterModule” could not be found after September/October 2023 CU

Since release of September 2023 CU we received a couple of support cases where all web applications stopped working with a 500 server error.
A similar problem related to problems coming from Antivirus Scanners was discussed in my previous article.

In a couple of cases we identified a second problem with similar symptoms but different cause.

This new issue also shows a HTTP 500 Error and is also related to the AMSI functionality – but in this case the problem is caused by a configuration problem in the applicationHost.config file of IIS.

Symptoms

The easiest way to spot this issue is by looking into the Modules configuration of the IIS website for the affected web application. Here you can see that the SPRequestFilterModule is not correctly registered as the Code column is empty:

The problem will also be revealed when using Failed Request Tracing in IIS:

Background Information

We have heard about assumptions that the module is incorrectly registered in the web.config as it does not have a path here:

<modules ...>
   ...
   <add name="SPRequestFilterModule" />
</modules ...>

Just to be clear: this line is fully correct and should not be changed!
If you look around you will notice other SharePoint modules in the same section which have a similar registration and work perfectly correct:

<modules ...>
   ...
      <add name="SPNativeRequestModule" preCondition="integratedMode" />
      <add name="SharePoint14Module" preCondition="integratedMode" />
   ...
</modules ...>

All these modules are registered in the applicationHost.config file as global modules which guarantees that they can be loaded by just specifying the name without having to specify the class and assembly in the web.config:

<globalModules>
   ...
   <add name="SharePoint14Module" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\owssvr.dll" preCondition="appPoolName=SharePoint Central Administration v4;SharePoint - 2002;SharePoint - 2001;SharePoint - 2000;SharePoint - 80;SharePoint - 2003;SharePoint - 2004" />
   <add name="SPNativeRequestModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\spnativerequestmodule.dll" />
   <add name="SPRequestFilterModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\sprequestfilteringmodule.dll" preCondition="integratedMode,bitness64" />
</globalModules>

Coming back to the support cases. The entry in the web.config for these cases is correct.
The problem is caused by a missing SPRequestFilterModule registration in the applicationHost.config.

Solution

To fix the issue ensure that the green line above is listed in the globalModules section of the applicationHost.config.

We discourage from fixing the issue by adding the path to the SPRequestFilterModule in the web.config as this is just a local fix for this given web application. When creating new web applications later or extending an existing one will result in the same issue as the web.config file generated by these operations expects the module to be globally registered. In addition, reprovisioning the web application later – e.g. by applying a CU which performs this step to update the web.config – might revert the manual changes in the web.config.

9 Comments


    1. Reply

  1. We activated AMSI in Sharepoint SE in June and also received the 500 error in September. The entry in the applicationHost.config file only existed on the server that hosts Central Administration. On the other servers, we registered the module in IIS as server-level native modules.
    https://blog.kenaro.com/2023/09/18/internal-server-error-on-sharepoint-server-2019-o-premises-after-update/

    Then the entry was present in the applicationHost.config, but not yet in the web.config of the WebApplications. Only after we did AMSI Disable-SPFeature -Identity 4cf046f3-38c7-495f-a7da-a1292d32e8e9 -Url http://url-to-webapp and then enable-SPfeature was also present. And everything was fine.
    Maybe a permissions issue with the Farm-Account?

    Reply

  2. Can be added in a scripted way as well:

    $fn = “$([environment]::GetEnvironmentVariable(“SystemRoot”))\system32\inetsrv\config\applicationhost.config”
    $l = [System.Collections.Generic.List[string]]::new( ([system.io.file]::ReadAllLines($fn)) )

    if( $null -eq ($l | ? { $_ -like “SPRequestFilterModule“} ) ) {
    Write-Host “SPRequestFilterModule not found…”

    if( (Test-Path "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\sprequestfilteringmodule.dll") ) {
    write-host "missing module found on disk!"

    . iisreset /stop

    $m = @()
    for( $i = 0; $i -lt $l.Count; $i++ ) {
    if( $l[$i].IndexOf("</globalModules>", [StringComparison]::OrdinalIgnoreCase) -ge 0) {
    $l.Insert($i, ' <add name="SPRequestFilterModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\sprequestfilteringmodule.dll" preCondition="bitness64" />')
    break
    }
    }

    [system.io.file]::WriteAllLines($fn, $l.ToArray())

    . iisreset /start
    } else {
    Write-Error "Missing module DLL not found on disk!"
    }

    } else {
    Write-Host “SPRequestFilterModule is already registered in IIS!”
    }

    Reply

    1. … this is a copy of the script from the blog post mentioned….

      Reply

  3. the same issue happened with me for SharePoint SE after November update,

    Reply

    1. Hi Abdullah,
      thats correct. A fix is currently scheduled for December 2023 CU.
      Cheers,
      Stefan

      Reply

  4. I ran into this issue on a Windows 2019 server installing SP2016 with the Sept 2023 patch.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.