x86 IIS module in CI-built MSI fails to load - fuzzy.dll missing MinGW runtime DLLs (error 126)

[webwizuk]

Describe the bug

The MSI produced by the "CI/CD for IIS Module" workflow installs an x86 IIS module that fails to load in 32-bit application pools with error 126. The x64 module loads and works correctly; only 32-bit pools are affected.

Cause: fuzzy.dll (ssdeep) is built with MinGW gcc in CI, unlike the rest of the module which is MSVC/vcpkg. The 32-bit MinGW build of fuzzy.dll imports libgcc_s_dw2-1.dll (which in turn requires libwinpthread-1.dll), but the MSI does not package these DLLs, so the x86 dependency chain breaks and ModSecurityIIS.dll cannot load. Confirmed by reading the import table of the shipped x86 fuzzy.dll - its only non-system import is libgcc_s_dw2-1.dll, which is not present in the MSI or on a standard Windows Server install.

Logs and dumps

Windows Application Event Log, event ID 2280, on any request to a site in a 32-bit application pool:

The Module DLL C:\WINDOWS\SysWOW64\inetsrv\ModSecurityIIS.dll failed to load.  The data is the error.

Event data contains Win32 error 126 (ERROR_MOD_NOT_FOUND).

LoadLibraryEx on C:\Windows\SysWOW64\inetsrv\fuzzy.dll in a 32-bit process fails with error 126; after copying libgcc_s_dw2-1.dll and libwinpthread-1.dll into the same directory, fuzzy.dll, libxml2.dll and modsecurityiis.dll all load successfully.

No debug/audit/error logs are produced because the module never loads. No crash/core dump - clean load failure.

To Reproduce

1. Download the MSI artifact (modsecurityiis-installers-Release) from a "CI/CD for IIS Module" workflow run on v2/master
2. Install on Windows Server with IIS
3. Set an application pool to "Enable 32-Bit Applications = True"
4. Request any page from a site in that pool
5. Site fails / event 2280 logged; x64 pools on the same server work fine

Expected behavior

x86 module loads in 32-bit application pools, as the x64 module does in 64-bit pools.

Workaround (verified in production)

Copy libgcc_s_dw2-1.dll and libwinpthread-1.dll (from MSYS2 packages mingw-w64-i686-gcc-libs and mingw-w64-i686-libwinpthread) into C:\Windows\SysWOW64\inetsrv\. The module then loads and blocks correctly in 32-bit pools.

Suggested fix

In .github/workflows/test-ci-windows.yml, copy the MinGW runtime DLLs from the MINGW32 environment into the x86 release directory alongside fuzzy.dll before the WiX heat harvest, so they are included in the MSI. (Alternatively, build ssdeep with MSVC like the other dependencies, or statically link the MinGW runtime with -static-libgcc.)

Server

• ModSecurity version: v2/master CI build (post-2.9.13, 2026)
• WebServer: IIS on Windows Server, mixed 32/64-bit application pools
• OS: Windows Server (multiple versions across a shared hosting estate)