Сообщение error description not available появляется в Журнале событий Windows, консолях управления, логах служб и сторонних приложений, когда система получает код ошибки, но не может найти для него текстовое описание. Это не отдельная неисправность, а признак того, что программа знает номер сбоя, но не знает, как его расшифровать.
Проблема осложняет диагностику: вместо понятного пояснения пользователь видит пустую заглушку. Однако сам код ошибки при этом сохраняется, и по нему можно восстановить полную картину. Ниже разберём, почему описание теряется, где искать расшифровку и какие шаги помогают устранить первопричину.
Почему система не показывает описание ошибки
Текстовые описания ошибок в Windows хранятся в библиотеках сообщений — файлах DLL и ресурсах MUI. Когда программа вызывает функцию получения описания (например, FormatMessage), система ищет текст по коду ошибки в этих ресурсах. Если ресурс отсутствует, повреждён или не зарегистрирован, на выходе получается заглушка «description not available».
Типичные ситуации, в которых это происходит:
- 🔧 Программа была удалена или обновлена, а её библиотека сообщений пропала вместе с ней — журнал событий больше не может найти текст.
- 🌐 Ошибка пришла от сетевого устройства или удалённого сервера, чьи ресурсы сообщений недоступны локальной машине.
- 🗂️ Повреждены системные файлы Windows, отвечающие за локализацию и хранение строк.
- 📦 Приложение использует собственные коды ошибок, но разработчик не включил для них текстовые описания.
Отсутствие описания не означает, что ошибка несерьёзна. Часто за такой заглушкой скрываются сбои драйверов, служб или оборудования, которые требуют внимания.
Где чаще всего встречается это сообщение
Чаще всего пользователи замечают фразу в Просмотре событий (eventvwr.msc) — в свойствах записи вместо текста отображается «the description for Event ID cannot be found» или её аналог. Это происходит, когда источник события ссылается на файл сообщений, которого нет в системе.
Вторая типичная точка — журналы стороннего ПО: антивирусов, систем резервного копирования, серверных приложений. Программа фиксирует числовой код, но не поставляет словарь расшифровки, особенно в бесплатных или устаревших версиях.
Третий сценарий — WMI и скрипты администрирования. Запросы Get-WinEvent или wbemtest могут вернуть код без описания, если репозиторий WMI повреждён или не содержит нужного провайдера.
Как найти расшифровку по коду ошибки
Ключ к разгадке — числовой код, который почти всегда присутствует рядом с заглушкой. Его нужно скопировать и проверить по открытым источникам. Для системных кодов Windows существуют официальные таблицы Win32 error codes и HRESULT, опубликованные в документации Microsoft.
Для быстрой проверки системного кода можно использовать встроенную команду. Откройте командную строку и выполните:
net helpmsg КОД_ОШИБКИНапример, net helpmsg 5 вернёт «Отказано в доступе». Команда работает только для стандартных системных кодов — для кодов конкретных приложений она бесполезна.
Если ошибка относится к конкретной программе, ищите расшифровку в её документации или базе знаний разработчика. Многие вендоры публикуют списки собственных кодов отдельно от системных.
Пошаговая диагностика в Просмотре событий
Когда заглушка появляется в Журнале событий, действуйте последовательно, от простого к сложному.
☑️ Диагностика события без описания
Откройте проблемное событие и перейдите на вкладку Подробности, выберите режим XML. В нём сохраняются поля EventID, Provider Name и бинарные данные, которые не зависят от отсутствующего текстового ресурса. Именно эти поля дают реальную информацию о сбое.
Далее проверьте, существует ли программа, указанная в поле Провайдер. Если приложение удалено, а события продолжают появляться, возможно, в системе осталась работающая служба или драйвер этого ПО. Полная переустановка или чистое удаление программы обычно прекращает поток таких записей.
⚠️ Внимание: не удаляйте записи о регистрации источников событий из реестра вручную, если не уверены в последствиях. Некорректная правка ветки HKLM\SYSTEM\CurrentControlSet\Services\EventLog может нарушить работу журналирования всей системы.
Восстановление системных файлов и WMI
Если описания пропали у множества событий разных источников, вероятная причина — повреждение системных ресурсов Windows. В этом случае стоит выполнить стандартную проверку целостности. Запустите командную строку от имени администратора и выполните по очереди:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
Первая команда проверяет и восстанавливает защищённые системные файлы, вторая — исправляет хранилище компонентов, из которого SFC берёт исправные копии. После завершения обеих операций перезагрузите компьютер и проверьте, появились ли описания у новых событий.
Если проблема затрагивает только запросы WMI, возможная причина — повреждённый репозиторий. Диагностику можно начать с команды winmgmt /verifyrepository. Восстановление репозитория — более рискованная операция, и перед ней стоит создать точку восстановления системы.
⚠️ Внимание: сброс репозитория WMI командой winmgmt /resetrepository удаляет пользовательские расширения классов, добавленные сторонними программами. Выполняйте её только после того, как проверка не помогла, и при наличии резервной копии системы.
Сравнение источников расшифровки кодов
Разные коды ошибок требуют разных справочников. Таблица ниже поможет выбрать правильный источник.
| Тип кода | Где искать описание | Пример формата |
|---|---|---|
| Системные Win32 | Команда net helpmsg, документация Microsoft | 5, 87, 10013 |
| HRESULT | Официальная таблица кодов HRESULT | 0x80070005 |
| Коды состояния NTSTATUS | Документация для разработчиков Windows | 0xC0000005 |
| Коды приложений | База знаний разработчика программы | Зависит от вендора |
| События Event ID | Поиск по сочетанию «источник + ID» | Event ID 1001 |
Почему один и тот же код выглядит по-разному
Одно и то же значение может записываться в десятичном и шестнадцатеричном виде. Например, HRESULT 0x80070005 соответствует системной ошибке 5 (отказано в доступе): младшие 16 бит кода 0x0005 — это и есть Win32-код. При поиске пробуйте оба формата.
Когда проблема на стороне разработчика
Иногда отсутствие описания — недоработка самой программы. Разработчик регистрирует источник событий, но не включает файл сообщений в установщик или не локализует строки. В таком случае ни одна системная проверка ситуацию не исправит.
Что можно сделать пользователю:
- 🔄 Обновите программу до актуальной версии — в новых сборках файл сообщений может быть добавлен.
- 📩 Сообщите о проблеме в поддержку разработчика, приложив код события и версию ПО.
- 🧭 Используйте код и контекст события (время, действие перед сбоем) как основу для поиска, даже без текстового описания.
Если событие появляется регулярно и совпадает с конкретным действием — запуском программы, подключением устройства, выходом из сна — фиксируйте эту закономерность. Она часто важнее текста описания для поиска решения.
Часто задаваемые вопросы
Опасна ли ошибка «error description not available»?
Сама по себе заглушка безопасна — это лишь отсутствие текстового пояснения. Опасность определяется скрытым за ней кодом: одни события информационные, другие указывают на сбои драйверов или оборудования. Расшифруйте код, чтобы оценить серьёзность.
Почему в Просмотре событий нет описания у многих записей?
Наиболее вероятные причины: программа-источник была удалена или обновлена, повреждены системные файлы, либо разработчик не включил файл сообщений в дистрибутив. Начните с проверки sfc /scannow и анализа источников событий.
Как расшифровать код вида 0x80070005?
Это формат HRESULT. Младшие разряды указывают на системный код — в данном случае 5, то есть «отказано в доступе». Проверить можно командой net helpmsg 5 или по официальным таблицам кодов Microsoft.
Поможет ли переустановка программы вернуть описания событий?
Да, если причина в отсутствующем или повреждённом файле сообщений этой программы. Переустановка регистрирует источник событий заново вместе с его ресурсами. Если проблема на уровне Windows, переустановка приложения не поможет.
Можно ли игнорировать такие записи в журнале?
Можно, если событие имеет уровень «Сведения» и не связано со сбоями в работе. Записи с уровнями «Ошибка» и «Критическая» игнорировать не стоит — расшифруйте их коды и устраните первопричину.