Blue screen of death when copying via Remote Desktop is now available on the server platform

Windows Server 2016 was released on September 30, 2016. Unfortunately, along with positive innovations came negative ones. On Windows Server, an error was successfully transferred from Windows 10 Anniversary Update, causing the remote server to crash when accessing the local path \\ tsclient via FAR Manager from it.

From the very first manifestation of this problem, I tried to draw attention to this from Microsoft, but without success. There is no solution so far.
UPDATE . The error was fixed as part of the update on 03/14/2017 in both Windows 10 and Windows Server 2016. The version of the rdbss.sys driver is 10.0.14393.953 (03/04/2017).

Problem

In the process of work, I often have to access remote computers via Remote Desktop. Sometimes you have to copy files there / back; in this case, it is quite useful to access the disks of my computer from the RDP client on the \\ tsclient \ d type path. Also it is necessary to mention that I got used to use FAR Manager.

After the Windows Anniversary Update update, released in August 2016, in which I hoped Microsoft would correct a number of its errors, the opposite happened. When accessing the \\ tsclient \ d path through FAR, the remote machine began to fall into the blue screen. Specifically, the rdbss.sys driver was guilty.
')
The problem was repeated once or twice or three, and further tests were perfectly performed on virtual machines with the operating system installed from scratch. The culprit was clearly visible when viewing the core dump.

BugCheck 27, {fcb0027c, ffffd5073f279eb8, ffffd5073f279af0, 0} Page c920 not present in the dump file. Type ".hh dbgerr004" for details Probably caused by : rdbss.sys ( rdbss! ?? ::FNODOBFM::`string'+1f09 ) nt!KeBugCheckEx rdbss! ?? ::FNODOBFM::`string'+0x1f09 (  RxSelectAndSwitchPagingFileObject) rdbss!RxCommonClose+0x126 rdbss!RxFsdCommonDispatch+0x55b rdbss!RxFsdDispatch+0x86 rdpdr!DrPeekDispatch+0x203 mup!MupStateMachine+0x1dc mup!MupClose+0x8c FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x1a6 FLTMGR!FltpDispatch+0xb6 nt!IopDeleteFile+0x12d nt!ObpRemoveObjectRoutine+0x78 nt!ObfDereferenceObjectWithTag+0xc6 nt!ObCloseHandleTableEntry+0x28f nt!NtClose+0xcb nt!KiSystemServiceCopyEnd+0x13 0x00007ffa`8c925034 

Correspondence

Well, I thought, let's go to Microsoft. Since I did not find the forms for sending messages on similar occasions (and somehow I didn’t want to get paid support request), a topic was created in the technet forum . In the message, I described the sequence in which the problem was reproduced and attached Windows dump analysis from WinDBG.

As a result, I received a response from the moderator:

According to your analysis, the problem is with “rdbss.sys”. This is the driver of the buffering subsystem of the redirected disk. Since the problem is observed on any machine, I suspect the driver is incompatible with the functionality of Windows 10 RDP. You'd better confirm this with the developer of this software.

Attempting to indicate that the developer of the rdbss.sys module in Windows 10 is Microsoft did not lead to success. “Contact the developer company; I do not have the opportunity to check it, ”writes a moderator, a Microsoft employee.

Here I thought that the problem recurs for an unprivileged user (indeed), and decided to write in the Microsoft Security Report. Microsoft takes seriously the sending of such a message - you need to send an encrypted email (S-MIME or OpenPGP with a Microsoft key) by e-mail, which will be answered within 24 hours.

Indeed, the answer was given:

Apparently, this problem is FAR Manager, not Windows 10. However, this cannot be considered a security problem, since you already have access to the system and the ability to execute code on the machine.

To the question whether it is normal, if an unprivileged user can call a BSOD, there was no answer.

When the release assemblies of Window Server 2016 appeared in which this problem was repeated, I sent another letter, paying attention to the inadmissibility of this for the server platform. The answer was similar:

Thanks for the additional information. Unfortunately, it still looks like a problem in FAR Manager. It could also be a DOS attack by a locally authenticated user, but we do not find it sufficient to provide support for security tasks.

Analysis

For the sake of interest, I looked at whether this problem manifests itself in other versions of Windows - it turns out, no. Neither in Windows 10 1511, nor in Windows Server 2016 TP5 it was observed.

A brief review of the code in WinDBG revealed a very interesting thing. The RxSelectAndSwitchPagingFileObject function, which, in fact, caused Bugcheck 0x27, did not change much compared to Windows 10 1511. But in the previous version, when errors were detected, they were simply ignored, and the call to KeBugCheckEx was explicitly added. Apparently, the developers could not fix any of their bugs and decided to work "according to the Brazilian system" - if anything, the system will simply fall, and then we will be able to find the causes of some internal (and possibly not fatal) errors.

However, the reality is a strange situation - users find this error and describe the sequence of its reproduction, and technical support is a barrier - “this is not our problem”. Developers, I suspect, the information does not reach.

In Windows Server 2016 TP5, by the way, this feature did not exist at all. However, it appeared in the release version and absolutely also causes a blue screen, as in Windows 10 Anniversary. It is worth noting that since the release of Windows Anniversary Update there have been several updates to the rdbss.sys module, but they have not solved this problem.

On the FAR Manager side, the situation is such that it actively uses the Native API, and for operations with directories it uses not the classic functions of the kernel32 module (FindFirstFile / FindNextFile), but the functions of the ntdll module (NtQueryDirectoryFile). Perhaps there is some unexpected combination of parameters / calls that the developers of rdbss.sys did not take into account (the system crashes on NtClose when the open file object is being cleared).

I hope this article will warn system administrators about the new scourge and will allow you to avoid unexpected crashes of remote servers. I also cherish the pitiful hope that Microsoft representatives present at Harbahabr will convey the necessary information to rdbss.sys developers through the “technical support” wall.