求助：IIS自定义Classic模块32位正常，64位加载失败致应用池崩溃

核心问题定位 #

错误80070002明确指向文件或依赖项找不到，64位环境下的加载失败通常和32位/64位依赖不匹配、路径配置错误、权限问题有关。

1. 验证64位DLL的有效性 #

• 用dumpbin /headers D:\IISModules\mydll.dll检查输出，确认machine字段为x64，确保编译目标确实是64位架构。
• 使用64位版本的Dependency Walker扫描DLL，排查是否存在缺失的64位依赖库（32位版本无法正确识别64位DLL依赖）。

2. 检查模块注册的路径与注册表配置 #

• 确认IIS中模块的注册路径为绝对路径，若路径含空格需用引号包裹，避免64位工作进程解析路径出错。
• 检查注册表项：
  • 64位模块需注册在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS\Modules下（而非Wow6432Node子项）。
  • 确保对应mydll的ImagePath值为正确的64位DLL绝对路径，无拼写错误。

3. 权限与文件访问排查 #

• 给IIS应用池标识（默认是ApplicationPoolIdentity）配置D:\IISModules目录的读取和执行权限，64位工作进程的权限上下文可能与32位不同。
• 重新编译替换DLL，确认文件未损坏、未被其他进程锁定。

4. 模块入口点与兼容性检查 #

• Classic模块的入口点必须是RegisterModule，且严格遵循64位调用约定：

  HRESULT __stdcall RegisterModule(
      DWORD dwServerVersion,
      IHttpModuleRegistrationInfo* pModuleInfo,
      IHttpServer* pGlobalInfo
  );
  

  避免误用cdecl等非标准调用约定，64位下调用约定不匹配会直接导致加载失败。
• 确保编译时使用的IIS SDK版本与目标服务器的IIS版本一致（如IIS 10对应SDK版本10.0）。

5. 调试加载过程 #

• 用Visual Studio附加到64位w3wp.exe进程，设置加载时断点（或在模块初始化代码开头加DebugBreak()），查看调用栈定位具体失败原因。
• 启用IIS失败请求跟踪规则，捕获模块加载阶段的详细错误日志。

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