Microsoft подтвердила, что июньские обновления безопасности за 2026 год ломают привычный сценарий удаления файлов: при окончательном удалении объекта из Корзины Windows система показывает не исходное имя, а внутренний служебный идентификатор вроде $Rxxxxx.ext. Для обычного пользователя это выглядит как мелкий визуальный сбой, но для админов, техподдержки и корпоративных ИТ-команд баг Корзины Windows означает лишнюю путаницу в базовой операции, которая вообще-то не должна требовать расшифровки.
О проблеме, как пишет BleepingComputer, Microsoft сообщила 19 июня 2026 года в обновлении панели Windows release health. Сценарий сбоя очень конкретный: если пользователь удаляет один элемент из Корзины без возможности восстановления, в окне подтверждения показывается не исходное имя файла, а его внутреннее имя, которое Windows использует внутри Корзины. При этом сама Корзина по-прежнему отображает правильное имя, и восстановление файла тоже возвращает его под исходным названием. То есть данные не портятся и файл не «переименовывается» навсегда, но интерфейс в критический момент сообщает пользователю не то, что он ожидает увидеть.
Отдельно неприятно то, что история не ограничивается одной веткой Windows 11. По данным Microsoft, баг затрагивает все поддерживаемые версии Windows на клиентских и серверных платформах после установки июньских security updates. В клиентский список попали Windows 11 версий 26H1, 25H2, 24H2 и 23H2, Windows 10 22H2, а также Windows 10 Enterprise LTSC 2021, LTSC 2019 и LTSB 2016. На серверной стороне затронуты Windows Server 2025, 2022, 2019, 2016, 2012 R2 и 2012. То есть речь не про экзотический билд для инсайдеров, а про довольно широкий срез инфраструктуры, включая машины, которые в компаниях обычно живут долго и обновляются по строгому регламенту.
С инженерной точки зрения это не катастрофа и не инцидент класса «все срочно откатываем». Microsoft прямо говорит, что Корзина показывает оригинальное имя, а восстановление работает корректно. Но именно такие «нестрашные» дефекты обычно и создают самый утомительный слой операционного шума. Пользователь видит в диалоге подтверждения странный набор символов, пугается, делает скриншот, пишет в сервис-деск или в корпоративный чат, а дальше команда поддержки тратит время не на решение проблемы, а на объяснение, что проблема, строго говоря, ничего не ломает. Для крупных организаций с большим парком Windows-машин это означает не простои, а накопление мелких обращений и снижение доверия к очередному ежемесячному пакету обновлений.
Для разработчиков, DevOps-инженеров и системных администраторов здесь важен еще один момент. Июньские обновления 2026 года уже успели отметиться не только этим сбоем. Ранее на той же неделе Microsoft признала другую проблему: после этих обновлений сторонние приложения могли не запускать Word, Excel, PowerPoint, Access и другие приложения Office, а также не открывать документы через них. Чуть позже, тоже в четверг, компания сообщила об исправлении еще одного известного дефекта, из-за которого июньские security updates не устанавливались на Windows Server 2016, если на системе не было майского обновления KB5087537. Картина выходит довольно показательная: один и тот же пакет обновлений приносит сразу несколько побочных эффектов в разных частях экосистемы, от пользовательского интерфейса до серверного обслуживания и интеграций с Office.
Сам Microsoft называет временное решение, но не публикует его открыто. Вместо этого компания предлагает организациям обращаться в Support for business, чтобы применить workaround и смягчить проблему на затронутых устройствах. Для enterprise-среды это стандартная практика, хотя удобной ее не назовешь: если дефект массовый и официально признанный, ИТ-команды обычно предпочли бы видеть публичный и воспроизводимый сценарий обхода, а не маршрут через поддержку. Пока же в открытом доступе есть только обещание, что полноценное исправление выйдет в одном из будущих обновлений Windows. Конкретной даты Microsoft не называет.
В практическом плане это означает простую, но полезную вещь: июньские пакеты стоит сопровождать внутренним пояснением для первой линии поддержки и пользователей, особенно если в компании активно работают с файлами через стандартный Проводник Windows. Если сотрудники начнут жаловаться, что система вдруг пытается удалить «непонятный $R-файл», это не похоже на вредоносную активность само по себе и не выглядит как потеря данных. Это именно баг Корзины Windows, подтвержденный производителем. Для SOC и ИБ-команд это тоже полезная ремарка: не каждый странный системный идентификатор в интерфейсе означает компрометацию, иногда это просто неудачный побочный эффект очередного вторника обновлений.
Есть и более широкий вывод. Microsoft давно живет в режиме постоянной доставки исправлений, где безопасность, совместимость и скорость релизного цикла все чаще конфликтуют друг с другом. На бумаге баг с неправильным именем файла в диалоге удаления выглядит почти анекдотично. На практике он показывает, насколько хрупкими остаются даже самые базовые пользовательские сценарии, когда одно и то же ежемесячное обновление одновременно затрагивает клиентские редакции Windows 10 и 11, серверные выпуски и соседние продукты вроде Office. Для ИТ-отделов это еще одно напоминание: патч-менеджмент давно перестал быть задачей «накатили и забыли», а баг Корзины Windows хорошо иллюстрирует, как мелкая ошибка интерфейса быстро превращается в вполне осязаемую операционную нагрузку.