在 IIS 8.5 上，我们有一个正在运行的 Web 应用程序，其应用程序池的标识设置为ApplicationPoolIdentity。
当我们切换到Custom account而不是ApplicationPoolIdentity时，Web 应用程序的用户会话会随机丢失，并且会在应用程序池回收时丢失。
但一切都还好ApplicationPoolIdentity。
Custom account知道使用具有 IIS_IUSRS 权限的 Windows 用户帐户存在什么问题吗？
我们所需要的只是让Custom account身份的行为方式与ApplicationPoolIdentity会话状态相同。其他一切都很好。
更新 1：
- 我们正在使用
InProc会话状态模式，因为我们没有定义模式web.config 文件中的属性，并且InProc是默认值 - 如果出现 ApplicationPoolIdentity 情况，则相同的 IIS Web 应用程序在对所有用户进行手动/自动应用程序池回收后仍保留会话。这里的问题不是好坏，而是发生这种情况的原因：https://stackoverflow.com/a/4089977/218408
- 永久停止应用程序池回收对我们来说不是一个选择
答案1
首先，纠正一个错误观念，你意味着在应用程序池回收时丢失状态，除非您已将状态信息移出进程（例如，通过使用 ASP.Net 会话状态服务器、数据库或涉及持久性 cooke 的方案）。因此，除非应用程序设计为能够妥善处理回收（默认情况下并非如此），否则您可能会发现最初的假设不正确。另请参阅这个答案。
话虽如此 - 我认为这里的关键线索可能是，当应用程序以自定义用户身份运行时，你听起来像是随机丢失状态没有回收（或者显然不回收）。
这里可能发生的情况：
- 应用程序由于某种原因崩溃（导致应用程序池完全回收 - 这将显示在事件日志中）
- 由于某种原因，AppDomain 正在回收（这不会显示在事件日志中，但您可以附加日志记录，它会告诉您何时发生这种情况）
- 用户以某种方式导致上述情况发生
如果这不仅仅是应用程序以 NetworkService 派生用户身份运行时无法执行某些操作而导致其行为异常并崩溃，则用户的存在可能会导致（例如）防病毒软件或其他组织安全控制开始对机器执行某些操作（或扫描网站文件）。
因此，我会检查：
- 应用程序池回收的证据
- AppDomain 回收的证据
- 应用程序和系统日志是应用程序在会话状态丢失时出现问题的证据
- 无论是特定用户还是任何用户
- 是否可以使用调试器进行重现（或者设置 ShutdownActionExe 在关机时转储进程，并查看内存转储中发生的情况）。