这种间歇性的跨服务器加载差异确实让人头疼，尤其是配置看似完全一致的情况下。结合你提到的现象——一台服务器在非共享AppDomain加载了DLL，另一台没加载，还有间隔不定的权限拒绝错误——我整理了几个最可能的原因和排查方向：

1. 共享IIS配置的同步延迟或本地缓存差异 #

虽然用了共享IIS配置，但Windows服务器会对IIS配置和ASP.NET临时文件做本地缓存，不会实时同步所有变更：

• 其中一台服务器的应用池可能在部署后没有完全重启，导致旧的配置缓存还在，从未触发过对新DLL的加载请求；而另一台可能因为应用池自动回收、服务器重启等，已经触发了加载流程。
• 即使Temporary ASP.NET Files权限正常，两台服务器的缓存文件状态也可能不同：比如一台缓存了DLL的有效副本，另一台的缓存文件因为某种原因损坏或未生成，导致加载时出错。

2. 应用池回收策略的隐性差异 #

共享配置有时候会被本地服务器的手动修改“覆盖”，尤其是应用池的回收设置：

• 检查两台服务器的应用池高级设置：右键应用池→高级设置，看回收的时间间隔、内存/CPU阈值、特定时间回收等是否完全一致。如果一台的回收间隔刚好和你看到的5分钟错误周期吻合，那回收后重新加载DLL时可能遇到临时权限问题；而另一台回收策略不同，或者回收后加载成功，所以一直保持加载状态。
• 另外，应用池的快速失败保护设置也可能差异：如果一台服务器的应用池因为加载错误触发了快速失败保护，会自动回收，导致DLL被卸载，而另一台没有触发这个机制。

3. 文件服务器的网络连接或缓存问题 #

因为DLL放在共享文件服务器上，两台Web服务器的网络访问状态可能存在差异：

• 其中一台服务器可能偶尔出现网络波动，导致加载DLL时出现临时访问失败，系统会把这种网络错误伪装成“权限拒绝”返回（这是Windows常见的误导性报错）。
• Windows的文件系统缓存机制也可能导致差异：一台服务器缓存了DLL的本地副本，后续加载直接用缓存；而另一台每次都要从文件服务器读取，遇到临时访问问题就报错。可以尝试把DLL复制到Web服务器的本地应用目录，测试是否还会出现加载差异，以此排除文件服务器的影响。

4. AppDomain动态创建的触发差异 #

你提到一台服务器在非共享AppDomain加载了DLL，另一台没加载，这很可能是应用代码的触发路径不同：

• 应用中的某些逻辑（比如插件机制、动态编译的代码、特定API请求）可能会创建新的AppDomain并加载DLL。如果一台服务器收到过这类触发请求，就会加载DLL；而另一台还没处理过这类请求，所以DLL未被加载。
• 间歇性错误可能是因为当这个非共享AppDomain被回收或卸载后，重新加载时遇到了权限问题。可以对比两台服务器的请求日志，看是否有特定请求会触发PLEGateway的调用，确认请求分布是否一致。

5. 32位模式的实际生效差异 #

虽然你说应用池启用了32位程序，但可能存在隐性的模式不生效问题：

• 用Process Explorer检查两台服务器的W3wp.exe进程，确认都带有32位标记（进程名后加*32）。如果其中一台实际是64位模式，加载32位的PLEGatewayCore.dll就会出错，而且错误可能表现为间歇性的权限拒绝。
• 用dumpbin /dependents PLEGatewayCore.dll命令查看DLL的依赖项，检查两台服务器上这些依赖项是否都存在，且权限配置一致。比如某个依赖项在64位环境下缺失，就会导致加载失败。

下一步排查建议 #

1. 强制重启两台服务器的应用池，观察后续加载状态是否一致；
2. 把PLEGatewayCore.dll复制到Web服务器本地的bin目录，测试是否还会出现间歇性错误；
3. 用Process Monitor跟踪W3wp.exe对PLEGatewayCore.dll的访问记录，看失败时的具体错误细节（比如是真的权限问题，还是文件找不到、依赖缺失）；
4. 对比两台服务器的应用池配置、系统事件日志，找出细微的差异点。

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