Синій екран смерті при копіюванні через Remote Desktop тепер доступний і на серверній платформі
З самого першого прояву цієї проблеми я намагався звернути на це увагу фірми Microsoft, але безуспішно. Рішення немає досі.
У процесі роботи часто доводиться звертатися до віддалених комп'ютерів через Remote Desktop. Іноді доводиться копіювати файли туди/назад; при цьому буває дуже корисна можливість звернутися до дисків мого комп'ютера з клієнта RDP шляхом виду \\tsclient\d. Також потрібно згадати, що звик скористатися FAR Manager.
Після оновлення Windows Anniversary Update, в якому, як я сподівався, компанія Microsoft виправить низку своїх помилок, сталося протилежне. При зверненні до шляху \\tsclient\d через FAR віддалена машина почала падати в синій екран. Саме винним виявився драйвер rdbss.sys.
Що ж, подумав я, звернемося до компанії 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, коли відбувається очищення відкритого об'єкта файлу).
Ви можете допомогти і перевести небагато коштів на розвиток сайту