Windows DCOM 10016 и Docker: как различить ошибки localhost

Автор: Казачкин Даниил Михайлович · Обновлено 29 сентября 2026 г.

Длинное событие Windows о «разрешении локальной активации для COM-сервера» содержит слова localhost и «контейнер приложения». Из-за них его легко принять за ошибку контейнерной сети Docker. Сначала определим источник события: DistributedCOM использует COM/DCOM Windows, а Linux-контейнеры Docker Desktop работают через другую инфраструктуру. Совпадение слова не устанавливает причинную связь.

Какие записи имеются в виду

В Event Viewer можно встретить сообщения о локальном запуске или активации с CLSID/APPID и такими значениями:

Текст также может называть NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\SYSTEM (локализованное «СИСТЕМА») или NT AUTHORITY\NETWORK SERVICE, их SID S-1-5-19, S-1-5-18, S-1-5-20, адрес LocalHost и LRPC. Это сведения о Windows-контексте вызова. Ни GUID, ни AppContainer SID Unavailable не являются именем Docker-контейнера или опубликованным TCP-портом.

Что подтверждает Microsoft, а что ещё нужно выяснить

Microsoft описывает конкретные события 10016, в том числе первую пару GUID выше, как ожидаемый результат попытки доступа с последующим другим способом обращения. Для описанных в статье случаев рекомендовано не менять разрешения ради устранения записи: функциональность не страдает. Это не универсальное заключение о любом GUID, любой версии Windows и любом сбое приложения. Официальная статья Microsoft.

Для WscDataProtection и третьей пары сначала сохраните provider, Event ID, время и наблюдаемую неисправность. Само наличие похожего сообщения не доказывает, что нужно раздавать права DCOM или менять владельца веток реестра. Если компонент действительно не работает, расследуйте именно его с документацией соответствующей версии Windows.

Посмотреть недавние события без изменения системы

В PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-DistributedCOM'
    Id = 10016
    StartTime = (Get-Date).AddHours(-2)
} -MaxEvents 20 | Select-Object TimeCreated, Id, ProviderName, Message

Если совпадений нет, это результат фильтра, а не поломка команды. Для чтения некоторых журналов требуются подходящие разрешения. Не экспортируйте весь журнал без просмотра имён пользователей и компьютеров. Фильтрация Get-WinEvent.

Отдельно проверить Docker Desktop

Запишите время сбоя Docker, затем выполните docker version, docker info, docker context show в той же среде, где запускается проект. Если Engine отвечает, запустите небольшой известный контейнер и проверьте его логи. Для проблемы опубликованного порта сверяйте docker port, listener приложения и фактический адрес клиента по [уроку ports](/lessons/without-university/docker-containerization/docker-developer-21).

Если Desktop не стартует, используйте его штатную диагностику и журналы, сопоставьте backend WSL и системные события по времени. Событие DCOM, появившееся одновременно, пока лишь корреляция: для причинного вывода нужно показать, какой вызов мешает конкретному действию. Диагностика Docker Desktop.

Задание: два независимых сигнала

Составьте отчёт из двух частей: точное Windows-событие и отдельно воспроизводимый сценарий Docker. Для каждого запишите источник, время, действие пользователя и проверяемый результат. Если Docker исправен, не меняйте DCOM ACL ради исчезновения предупреждения. Если Docker неисправен, ищите подтверждающие сообщения его компонентов. Урок закрывает вопрос «это ошибка Docker или Windows?» до любых действий с разрешениями; он не обещает универсального исправления реестра для перечисленных GUID.