自从我们的一些客户迁移到 Windows Sever 2016 以来，我们管理的 .net 应用程序发生更频繁的（硬）崩溃。
确切的设置：Windows Server 2016 文件共享提供应用程序，在 Windows Server 2016 RDS 会话（其他计算机）中启动应用程序（托管），有时会失败并显示“已停止工作”，没有例外，什么都没有。它在程序的某些部分中是可重现的，并且不是由于已知/可重现的错误造成的。
这似乎与类似的事情有关https://support.microsoft.com/en-gb/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-ar尽管它声称该问题在 WS2016 中不再存在。
网络问题和幽灵会话（用户几天/几周未注销）似乎加剧了这个问题。
我们现在将建议用户在 Windows Server 2016 RDS 机器上配置自动注销（空闲时），但目前尚无反馈表明这是否有帮助。
此类问题已知吗？有已知的解决方法吗？
答案1
我们面临着同样的问题。
Server 2008 r2 应用程序服务器将应用程序传送到 ws 2016 rds 集群。
应用程序快捷方式从服务器 2008 r2 应用服务器上的共享重定向到 RDS 用户。
为了解决这个问题，我们将 rds 2012 集群升级到 2016，因为微软对与 FCB 相关的问题的解决方案（如您上面发布的）是升级到服务器 2016。
很高兴知道它仍然可以与服务器 2016 文件服务器一起使用，因为这将是我们的下一个故障排除步骤（升级文件服务器）。
自从升级到 RDS 服务器 2016 以来，应用程序已经运行了 2 个月，没有任何问题。
今天，我们收到了“页面错误”和相同的行为，就好像我们仍然从 WS 2012 RDS 访问应用程序一样。
由于需要在 RDS 集群中的所有服务器之间重定向共享文件、每个部署许可成本（安装的每台服务器）和负载平衡，我们没有在本地运行应用程序的奢侈，所以“本地部署”对我们来说不是一个选择。
看来 2016 年 FCB 仍然存在问题。
如果确实是 FCB 问题，自动注销会使情况变得更糟，因为只要持有远程共享上的“魔术文件句柄”的用户关闭应用程序或退出 RDS，应用程序就会崩溃，许多用户都会遇到这种情况。
在服务器 2012 上，我们使用计划任务和脚本在任何用户登录之前按计时器打开应用程序，然后使用“WAIT”保持文件锁打开 24 小时，然后在一天结束时清理，重复冲洗，只是为了保持“魔术文件句柄”打开并锁定到后台进程而不是用户，但这充其量是不可靠的，并且从长远来看是不可持续的。
我们甚至使用我们的一个开发蓝色棱镜机器人在核心工作时间之前登录并打开应用程序，但由于我们的用户群是印度人，并且几乎 247 小时不间断运行，因此它无法作为长期解决方案，但如果您拥有稳定的“9 到 5”用户群并且知道人们何时会按照可靠的时间表登录和注销，那么它就是可行的。
关键是在其他用户之前打开该应用程序，并保持文件句柄处于打开状态，这是解决该问题的最佳方法。
您会注意到，应用程序在 rds 服务器上打开，但当出现此问题时，文件服务器上共享和存储管理器中看不到该 exe 的打开文件句柄，应用程序崩溃。文件服务器端的锁将消失。一旦持有与共享应用程序文件的 FCB 相关的锁的用户关闭应用程序或注销，就会出现混乱。
唯一真正指向您的是确保您的文件共享及其上的应用程序文件不在用户使用该应用程序时被快照的磁盘上 - 我已经看到这是其他服务器 2016 盒上的根本原因，但遗憾的是，这不是我们特定情况下的原因。
我们希望 WS 2016 确实能解决问题，就像广告中说的那样，但我们确信这是一个 Windows 服务器问题，尽管广告中说已在 WS 2016 中修复，但该问题仍未修复。奇怪的是，它在 WS 2016 RDS 上已经运行了 2 个月，但今天又开始出现这种情况。
我们仍在调查此事，如果您需要任何其他帮助，我们有数月的故障排除记录（尽管这主要涉及 RDS 2012）。
此外，我们可以听取其他管理员的一些指点，因为今天我们再次遇到这个问题，而且我们使用的是服务器 2016。
您的应用程序是否恰好在 NAS 上共享或通过 ISCSI 连接到应用程序服务器，并且您是否使用 GOODSYNC 对应用程序共享进行文件级备份？
本。
答案2
只是为了更新。
解决该问题的另一个更持久的方法是将 .Net 框架从 4.xx 及以上版本降级到 .Net 框架 4.0。
如果您能够做到这一点，它将会停止错误。
如果安装的 .Net 版本高于 4.5，则 FCB 问题在 2008r2 及以上版本的所有 WS OS 上更加明显
我们在实验室中对从服务器 2008r2 一直到 2016 的虚拟机进行了测试，并得出结论，该问题是从 4.0 升级到 4.5.x 或 4.xx 时引入的
对于生产环境来说，这不是一个很好的修复方法，但我们想指出的是，在我们迄今为止测试过的所有操作系统上，降级 .Net 后，该问题就会消失。
遗憾的是，我们无法实现上述操作，但根据我们的经验，它确实可以解决这个问题。
看起来 FCB 问题与所有 Windows 服务器操作系统 4.5.x 及以上版本直接相关。
去想想吧——框架中引入了一些东西导致了这个问题。
如果您使用的是 2016 并且遇到此问题，还请在事件查看器中检查您的容错堆错误日志。
如果您看到与您的应用程序相关的容错堆错误，则可以从注册表中的 FTH 中排除该应用程序，在某些情况下这也会修复崩溃。
答案3
至于我们的特定问题，每晚定期重启即可解决该问题，至少可以达到可以忍受的程度。
答案4
我的经验是，Windows 2016 Server 用户桌面环境实施正在阻止流量和/通过 Dcom 端口。在服务器集群中，集群应用程序之间会出现通信问题，而这些应用程序之间需要相互通信。由于我们在应用服务器上阻止了传出/传入流量，因此 Windowsupdate 服务会出错并同时阻止应用程序...
三年前就曾致电过 MS 帮助台，但仍然没有收到解决方案，另外我们不对第三方应用程序崩溃负责……