自从我们的一些客户迁移到 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 机器上配置自动注销（空闲时），目前还没有关于这是否有帮助的反馈。
这种问题是已知的吗？有任何已知的解决方法吗？
我们面临着同样的问题。
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 个，因此作为长期解决方案是不可行的，但是如果您有一个稳定的“朝九晚五”的用户群，并且知道人们何时会按照可靠的时间表登录和注销，那么它就可以工作。
关键是在任何其他用户之前打开应用程序，并保持文件句柄打开，这是解决此问题的最佳方法。
您会注意到该应用程序在 rds 服务器上打开，但当发生此问题时，相关用户在文件服务器上的共享和存储管理器中的 exe 中看不到打开的文件句柄，并且应用程序崩溃。文件服务器端的锁将消失。一旦持有与共享应用程序文件的 FCB 相关的锁的用户关闭应用程序或注销，混乱就会随之而来。
唯一真正指向您的是确保您的文件与其上的应用程序文件共享不在用户使用该应用程序时正在快照的磁盘上 - 我已经看到这是其他服务器 2016 框的根本原因，但遗憾的是，这不是我们特定情况下的原因。
我们希望 WS 2016 实际上是解决方案，正如所宣传的那样，但我们相信这是一个 Windows 服务器问题，尽管被宣传为已在 WS 2016 中得到修复，但仍未得到修复。奇怪的是它已经为我们工作了 2 个月WS 2016 RDS，但今天又开始了。
我们仍在调查此问题，如果您需要任何其他帮助（尽管这主要与 RDS 2012 相关），我们会提供数月的故障排除说明。
此外，我们可以参考其他管理员的一些建议，因为我们今天再次面临这个问题，而且我们使用的是 2016 年服务器。
您的应用程序是否有机会在 NAS 上共享或通过 ISCSI 连接到应用程序服务器，您是否使用 GOODSYNC 进行应用程序共享的文件级备份？
本。
只是为了更新。
另一个更永久的解决方法是将 .Net framework 从 4.xx 及更高版本降级到 .Net framework 4.0。
如果您处于能够执行此操作的位置，它将阻止错误。
如果安装的 .Net 高于 4.5，则 FCB 问题在 2008r2 以上的所有 WS 操作系统上更为明显
我们在实验室中测试了从服务器 2008r2 一直到 2016 年的虚拟机，可以得出结论，问题是从 4.0 升级到 4.5.x 或 4.xx 时引入的
对于生产环境来说，这不是一个很好的工作修复，但我想把它扔在那里，在我们迄今为止测试过的所有操作系统上为我们降级 .Net 时，这个问题就消失了。
遗憾的是，我们无法实施上述内容，但根据我们的经验，它肯定会解决这个问题。
看起来 FCB 问题与所有 Windows 服务器操作系统上的 4.5.x 及更高版本直接相关。
去图 - 导致问题的框架中引入了一些东西。
如果你在 2016 年遇到了这个问题，也可以在事件查看器中检查容错堆错误日志。
如果您看到与您的应用程序相关的容错堆错误，则可以在注册表中将应用程序从 FTH 中排除，这在某些情况下也可以修复崩溃。
至于我们的特殊问题，计划的每晚重启修复了它，至少到了可以忍受的程度。
我的经验是 windows 2016 服务器 userdesktop envoirement 实现阻止流量和/通过 Dcom 端口。在服务器集群中，一个人会遇到集群应用程序的通信问题，因为这些应用程序彼此之间无法进行通信。由于我们阻止了应用程序服务器上的传出/传入流量，因此 windowsupdate 服务出现错误并同时阻止应用程序......
3 年前曾在 MS 服务台打过电话，但仍未收到解决方案，否则我们不对第三方的应用程序崩溃负责...