Что означает событие с Win32_Processor
Полный текст сообщает, что WMI не смогла повторно активировать фильтр с запросом вида SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99. Фильтр должен раз в 60 секунд отслеживать изменение данных процессора и срабатывать при загрузке выше 99 процентов.
Код 0x80041003 соответствует WMI-ошибке WBEM_E_ACCESS_DENIED — операции отказано в доступе. Это может происходить, когда подписка создана с неподходящими правами, её владелец удалён, изменена защита пространства имён или после удаления программы осталась неполная регистрация.
Сам текст не говорит, что процессор всё время работает на 100 процентах. Условие лишь записано внутри запроса, который сейчас не запускается. Посмотрите фактическую загрузку в Диспетчере задач. Если она нормальная, не меняйте охлаждение и питание на основании одной записи журнала.
WMI, или Windows Management Instrumentation, предоставляет системным приложениям сведения об оборудовании и событиях. Постоянная подписка состоит из __EventFilter, потребителя события и привязки __FilterToConsumerBinding. Фильтр выбирает событие, потребитель выполняет действие, а привязка соединяет их. Записи обычно хранятся в пространстве root\subscription, хотя запрос наблюдает классы в root\cimv2.
Однократное старое событие без симптомов можно оставить. Повторяющаяся ошибка при каждом запуске, сбой управляющей программы или неизвестный потребитель требуют проверки. Не удаляйте весь репозиторий WMI ради одной подписки.
Как проверить повторяемость и источник ошибки
Откройте «Просмотр событий» и перейдите в «Журналы приложений и служб» → Microsoft → Windows → WMI-Activity → Operational. Найдите событие по времени и скопируйте его идентификатор, ClientProcessId, User и полный запрос, если поля есть. Затем сравните время с установкой или удалением программ.
Откройте «Диспетчер задач» → «Подробности» и сопоставьте ClientProcessId с процессом, если он ещё работает. PID меняется после перезапуска, поэтому старый номер не всегда найдётся. Не завершайте случайный svchost.exe: внутри него работают разные системные службы.
Проверьте, возникает ли событие после чистой загрузки. Отключите сторонние элементы автозапуска в Диспетчере задач, а службы скрывайте и отключайте группами через msconfig, предварительно отметив «Не отображать службы Microsoft». Если ошибка исчезла, возвращайте компоненты по группам и определите программу-владельца.
Посмотрите список недавно установленных утилит мониторинга CPU, разгона, удалённого управления, антивирусов и фирменных центров поддержки. Такой фильтр логично мог использоваться для реакции на полную загрузку. Обновите обнаруженную программу с официального сайта или корректно удалите её через «Установленные приложения».
Не скачивайте готовый .vbs или .bat, который обещает удалить ошибку одной кнопкой. Старые сценарии часто рассчитаны на конкретное имя фильтра и без проверки удаляют экземпляры WMI. На современной системе одинаковый текст может принадлежать другому приложению.
Проверка системных компонентов и репозитория WMI
Создайте точку восстановления и сохраните важные данные. Откройте Терминал от имени администратора и выполните DISM /Online /Cleanup-Image /RestoreHealth. После успешного завершения запустите sfc /scannow. Перезагрузите компьютер и проверьте, появилось ли новое событие, а не старое в журнале.
Проверьте состояние службы «Инструментарий управления Windows». Тип запуска обычно не следует менять вручную. Служба может перезапускаться вместе с зависимыми компонентами, поэтому не удаляйте её и не переименовывайте папку Repository.
Для проверки согласованности репозитория выполните в административном Терминале winmgmt /verifyrepository. Результат «WMI repository is consistent» означает, что массовое восстановление не требуется. Ошибка отдельного фильтра при согласованном репозитории решается поиском подписки и её владельца.
Если проверка официально сообщает о несогласованности, используйте winmgmt /salvagerepository. Команда снова проверяет репозиторий и при подтверждённой проблеме перестраивает его, стараясь объединить читаемое содержимое. После неё перезапустите компьютер и повторите проверку.
Не начинайте с winmgmt /resetrepository и не удаляйте файлы Repository вручную. Полный сброс возвращает WMI к начальному состоянию и может удалить регистрации сторонних приложений, нарушив управление антивирусом, драйверами и корпоративными агентами. Такая мера оправданна только по плану восстановления и после резервной копии.
Как найти постоянный фильтр без удаления
Откройте PowerShell от имени администратора. Для чтения фильтров выполните Get-CimInstance -Namespace root/subscription -ClassName __EventFilter | Select-Object Name, EventNamespace, Query. Найдите строку, где Query содержит Win32_Processor и LoadPercentage. Запишите точное Name и EventNamespace.
Затем просмотрите потребителей командами Get-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer и Get-CimInstance -Namespace root/subscription -ClassName ActiveScriptEventConsumer. Обратите внимание на Name, CommandLineTemplate, ExecutablePath и ScriptFileName. Ничего не запускайте из найденных путей.
Список привязок показывает команда Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding | Select-Object Filter, Consumer. Сопоставьте нужный фильтр с потребителем. Сохраните вывод в текстовый файл на рабочем столе, чтобы при необходимости передать специалисту. Эти команды читают конфигурацию и сами ничего не удаляют.
Если потребитель указывает на известную установленную программу, сначала обновите или удалите её штатным деинсталлятором. После перезапуска проверьте, исчезли ли фильтр и событие. Оставшуюся запись следует удалить только адресно вместе с её привязкой, предварительно экспортировав сведения и подтвердив, что другое ПО её не использует.
Для управляемого рабочего компьютера перед изменением root\subscription обратитесь к администратору. Агент мониторинга или защиты мог создать подписку по политике и восстановит её автоматически. Самовольное удаление нарушит контроль устройства, даже если запись кажется странной.
Проверка безопасности и реальной причины выключений
Постоянные WMI-потребители используются как легальными программами, так и вредоносным ПО для автозапуска. Запустите полную проверку «Безопасностью Windows», обновив определения. При серьёзном подозрении используйте автономную проверку Microsoft Defender, которая перезагружает компьютер и сканирует до обычного входа.
Если антивирус сообщает risktool.bitcoinminer что это, не считайте запись WMI единственным доказательством. Сохраните имя детекта и путь, поместите объект в карантин, выполните автономную проверку и смените пароли с чистого устройства при признаках компрометации. Не восстанавливайте файл только потому, что он назывался «мониторингом».
Подозрительны потребители, запускающие PowerShell со скрытым окном, скрипт из временной папки, неизвестный EXE в профиле пользователя или сетевую команду. Но путь сам по себе не доказывает вредоносность. Проверьте цифровую подпись, издателя, хеш и связь с установленной программой.
Если компьютер действительно выключается при нагрузке, ошибка фильтра обычно является сопутствующей записью, а не причиной. Проверьте температуры CPU и GPU, блок питания, журнал Kernel-Power, аппаратные ошибки WHEA и стабильность памяти. Внезапное отключение без завершения работы чаще связано с питанием, перегревом или аппаратной защитой.
После исправления не очищайте журнал сразу. Перезагрузите компьютер, создайте контролируемую нагрузку и убедитесь, что новые события 0x80041003 не появляются. Затем сохраните диагностические данные и только после этого при желании очистите старые записи.
FAQ
Код 0x80041003 означает вирус?
Нет. Это WMI-ошибка отказа в доступе. Её может вызвать остаток легальной программы, изменение прав или повреждение регистрации. Проверка безопасности нужна потому, что постоянные WMI-подписки также могут использоваться для закрепления вредоносного ПО.
Нужно ли удалять фильтр Win32_Processor?
Только если вы нашли его потребителя, подтвердили, что программа больше не нужна, и штатное удаление не очистило подписку. Не удаляйте все __EventFilter и __FilterToConsumerBinding: среди них могут быть системные и корпоративные компоненты.
Поможет ли сброс репозитория WMI?
При согласованном репозитории — обычно нет. Сначала выполните winmgmt /verifyrepository, DISM и SFC. salvagerepository применяют при подтверждённой несогласованности, а полный сброс оставляют как крайнюю меру по плану восстановления.
Может ли это событие выключать компьютер?
Сам неактивированный фильтр обычно лишь создаёт запись в журнале. Для внезапных выключений проверяют питание, температуры, WHEA, память и Kernel-Power. Сопоставляйте события по времени, а не назначайте причиной первую найденную ошибку.
