Синій екран смерті при копіюванні через Remote Desktop тепер доступний і на серверній платформі



30 вересня вийшов Windows Server 2016. На жаль, поряд з позитивними нововведеннями прийшли і негативні. У Windows Server успішно перенесена помилка Windows 10 Anniversary Update, що викликає падіння віддаленого сервера при зверненні з нього до локального шляху \\tsclient через FAR Manager.

З самого першого прояву даної проблеми я намагався звернути на це увагу фірми Microsoft, але безуспішно. Рішення немає до цих пір.

Проблема
У процесі роботи мені часто доводиться звертатися до віддалених комп'ютерів через Remote Desktop. Іноді доводиться копіювати файли туди/назад; при цьому буває досить корисна можливість звернутися до дисків мого комп'ютера з клієнта RDP по шляху виду \\tsclient\d. Також потрібно згадати, що звик користуватися FAR Manager.

Після оновлення 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
відомстві!MupStateMachine+0x1dc
відомстві!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 через стіну «підтримки».
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.