在 AWS 中，任务被放置在 EC2 实例上，并且 ASP.NET WebAPI 2 应用程序在 docker 容器中启动。
根站点是空的，“/myapp”子目录包含正在运行的 Web 应用程序。
应用程序池配置为自动启动并始终保持开启状态。preloadEnabled 设置处于活动状态，以确保重叠回收正确进行，并且 Application_Start 在处理请求之前完成。我甚至指定了一个设置标志的预热页面，并确认在向新进程传递请求之前也会调用该页面。
我遇到的问题是，当第一次放置任务时，在调用 Application_Start 之前，我看到 Windows 系统日志表明 IIS 认为发生了配置更改，需要重新启动应用程序池。结果是第二个 w3wp.exe 进程在第一个进程开始几秒钟后就开始执行 Application_Start 逻辑，甚至在它有机会完成其 Application_Start 运行之前。最终，两个进程都崩溃了，它们被第三个进程取代，后者成功完成并开始处理请求。
我的第一个问题是，为什么一个即将启动 IIS 的新 docker 容器会立即认为发生了一些设置更改，需要最初的回收过程? 在写入此系统日志时，甚至没有用户代码运行；它的时间戳出现在 Application_Start 记录任何活动之前的几秒钟。我的第二个问题是，我怎么才能弄清楚是什么触发了这个明显的设置更改，或者这个设置更改是什么？日志没有提到哪些设置或文件发生了更改，也没有提到更改的原因。这似乎在 docker 容器内调试起来特别困难。
据我所知，没有病毒扫描程序接触文件在docker容器中（如最初建议的那样这里)，据我所知，docker 镜像的文件系统在启动时就已经锁定了；它不像docker文件中的那些改变设置的行在镜像挂载时会重新运行。
系统日志：
2022 年 1 月 25 日 22:36:59 WAS 警告为应用程序池“DefaultAppPool”提供服务的进程意外终止。进程 ID 为“11592”。进程退出代码为“0xc0000005”。
2022 年 1 月 25 日 22:36:59 WAS 警告为应用程序池“DefaultAppPool”提供服务的进程与 Windows 进程激活服务发生致命通信错误。进程 ID 为“1328”。数据字段包含错误编号。109 0 7 128
2022 年 1 月 25 日 22:34:35 WAS 信息由于应用程序池属性中的一个或多个配置更改，需要重新启动进程，因此为应用程序池“DefaultAppPool”提供服务的工作进程正在被回收。
请注意，第一个日志在 22:34:35 出现，表明某些事情已经发生改变，这发生在第一个进程到达 Application_Start 之前，因为 Application_Start 输出的第一个日志的时间戳远晚于它。切换不同的应用程序池设置（如启动超时等）会改变两个进程崩溃的原因（例如，有时是 OutOfMemoryException 而不是访问冲突），但这些都不能解释为什么它认为在第一个进程启动之前就需要池回收，然后启动两个进程，一个接一个。我不太关心为什么它们最终都崩溃了，然后被一个完全相同的第三个进程取代，而第三个进程完全没有任何问题地完成。