技术求助：IIS 7.5经典应用池下自定义C#模块未执行排查

兄弟，我之前踩过ISAPI和.NET自定义模块配合的坑，结合你的情况（IIS7.5经典模式完全不执行，IIS Express经典模式正常），给你列几个按优先级排序的排查方向：

1. 先盯死模块的注册顺序和执行阶段 #

经典模式下，.NET托管模块和ISAPI插件的执行顺序完全看IIS里的注册排序，这是最容易出问题的点：

• 打开IIS管理器，找到你的网站→模块，检查你的自定义模块是不是排在Apache Jakarta和CA Siteminder ISAPI的后面。如果排前面，大概率被ISAPI的身份验证逻辑拦截了请求，根本轮不到你的模块执行。
• 另外，确保你的模块绑定了正确的管道阶段。因为要在ISAPI身份验证之后执行，一定要绑定到PostAuthenticateRequest或者更晚的阶段（比如PostMapRequestHandler），代码里要明确指定：

  public void Init(HttpApplication context)
  {
      // 选这个阶段确保在身份验证完成后执行
      context.PostAuthenticateRequest += OnPostAuthenticateRequest;
  }
  
  private void OnPostAuthenticateRequest(object sender, EventArgs e)
  {
      // 你的模块逻辑
  }
  

• 对比下IIS Express的applicationhost.config和正式IIS的applicationHost.config里的模块注册节点，看看有没有差异——IIS Express有时候会自动帮你补全配置，而正式IIS可能漏了某些关键项。

2. 排查ISAPI插件的拦截行为 #

CA Siteminder的ISAPI插件是出了名的“霸道”，经常会直接改写请求或者终止管道：

• 先去看Siteminder的日志，确认请求有没有被正常放行到后续的托管管道阶段。如果日志里显示请求被Siteminder拦截（比如跳转到登录页），那你的模块自然不会执行。
• 临时做个测试：禁用Siteminder和Jakarta ISAPI，单独跑你的自定义模块。如果这时候模块能正常执行，那就是ISAPI和你的模块的执行逻辑冲突了，需要调整ISAPI的通知类型（比如不要用SF_NOTIFY_READ_RAW_DATA这类高优先级通知）。

3. 验证模块的注册和权限配置 #

IIS Express用的是当前用户身份，权限宽松，但正式IIS的应用池身份经常踩权限坑：

• 检查你的模块DLL所在的bin目录，有没有给应用池身份（比如IIS AppPool\你的应用池名称）读取和执行权限？如果权限不够，模块根本加载不起来。
• 确认IIS里的模块列表中，你的自定义模块是已启用状态，有没有被误禁用？
• 如果是全局模块，还要检查applicationHost.config里的<globalModules>节点有没有正确注册你的模块，并且在网站的<modules>节点里添加了引用。

4. 用IIS请求跟踪直接定位问题 #

这是最硬核的调试方法，能看到请求管道的每一步：

• 在IIS管理器中给你的网站开启失败请求跟踪规则，设置跟踪所有请求（或者指定你测试的URL）。
• 生成跟踪日志后，打开日志文件，顺着管道阶段找你的模块：如果日志里根本看不到模块的加载记录，说明注册有问题；如果看到模块被加载但对应的事件没触发，那就是执行顺序或者ISAPI拦截的问题。

5. 确认应用程序池的经典模式配置细节 #

别小看这种低级错误，我之前就踩过：

• 再确认一遍应用程序池的托管管道模式确实是“经典”，不是不小心改成了“集成”——集成模式下模块的执行逻辑和经典模式完全不一样，IIS Express可能默认是经典，但正式IIS可能被改了。
• 经典模式下，托管模块依赖aspnet_isapi.dll的映射，检查网站的处理程序映射里，.aspx等你用到的扩展名是不是正确映射到了aspnet_isapi.dll，而且状态是“已启用”。如果这个映射挂了，托管模块根本不会被触发。

内容的提问来源于stack exchange，提问作者AutomationNation