The 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, negative innovations came along with positive innovations. An error from Windows 10 Anniversary Update was successfully transferred to Windows Server, causing a remote server to crash when accessing the local \\ tsclient path through FAR Manager from it.

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

Problem

In the process, I often have to access remote computers through Remote Desktop. Sometimes you have to copy files back and forth; it can be very useful to access the disks of my computer from the RDP client along the path of the form \\ tsclient \ d. You also need to mention that I'm used to using FAR Manager.

After the Windows Anniversary Update, released in August 2016, in which, I hoped, Microsoft would fix some of its errors, the opposite happened. When accessing the path \\ tsclient \ d via FAR, the remote machine began to fall into the blue screen. The rdbss.sys driver turned out to be specifically guilty.

The problem was repeated one-two-three, and further tests went fine on virtual machines with the operating system delivered from scratch. The culprit was clearly visible when viewing a 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 turn to Microsoft. Since I did not find forms for sending messages on similar occasions (I somehow did not want to start a paid support request), a topic was created in the technet forum . In the message, I described the playback sequence of the problem and attached the analysis of the Windows dump from WinDBG.

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

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

An attempt 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 don’t have the opportunity to check this, ”writes a moderator, a Microsoft employee.

Here I thought that the problem was repeated for the unprivileged user (really), and decided to write in the Microsoft Security Report. Microsoft is serious about sending such a message - you need to send an encrypted letter (S-MIME or OpenPGP with a Microsoft key) via 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.

When asked whether it is normal if an unprivileged user can call BSOD, there was no answer.

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

Thanks for the additional information. Unfortunately, this 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 to see if this problem manifests itself in other versions of Windows - it turns out, no. Neither in Windows 10 1511 nor in Windows Server 2016 TP5 was it observed.

A brief review of the code in WinDBG revealed a very interesting thing. The function RxSelectAndSwitchPagingFileObject, which, in fact, caused Bugcheck 0x27, did not change much compared to Windows 10 1511. But in the previous version, they were simply ignored when errors were detected, and the KeBugCheckEx call was explicitly added in the new version. Apparently, the developers could not fix their bugs in any way and decided to work “according to the Brazilian system” - if that is the case, the system will simply crash, and then it will be possible 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." I suspect that the information does not reach the developers.

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

From the side of FAR Manager, the situation is that it actively uses the Native API, and for directory operations it uses not the classic kernel32 module functions (FindFirstFile / FindNextFile), but ntdll module functions (NtQueryDirectoryFile). Perhaps here we get some unexpected combination of parameters / calls that the developers of rdbss.sys did not take into account (the system crashes to NtClose when the open file object is being cleaned).

I hope this article will warn system administrators of a new misfortune and will help to avoid unexpected crashes of remote servers. I also cherish the pathetic hope that the Microsoft representatives present at Harbahabr will bring the necessary information to the rdbss.sys developers through the "technical support" wall.