30 сентября 2016 г вышел Windows Server 2016. К сожалению, вместе с положительными новшествами пришли и отрицательные. В Windows Server успешно перенесена ошибка из Windows 10 Anniversary Update, вызывающая падение удалённого сервера при обращении из него к локальному пути \\tsclient через FAR Manager.
С самого первого проявления данной проблемы я пытался обратить на это внимание фирмы Microsoft, но безуспешно. Решения нет до сих пор.
UPDATE. Ошибка была исправлена в рамках обновления 14.03.2017 как в Windows 10, так и в Windows Server 2016. Версия исправленного драйвера rdbss.sys — 10.0.14393.953 (04.03.2017).
Проблема
В процессе работы мне часто приходится обращаться к удалённым компьютерам через Remote Desktop. Иногда приходится копировать файлы туда/обратно; при этом бывает весьма полезна возможность обратиться к дискам моего компьютера из клиента RDP по пути вида \\tsclient\d. Также нужно упомянуть, что привык пользоваться FAR Manager.
После выпущенного в августе 2016 г обновления Windows Anniversary Update, в котором, как я надеялся, компания Microsoft исправит ряд своих ошибок, произошло обратное. При обращении к пути \\tsclient\d через FAR удалённая машина стала падать в синий экран. Конкретно виновным оказался драйвер rdbss.sys.
Проблема повторялась на раз-два-три, и дальнейшие тесты прекрасно проходили на виртуальных машинах с поставленной «с нуля» операционной системой. Виновник был чётко виден при просмотре дампа ядра.
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
Переписка
Что же, подумал я, обратимся в компанию Microsoft. Поскольку форм отправки сообщений по подобным поводам я не нашёл (а заводить платный support request как-то не хотелось), была создана тема в technet forum. В сообщении я описал последовательность воспроизведения проблемы и приложил анализ дампа Windows от WinDBG.
В результате получил ответ от модератора:
По данным вашего анализа, проблема связана с «rdbss.sys». Это драйвер подсистемы буферизации перенаправленного диска. Поскольку проблема наблюдается на любой машине, я подозреваю, драйвер несовместим с функционалом Windows 10 RDP. Вам лучше подтвердить это у разработчика данного программного обеспечения.
Попытка указать, что разработчиком модуля rdbss.sys в составе Windows 10 является компания Microsoft, не привели к успеху. «Обращайтесь к компании-разработчику; у меня нет возможности это проверять», пишет модератор, сотрудник Microsoft.
Здесь я подумал, что проблема повторяется и для непривилегированного пользователя (действительно), и решил написать в Microsoft Security Report. К отправке подобного сообщения Microsoft относится серьёзно — по электронной почте нужно отправить зашифрованное письмо (S-MIME или OpenPGP с ключом Microsoft), на которое дадут ответ в течении суток.
Действительно, ответ дали:
Видимо, эта проблема FAR Manager, а не Windows 10. Однако это нельзя считать проблемой безопасности, поскольку вы уже имеете доступ к системе и возможность выполнять код на машине.
На вопрос, нормально ли, если непривилегированный пользователь может вызвать BSOD, ответа не было.
Когда появились релизные сборки Window Server 2016, в которой повторилась данная проблема, я отправил ещё одно письмо, обращающее внимание на недопустимость подобного для серверной платформы. Ответ был аналогичным:
Спасибо за дополнительную информацию. К сожалению, это всё ещё похоже на проблему в FAR Manager. Также это могло бы являться DOS-атакой локально аутентифицированного пользователя, но мы не находим это достаточным для обеспечения поддержки в рамках задач безопасности.
Анализ
Ради интереса я посмотрел, проявляется ли эта проблема в других версиях Windows – оказывается, нет. Ни в Windows 10 1511, ни в Windows Server 2016 TP5 она не наблюдалась.
Краткий обзор кода в WinDBG выявил весьма интересную вещь. Функция RxSelectAndSwitchPagingFileObject, которая, собственно, и вызывала Bugcheck 0x27, не сильно изменилась по сравнению с Windows 10 1511. Но в предыдущей версии при обнаружении ошибок они просто игнорировалась, а в новой был явно добавлен вызов KeBugCheckEx. Видимо, разработчики никак не могли исправить какие-то свои баги и решили работать «по бразильской системе» — если что, то система просто упадёт, и тогда удастся найти причины каких-то внутренних (возможно, и не фатальных) ошибок.
Однако в реальности получается странная ситуация — пользователи находят данную ошибку и описывают последовательность её воспроизведения, а техническая поддержка стоит барьером — «это не наша проблема». До разработчиков, подозреваю, информация так и не доходит.
В Windows Server 2016 TP5, кстати, этой функции вообще не было. Однако в релизной версии она появилась и абсолютно также вызывает синий экран, как и в Windows 10 Anniversary. Стоит отметить, что с выхода Windows Anniversary Update было несколько обновлений модуля rdbss.sys, но данную проблему они не решили.
Со стороны FAR Manager ситуация такова, что он активно использует Native API, и для операций с каталогами использует не классические функции модуля kernel32 (FindFirstFile/FindNextFile), а функции модуля ntdll (NtQueryDirectoryFile). Возможно, здесь и получается какая-то неожиданная комбинация параметров/вызовов, которую разработчики rdbss.sys не учли (система падает на NtClose, когда идёт очистка открытого объекта файла).
Надеюсь, данная статья предупредит системных администраторов о новой напасти и позволит избежать неожиданных падений удалённых серверов. Также лелею жалкую надежду, что представители Microsoft, присутствующие на Harbahabr, донесут необходимую информацию до разработчиков rdbss.sys через стену «технической поддержки».
