The windows management instrumentation service has detected an inconsistent system shutdown

I have a windows 2008 R2 server, which was configured and installed by a 3rd party vendor.  EVerytime the server is rebooted, we are prompted to supply the reason for the unexpected shutdown.  It's a dell server and Dell openmanage indicates a normal shutdown/restart. In combing through the event logs i find this error message "The Windows Management Instrumentation Service has detected an inconsistent system shutdown.
  • Remove From My Forums

  • Question

  • I have a windows 2008 R2 server, which was configured and installed by a 3rd party vendor.  EVerytime the server is rebooted, we are prompted to supply the reason for the unexpected shutdown.  It’s a dell server and Dell openmanage indicates a
    normal shutdown/restart. In combing through the event logs i find this error message «The Windows Management Instrumentation Service has detected an inconsistent system shutdown.

    I’ve googled this and not found a lot of info.  I am at a loss as where to begin my troubleshooting.  Any direction is appreciated.

    • Moved by

      Monday, June 28, 2010 5:34 AM
      (From:Windows Server 2008 R2 General)

Answers

  • Hi Betty,

    How did you reboot the server, remotely or locally on the server?

    Please ensure the
    Remote Registry service has been started if you shut down the computer remotely. A registry key value tells Shutdown Event Tracker when to prompt a user for information about an unexpected restart or shutdown. Without remote registry access,
    Shutdown Event Tracker cannot remotely reset this registry key value after you have provided a reason.

    When Shutdown Event Tracker is enabled, users cannot shut down or restart the computer without providing a reason. If the computer is shut
    down or restarted unexpectedly, either as a result of power interruption or hardware failure, the first member of the local Users group to log in after the restart is prompted to enter a reason in Shutdown Event Tracker.

    Alternatively, you can disable Shutdown Event Tracker through local Group Policy settings to avoid the shutdown reason window. To do this,
    please follow these steps.

    1. Click
      Start, click in the Search box, and type
      gpedit.msc      .The Group Policy Object Editor dialog box appears.
    2. In the
      Local Computer Policy navigation pane, expand Computer Configuration, expand
      Administrative Templates, and click System.
    3. In the console pane, scroll down to the list of objects, right-click
      Display Shutdown Event Tracker, and click Properties.
    4. On the
      Settings tab, click Disabled.

    For more information about Shutdown Event Tracker, please refer to the link below.

    http://technet.microsoft.com/en-us/library/cc770960.aspx

    Regards,

    Karen Ji

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    This posting is provided «AS IS» with no warranties, and confers no rights.

    On July 1st we will be making this forum read only. After receiving a lot of feedback from the community, it was decided that this forum is a duplication
    and therefore redundant of the     General Forum. So, until July 1st, we will start asking customers to redirect their questions to the
    General Forum. On June 11th, CSS engineers will move any new threads to the
    General Forum.

    Please post a reply to
    the announcement thread if you have any feedback on this decision or the process. You can
    also email     WSSDComm@microsoft.com.

    • Marked as answer by
      Karen Ji
      Friday, July 2, 2010 5:47 AM

Источник

Я столкнулся с этой ситуацией на днях: мои студенты тестировали управление системными функциями и две машины в домене (на обеих – Windows 10) стали возвращать ошибки при работе с Windows Management Instrumentation. Основной админ ещё не вышел из отпуска, пришлось вспоминать, что я бывший руководитель Отдела ИТ :)

Сразу отвечу на третий вопрос: без рабочего WMI, на мой взгляд, можно оставлять лишь домашний игровой компьютер, на котором, кроме игр и просмотра видео, больше ничего не делается (разве что дети учатся программировать). В остальных случаях, особенно на корпоративных машинах, тем более в домене, WMI должна работать как часы. Это моё мнение, кто-то может не согласиться.

Теперь о причинах произошедшего: их может быть очень много. Забегая вперед, скажу что на одной машине это произошло из-за того, что на жестком диске закончилось место, а затем был сбой по питанию из-за сломанного ИБП (увы, никто не застрахован; сервера, конечно, защищены от подобного, а обычная рабочая машинка не была). На второй хуже: нефатальный сбой жесткого диска с последующим BSOD. В целом, разобраться с причинами не так уж и важно, главное, выяснить, что причиной не является вирус или попытка взлома. Впрочем, намеренное удаление или случайная порча системных файлов тоже должны быть рассмотрены достаточно пристально.

Восстановление работоспособности WMI следует проводить поэтапно, от щадящих методов к деструктивным. Следует быть готовым к тому, что в самом худшем случае систему придётся переустановить. Не стоит лишний раз напоминать, что большинство команд должно выполняться от имени администратора.

1 этап. Проверка работы сервиса.

Проверяем имеется ли в системе служба Windows Management Instrumentation (Winmgmt) и включена ли она. Вызываем Службы (в Windows 10 проще всего через Пуск/Средства администрирования/Службы, но я предпочитаю в любой версии Windows, кроме самых старых, напечатать в командной строке services.msc), ищем Инструментарий управления Windows/Windows Management Instrumentation, проверяем, запущена ли она:

введите сюда описание изображения

Если она не запущена, пытаемся запустить, выставим режим запуска в «Автоматически». Если запущена, пытаемся перезапустить (Остановить/запустить). После этого проверяем работоспособность WMI. Проще всего сделать это, выполнив любой WMI-запрос в powershell (напоминаю, что powershell в Windows 10 запускается через Пуск/Windows PowerShell/Windows Power Shell, но проще, на мой взгляд, запустить командную строку с админовскими правами, а в ней уже набрать powershell), например, такой: (вы можете выполнить другой, свой любимый :))

Get-WmiObject -List -ComputerName localhost

Если у вас вылетела портянка объектов, всё в порядке. Если же полезли ошибки, значит, работоспособность не восстановлена, переходим ко второму этапу.

Между делом скажу пару слов об официальной утилите Microsoft WMI Diagnosis. Все почему-то наперебой её рекомендуют, как хороший помощник при восстановлении. Увы, я убил достаточно много времени на анализ результатов действия этой утилиты: скрипт создал кучу лог-файлов, через которые продраться можно, если вы никуда не торопитесь, у вас есть куча времени и полкило пуэра/кофе-машина. В причинах сбоев я разобрался быстрее без неё. Вероятность того, что она может помочь непосредственно в скором восстановлении работы WMI – очень мала.

2 этап. Недеструктивное восстановление

Стоит попытаться вначале выполнить перерегистрацию библиотек и рекомпиляцию файлов расширения свойств объектов (Managed Object Format, MOF) и языковую составляющую этих файлов (MFL). Практически гарантированно сработает, если попытка WMI-запроса у вас вызывала ошибку вида “Ошибка в файле WMI.MOF” или любом другом MOF-файле. Для этого выполним следующие операции:

  1. Остановим службу WMI, обязательно запретив её автостарт
  2. Перерегистрируем все библиотеки в папке Windowssystem32wbem
  3. Перерегистрируем службы WMI и WMI Provider Host
  4. Запускаем службу WMI и разрешаем её автостарт
  5. Рекомпилируем MOF и MFL файлы

Можно собрать всё это в один BAT-файл и запустить:

# пункт 1
sc config winmgmt start= disabled
net stop winmgmt
# пункт 2
cd %windir%system32wbem
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
#пункт 3
wmiprvse /regserver
winmgmt /regserver
#пункт 4
sc config winmgmt start= auto
net start winmgmt
#пункт 5
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s

Отмечу, что таким образом я восстановил работу WMI на первой машине. Со второй, увы не получилось. Если у вас не получается, пора переходить к 3му этапу

3 этап. Деструктивное восстановление

Фактически, на 3м этапе мы пересоздаем хранилище WMI, как таковое, которое находится в папке WindowsSystem32WbemRepository и является базой данных, в которой хранятся данные и определения стандартных WMI-классов и статическая информация дополнительных WMI-классов, если они создавались на вашей машине.

Перед операциями проверьте состояние жёсткого диска и файловой системы!!!

Проверяем целостность (На Windows XP и ниже не работает):

winmgmt /verifyrepository

В случае ответа отличного от “База данных WMI согласована”, можно выполнить «мягкое восстановление» командой:

winmgmt /salvagerepository

с последующим перезапуском службы:

net stop Winmgmt
net start Winmgmt

Если мягкое восстановление не помогло, пробуем вернуть хранилище в начальное состояние (последствия: все дополнительные классы WMI, когда-либо зарегистрированные в вашей системе, скорее всего, придётся регистрировать заново):

winmgmt /resetrepository

с последующим рестартом системы. Отмечу, что вторая машина заработала после этого этапа. Последствия были не сильно удручающими, но серьёзными: пришлось переинсталлировать Visual Studio и Delphi Starter, MS Office отказался работать и его пришлось деинсталлировать вручную, удаляя папки, файлы и записи из реестра, с последующей повторной установкой. Также слетели все наши собственные классы WMI.

Но, если и это не помогло, придётся удалять и создавать хранилище заново. Это можно сделать следующим BAT-файлом:

# Остановим службу WMI, обязательно запретив её автостарт
sc config winmgmt start= disabled
net stop winmgmt
# проводим реинициализацию WMI
cd %windir%system32wbem
winmgmt /kill
winmgmt /unregserver
winmgmt /regserver
winmgmt /resyncperf
# создаем на всякий случай резервную копию нашего хранилища в папку WMI_VicoNT_Backup
# у вас, разумеется, может быть другое имя папки
if exist WMI_VicoNT_Backup rd WMI_VicoNT_Backup /s /q
rename Repository Repos_bakup
# воссоздаем хранилище
regsvr32 /s %systemroot%system32scecli.dll
regsvr32 /s %systemroot%system32userenv.dll
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
# запускаем службу WMI, заново регистрируем WMI Provider Host
sc config winmgmt start= auto
net start winmgmt
wmiprvse /regserver

Перегружаем компьютер. Если и после этих действий WMI не заработала, путь один – переустановка системы.

Источник

Unexpected Shutdown but a soft reboot was performed

I have a windows 2008 R2 server, which was configured and installed by a 3rd party vendor. EVerytime the server is rebooted, we are prompted to supply the reason for the unexpected shutdown. It’s a dell server and Dell openmanage indicates a
normal shutdown/restart. In combing through the event logs i find this error message «The Windows Management Instrumentation Service has detected an inconsistent system shutdown.
I’ve googled this and not found a lot of info. I am at a loss as where to begin my troubleshooting. Any direction is appreciated.

June 25th, 2010 7:09pm

Hello,
i have seen this sometimes if a machine is shutdown/rebooted via RDC instead on the server console direct. Do you have it both ways?Best regards Meinolf Weber Disclaimer: This posting is provided «AS IS» with no warranties or guarantees , and confers no rights.

June 26th, 2010 2:08pm

Hi Betty,

How did you reboot the server, remotely or locally on the server?

Please ensure the
Remote Registry service has been started if you shut down the computer remotely. A registry key value tells Shutdown Event Tracker when to prompt a user for information about an unexpected restart or shutdown. Without remote registry access,
Shutdown Event Tracker cannot remotely reset this registry key value after you have provided a reason.

When Shutdown Event Tracker is enabled, users cannot shut down or restart the computer without providing a reason. If the computer is shut
down or restarted unexpectedly, either as a result of power interruption or hardware failure, the first member of the local Users group to log in after the restart is prompted to enter a reason in Shutdown Event Tracker.

Alternatively, you can disable Shutdown Event Tracker through local Group Policy settings to avoid the shutdown reason window. To do this,
please follow these steps.

Click
Start, click in the Search box, and type
gpedit.msc.The Group Policy Object Editor dialog box appears.
In the
Local Computer Policy navigation pane, expand Computer Configuration, expand
Administrative Templates, and click System.
In the console pane, scroll down to the list of objects, right-click
Display Shutdown Event Tracker, and click Properties.
On the
Settings tab, click Disabled.

For more information about Shutdown Event Tracker, please refer to the link below.
http://technet.microsoft.com/en-us/library/cc770960.aspx

Regards,
Karen Ji

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
This posting is provided «AS IS» with no warranties, and confers no rights.

On July 1st we will be making this forum read only. After receiving a lot of feedback from the community, it was decided that this forum is a duplication
and therefore redundant of the General Forum. So, until July 1st, we will start asking customers to redirect their questions to the
General Forum. On June 11th, CSS engineers will move any new threads to the
General Forum.

Please post a reply to
the announcement thread if you have any feedback on this decision or the process. You can
also email WSSDComm@microsoft.com.

June 28th, 2010 8:34am

I receive this error when I am right at the console or when I rdp boot. The remote registry service is enabled and started. Often I am rebooting because of windows security patches, so when prompted to restart — i do. I am not
asked to supply the reason. (This is similar to my other 2008 servers but only this one gives me grief).
I will check your link about shutdown tracker and see if I can find out more info. thank you for the questions and responses.

June 29th, 2010 10:09pm

Anyone get this resolved. I am having the same issue with 2008 R2. Mine is a virtual running on esx 4 update 1.

June 30th, 2010 5:46pm

Same here. I’m running 2008 R2 virtualized on 2008 R2 Hyper-V.

August 4th, 2010 11:59pm

I still have this problem as well. I’ve opened a case with Microsoft but so far, we’ve had no luck in resolving it. They are pointing me back to Dell hardware support.

August 13th, 2010 5:00pm

I have the same issue on a 2008 R2 box without Dell hardware. Any news on this?

October 14th, 2010 10:58pm

I am also recieving this error on all of my 2008 R2 Data Center boxes running on Dell PowerEdge R710’s.Hi

November 4th, 2010 6:03pm

I’m in the same boat. For me it is occurring on my vCenter 4.1 server which is a virtual server (W2K8 R2). I performed a domain migration, pretty straight forward right? Well, the domain migration went just fine, however, every time I reboot
the server either via the console using VI client OR RDP, I get the shutdown tracker upon reboot looking for an answer as to why the server was shutdown «unexpectedly». The other thing I notice that is strange is that after all of the services
have loaded, the server does some kind of time synchronization that changes the local time of the server to be incorrect (about 30 mins slow). The mysterious part is that when the server boots and I first login to Windows the time is correctly synchronized
with the AD domain controllers. I don’t know what to make of this. It’s almost like there is some service that is restoring the system to a previous state when maybe the server wasn’t shutdown properly.

Any ideas on this would be greatly appreciated.
Thanks,
—Kevin

November 23rd, 2010 9:54pm

I’m having the same problem with the tracker once I login to any of my 2008 R2 servers, and it happens across physical and virtual systems, even when I manually shutdown and supply a reason.

@Kevin
So far as your time sync issue, double check that VMware Tools isn’t set to synchronize the servers time with the vSphere Host.

Regards,
MatthewRegards, Matthew

February 17th, 2011 8:55pm

I have the same issue on a 2008 R2 box with Intel Server hardware. Any news on this?

Thanks

February 18th, 2011 1:16am

For me, the problem was Blackberry Enterprise Server Express running on the system. I’ve installed BES on a few Windows 2008 R2 systems and they all have this shutdown issue. I opened an MS support case and was told that BES does not properly
clean up files on shutdown.

February 18th, 2011 9:25am

I’ve been building a Blackberry Enterprise Server Express system inside VMWare Workstation and after I installed BES it started doing this. BES sucks. This just confirms it. Please let me know if anybody figures out how to fix it.

February 21st, 2011 5:20pm

I opened a support case with Blackberry on this a couple of months ago, but I don’t think they’re too concerned about fixing it (or even acknowledging it). I don’t think the support person had to worry about the annoyance of shutting down a server
then checking it every time you reboot it to make sure there is not a genuine problem with the system.
Here is the fundamental reason for the problem as described to me by Microsoft:
Windows Server 2008 onward we maintain a heartbeat file to determine whether we have a clean shutdown or not. Files are LastAlive0 or LastAlive1 in C:windowsServiceProfilesLocalServiceAppDataLocal. If the LASTALIVESTAMP is present and if we can successfully
read heartbeat data, it indicates that the previous shutdown was abnormal, i.e. we didn’t execute our normal shutdown cleanup code.

For some reason lastalive0.dat and lastalive1.dat at C:windowsServiceProfilesLocalServiceAppDataLocal were not getting deleted while doing a clean shut down/Reboot.

Many cases show that Blackberry Service can cause the problem. Because Blackberry Services putting a handle lastalive file and not releasing it during shutdown process.

According to the System Information, I found that Blackberry Service is running.
Please check the following path and see if there are files called LastAlive0 or LastAlive1: C:windowsServiceProfilesLocalServiceAppDataLocal folder. If so, please stop or disable the Blackberry Services before next time you start the server, or you can
contact the company of Blackberry and see if there is an update of the service to fix this problem.

February 21st, 2011 5:30pm

I am having the same issue as the OP. At first I thought it was the pcAnywhere connection. I recommend uninstalling or stop using any type of remote connection. I believe this is the cause of the problems. We are running Windows
Server 2008 Standard 32 bit. We had it in a virtualized environment (virtualbox), but removed it since we thought VirtualBox was the culprit. We have moved onto a physical environment and continue to receive these issues. The new server is
on new hardware as well. When I restarted the server due to a Windows update, I did it via pcAnywhere, which then prompted the random restarts of the server. Try restarting the servers physically instead of remotely. Microsoft help us out.
Solve this issue, we need remote access to our servers.

March 1st, 2011 10:23am

I have noticed this after installing the VMware Tools for ESX 4.1 on my VM’d 2K8 R2 Server.

March 10th, 2011 2:32pm

I am also having this issue. At first I was concerned as this is running on an email server and the last thing you want is a dirty shutdown potentially causing further problems down the line.
I also think suggesting the Shutdown Event Tracker (SET) should be disabled is NOT a workaround to the issue. The OP clearly posted what the issue was and suggesting it should be disabled is poor advice.
The only time this should ever be suggested is when the initial SET is appearing before a reboot. This problem is whereby you fill in the first SET and then you are presented with another after reboot. There is obviously a reason for it and until
it is resolved, how do you know something more serious isn’t going to occur as a result of ignoring it?
However, since looking into this issue, in my case I am using RDP and BESE on the email server and I thought I would add my findings.
In an attempt to work out what is causing it, I manually stopped all the BlackBerry services from top to bottom in the list and then rebooted. I completed the first SET and after it did reboot and I logged on, I got no SET.
So in my case, and possibly those who are also running BESE, this sounds like an issue I’ve found elsewhere whereby the BB software is not cleanly stopping itself and leaving Windows to deduce an improper shutdown occurred. However, it sounds like RIM have
no fix and might not have even acknowledged this as an issue as yet.

March 20th, 2011 7:52am

I am having the same issue on one of our servers — which is usually just restarted due to windows update. All other servers — same procedure — do not exhibit this behaviour…

April 3rd, 2011 11:07pm

Same issue as outlined by all others above. Server generates a 6008 whether rebooted via RDP or console session, with blackberry services stopped, server reboots cleanly.
Observed on SBS 2011 Std: All MS patches applied
Exchange server 2010 v. 14.01.0218.013
Blackberry Enterprise Server Express 5.0.2.29
Any solutions found that do not require
disabling a feature intended to notify admins when there really is a problem?

May 16th, 2011 9:59pm

Источник

new computer shutting down 10minutes-1hour when playing games


  • Thread starter

    FLZ


  • Start date

    Apr 14, 2014

  • #1

hi, i recently built a new computer and it shuts down as soon as i start to play games for a while. so far it has shut down while playing metro: last light, and far cry 3

the event log says these 3 things i find to be possibly relevant

The description for Event ID 0 from source NVNetworkService cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

NVNetworkService
NetworkService in OnStart

The Windows Management Instrumentation service has detected an inconsistent system shutdown.

The winlogon notification subscriber <SessionEnv> was unavailable to handle a critical notification event.

fixes i have already tried include updating my motherboards bios and removing the nvidia shield streaming
i havent dont any overclocking yet

my pc’s bios are:
motherboard:ASUS MAXIMUS VI HERO
cpu: intel i7 4770k
gpu:ASUS GTX 780 3GB
ram: TEAM VULCAN 4gb(x2) DDR3 2400 RAM
psu:Antec HCG M HCG-850M 850W ATX12V SLI Ready CrossFire Certified 80 PLUS BRONZE Certified Modular Active PFC Power Supply
os:windows 8.1

thank you

popatim



Dec 2, 2009



38,841



963



129,290

8,725


  • #2

Step 1 is to remove all overclocks & CPU/Chipset Voltage increases.
You have some high speed ram, are they at the required voltage to operate properly?

  • #3

Step 1 is to remove all overclocks & CPU/Chipset Voltage increases.
You have some high speed ram, are they at the required voltage to operate properly?

how would i go about checking the voltage going to my ram.

all the overclocks and any adjustments are default as in stock

  • #4

please help

open hardware monitor only shows voltage on my cpu and lists the ram as «generic ram»

  • #5

bump. could it be a overheating problem or something?

Thread starter Similar threads Forum Replies Date

hollowz

Question PC Freeze and shuts down randomly Systems 1 Jan 19, 2023

G

Question Computer display shuts off after bios screen Systems 3 Jan 9, 2023

Rmay11

Question Computer shuts off randomly or display loses signal. Reboot has VGA light on motherboard on and nvme ssd not apearing in bios? Any advice what the is Systems 2 Dec 28, 2022

W

Question PC freezes constantly and can’t shut down Systems 3 Dec 27, 2022

S

Question Computer shuts down/restarts randomly Systems 4 Dec 23, 2022

S

Question Computer shuts down/restarts randomly Systems 19 Dec 15, 2022

S

Question Computer auto shuts off frequently Systems 7 Dec 14, 2022

Reavage

Question My computer keeps shutting down while gaming ? Systems 5 Dec 7, 2022

SnappyCat7000

Question Having Erratic Shutdown and Power on Issues with Computer Systems 3 Dec 2, 2022

N

Question Computer Shutting Down While Playing Demanding Games Systems 7 Nov 26, 2022

  • Advertising
  • Cookies Policies
  • Privacy
  • Term & Conditions
  • Topics

Источник

Любой бывалый Windows-админ не раз сталкивался с проблемами в работе службы WMI и ее компонентах. Наличие проблем в подсистеме WMI является критичным с точки зрения нормального функционирования системы, поэтому администратору приходится прибегать к тем или иным трюкам, позволяющим восстановить работоспособность WMI.  В этой статье мы опишем достаточно простую методику диагностирования и устранения неполадок в службе WMI.

О наличии проблем с WMI может свидетельствовать широкий спектр ошибок:

  • Ошибки обработки WMI запросов в системных журналах и логах приложений
  • Ошибки GPO, завязанные на WMI ( некорректная работа wmi фильтров политик, и пр.)
  • Ошибки в работе / невозможность установки агентов SCCM/SCOM
  • Ошибки в работе скриптов (vbs или powershell), использующих пространство имен WMI

В первую очередь нужно проверить имеется ли в системе служба Windows Management Instrumentation (Winmgmt) и включена ли она.

Если служба  присутствует и находится в состоянии Started, рекомендуется протестировать работоспособность WMI, обратившись к ней с помощью простого wmi-запроса. С помощью Powershell, например, это можно сделать так:

get-wmiobject Win32_OperatingSystem

Если при выполнении простейшего WMI-запроса система возвращает ошибку (на скриншоте приведен пример корректного ответа службы WMI), вероятно имеет место некорректное функционирование сервиса WMI или ряда его подсистем, повреждение репозитория WMI или другие проблемы.

Утилита WMIDiag

Для «тонкой» диагностики службы WMI существует официальная утилита Microsoft — WMIDiag (Microsoft WMI Diagnosis). Утилита представляет собой vbs скрипт, который проверяет различные подсистемы WMI и записывает собранную информацию в лог файлы (по умолчанию логи находятся в каталоге %TEMP% — C:USERS%USERNAME%APPDATALOCALTEMP). Получившийся отчет состоит из файлов, имена которых начинаются с WMIDIAG-V2.1 и включает в себя следующие типы фалов :

  • .log файлы содержат подробный отчет об активности и работе утилиты WMIDiag
  • .txt файлы содержат итоговые отчеты о найденных ошибках, на которые стоит обратить внимание
  • В .csv файлах содержится информация, нужная для долгосрочного анализа работы подсистемы WMI

Совет. В 64 битных версиях Windows wmidiag нужно запускать так:

c:windowsSystem32cscript.exe wmidiag.vbs

в противном случае появится ошибка: WMIDiag must be run from native 64-bit environment. It is not supported in Wow64.

После окончания работы утилиты WMIDiag администратор должен изучить полученные файлы логов, проанализировать и попытаться исправить найденные ошибки.

В общем случае, WMIDiag может дать информацию по исправлению частных ошибок в WMI , но в большинстве случаев процесс это довольно трудоемкий и стоит потраченного времени только при решении инцидентов в критичных системах (как правило, на продуктивных серверах). Для массового сегмента рабочих станций пользователей гораздо проще «бить по площадям» и решать проблему работы WMI более радикально.

Перерегистрация библиотек WMI и перекомпиляция mof файлов

Следующий скрипт представляет собой «мягкий» вариант восстановления работоспособности службы WMI на отдельно взятом компьютере (выполняется перерегистрация dll библиотек и службы WMI, перекомпилируются mof файлы). Данная процедура является безопасной и ее выполнение не должно привести к каким-либо новым проблемам с системой.

sc config winmgmt start= disabled

net stop winmgmt

cd %windir%system32wbem

for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s

wmiprvse /regserver

winmgmt /regserver

sc config winmgmt start= auto

net start winmgmt

for /f %%s in ('dir /b *.mof') do mofcomp %%s

for /f %%s in ('dir /b *.mfl') do mofcomp %%s

Указанные команды можно выполнить путем простой вставки в окно командой строки, либо сохранить код в bat файле и запустить его с правами администратора. После окончания работы скрипта, систему нужно перезагрузить и вновь проверить работу WMI.

В том случае, если предыдущий способ не помог, придется перейти к более «жесткому» способу восстановления работоспособности службы WMI, заключающегося в пересоздании хранилища.

WMI репозиторий (хранилище) находится в каталоге %windir%System32WbemRepository и представляет собой базу данных, в которой содержится информация о метаданных и определениях WMI классов. В некоторых случаях репозитория WMI может содержать статическую информацию классов. При повреждении репозитория WMI,  в работе службы Windows Management Instrumentation (Winmgmt) могут наблюдаться ошибки вплоть до полной невозможности ее запустить.

В том случае, если вы подозреваете, что репозиторий WMI поврежден, имейте в виду, что его пересоздание это последняя вещь, к которой нужно прибегнуть только в том случае, если никакие другие операции реанимировать WMI не помогают.

Совет. На практике бывают случаи, когда пересоздание хранилища WMI приводит к проблемам со сторонним софтом. Вызван этот эффект тем, что все записи в базе WMI обнуляются (до состояния чистой системы). Такое ПО, вероятно, придется переустанавливать в режиме восстановления.

В Windows Vista и выше проверить целостность репозитория WMI  можно с помощью команды:

winmgmt /verifyrepository

Если команда возвращает, что база данных WMI находится в неконсистентном состоянии (INCONSISTENT), стоит попробовать выполнить «мягкое» восстановление репозитория:

Winmgmt /salvagerepository

И перезапустить службу wmi:

net stop Winmgmt
net start Winmgmt

Если описанная выше команда не помогла, выполняем сброс репозитория на начальное состояние (hard reset) так:

Winmgmt /resetrepository

В том случае, если команды Winmgmt /salvagerepository и Winmgmt /resetrepository желаемого эффекта не дали, стоит попробовать выполнить «жесткое» пересоздание базы WMI вручную таким сценарием:

sc config winmgmt start= disabled

net stop winmgmt

cd %windir%system32wbem

winmgmt /kill

winmgmt /unregserver

winmgmt /regserver

winmgmt /resyncperf

if exist Repos_bakup rd Repos_bakup /s /q

rename Repository Repos_bakup

regsvr32 /s %systemroot%system32scecli.dll

regsvr32 /s %systemroot%system32userenv.dll

for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s

for /f %%s in ('dir /b *.mof') do mofcomp %%s

for /f %%s in ('dir /b *.mfl') do mofcomp %%s

sc config winmgmt start= auto

net start winmgmt

wmiprvse /regserver

Данный скрипт полностью пересоздает хранилище WMI (старый репозитория сохраняется в каталоге Repos_bakup). После окончания работы скрипта компьютер нужно перезагрузить, после чего протестировать работу службы WMI простым запросом.

Источник

Like this post? Please share to your friends:
  • The windows is behind the sofa
  • The windows installer service could not be accessed как исправить
  • The windows installer service could not be accessed node js
  • The windows installer service could not be accessed hamachi windows 10
  • The windows installer engine is corrupt to attempt