We are facing the same Issue.
Server 2008 r2 application server delivering application to a ws 2016 rds cluster.
Application shortcuts are redirected for RDS users from a share on the server 2008 r2 app server.
We upgraded our rds 2012 cluster to 2016 specifically to address this issue, as Microsoft's solution for the issue as you posted above relating to FCB, is to upgrade to server 2016.
Good to know it still does it with a server 2016 file server as well, as that was going to be our next troubleshooting step (upgrade file server).
App has worked for 2 months since upgrading to server 2016 on the RDS side of things with no issues.
Today we get the 'in page errors' and the same behaviour as if we were still accessing the app from WS 2012 RDS.
We don't have the luxury of running the application locally due to the need for shared files redirected across all servers in the RDS cluster, per deployment licencing costs (per server installed on) and load balancing, so 'deploy it locally' is not an option for us.
Looks like 2016 still has issues with FCB.
Auto logoff will make it worse if it is indeed the FCB Issue, as as soon as the user holding the 'magic file handle' on the remote share closes the app, or logs out of RDS, the app will crash for numerous users.
On server 2012, we used scheduled tasks and a script to open the application on a timer before any users logged in, and then use 'WAIT' to keep the file lock open for 24 hours, then clean down at the end of the day, rinse repeat, just to keep the 'magic file handle' open and locked to a background process and not a user, but this is flaky at best, and isn't sustainable in the long run.
We even went as far as using one of our dev blue prism robots to log in and open the app before core business hours, but as our user base is Indian, and operates almost 247 it wasn't feasible as a long term solution, but works if you have a stable '9 to 5 only' userbase and know when people will be logging on and off on a reliable schedule.
The key is opening the application before any other user does, and keeping the file handle OPEN, this is the best way to work around the issue.
You will notice the app is open on the rds server, but no open file handle is visible for the exe in share and storage manager on the file server for the user in question when this issue occurs, and the app crashes. The lock at the file server side will have vanished. As soon as the user holding the lock pertaining to the FCB for the shared app file closes the app, or logs off, chaos ensues.
only real pointer to you would be to make sure your file share with the app files on it isn't on a disk that is being snapshotted while the users are using the app - I have seen this be the root cause on other server 2016 boxes, but alas, it isn't the cause in our particular case.
We were hoping WS 2016 was actually the solution, as advertised but we are confident it's a Windows server issue that still hasn't been fixed despite being advertised as being fixed in WS 2016. It's weird that it's been working for us for 2 months on WS 2016 RDS, but has started happening again today.
We are still looking in to this, and have months worth of troubleshooting notes on this if you need any other help (although this pertains to RDS 2012 primarily).
Also, we could do with some pointers from other admins, as we are facing this again as of today, and we are on server 2016.
Is your app share on a NAS by any chance or connected to the app server by ISCSI , and are you using GOODSYNC for file level backups of the app share at all?