Skip to content

IIS Module Troubleshooting Guide

Visual Studio Project Issues

When building on Windows 10, one may encounter the following build issues.

SigsciCtl

  • If the reference to Microsoft.Web.Management is missing, enable IIS Management Console
  • Target framework may have to be adjusted to .Net Framework 4.5 from 3.5.

SigsciIISModule

  • Windows SDK Version may have to change to 10.0. from 8.1.

Issues

  • If the customer is seeing lots of open TIME_WAIT connections and the agent logs are showing possible RPC errors. The module can be configured to use a connection pool by enabling the following option.

    "%PROGRAMFILES%\Signal Sciences\IIS Module\SigsciCtl.exe" Configure-Module ReuseConnections=True

However, the sigsci-agent must also be configured to use rpc-version=1

  • ReadEntityBody message errors may be seen in the module logs, often this relates to the inspection of POST body requests. To diagnose whether POST body inspection is indeed causing issues, one can try to disable inspection by doing the following. However, NOTE that leaving the module configured in such a way is not recommended.

    "%PROGRAMFILES%\Signal Sciences\IIS Module\SigsciCtl.exe" Configure-Module MaxPostSize=0

  • While the IIS module may not support 32-bit mode in 64-bit Windows 2008R2, we may need to allow using the SigSci Agent in reverse proxy(revproxy) mode as an alternative. Configuring TLS with revproxy on Windows may require a few additional steps. The CNAME associated with the certificate may need an entry in the hosts file on windows, the path is here: C:\Windows\System32\drivers\etc

In addition, if errors in the browser or the agent should indicate any TLS certificate errors, one may need to create a compatible windows certificate and store it in the Microsoft Management Console, see View certificates in the MMC snap-in. Below is an example of how to covert a PEM format along with its key into a PKCS12 format openssl pkcs12 -export -inkey cert_key_pem.txt -in cert_key_pem.txt -out cert_key.p12

Debugging

  • To enable debug logging, issue the following. All module logging will be seen in the Windows event viewer.

    "%PROGRAMFILES%\Signal Sciences\IIS Module\SigsciCtl.exe" Configure-Module Debug=true

  • For other environments such as Azure, that also make use of the module, one can set the application environment variable to enable debug logging,

    SIGSCI_MODULE_DEBUG = 1

  • SigsciCtl.exe wraps a lot of the same functionality from IIS' appcmd, which is useful in itself.

    %SYSTEMROOT%\system32\inetsrv\appcmd.exe" clear config -section:SignalSciences32

  • For stack traces and dump files, a more comprehensive study is required.

    You can open dump files in any Windows debugger. Easiest is DebugDiag 2. The best is WinDbg, but harder to use. Another is Visual Studio Community. Generally you can right-click on the dump file and Open with....

    There is some articles for how to capture a dump file.

    In any case, you will need the debug symbols (PDB) file for that build. Currently this is available as an artifact from Appveyor where we do our builds. Ask the build team if you do not have access or need help getting the correct PDB file. In the debugger you will then need to specify the path to find this PDB file to be able to make sense of the stack trace.

    Right now it is a bit tricky to find the correct PDB. Essentially you need to figure out what Appveyor build created the binaries for that version, look in the artifacts, and download that PDB. The new SHA256 files can help verify the correct PDB.

    In WinDbg, it helps to run the !analyze -v command to get a full stack trace (in the STACK_TEXT section) as well as other information such as the version of the module that crashed, etc.

Useful tools

  • ChkMatch is another tool that can get debug symbol files (PDBs) to match if you do not have the PDBs for that build. It's a bit hard to find now, use to be hosted here: http://debuginfo.com/tools/chkmatch.html