Корректная перезагрузка зависшего при выключении Windows сервера
Уже не первый раз сталкиваюсь с такой проблемой в Windows Server 2008 R2 / Windows Server 2012/R2: после установки обновлений или неких ролей/компонентов сервер запрашивает перезагрузку, во время которой на экране появляется надпись “ Preparing to configure Windows. Do not turn off your computer ” или “ Подготовка к настройке Windows. Не выключайте компьютер ”. На этом этапе сервер замирает и эта надпись может висеть часами. При этом сервер продолжает быть доступен по сети, но часть служб, в том числе доступ к RDP, не доступны.
Как правило, в этом случае самый быстрый способ решить проблему – перезагрузить сервер по питанию (хардрезет). Например, удаленно перезагрузить физический сервер можно из консоли HP ILO , Dell iDRAC и .т.п, или из консоли Hyper-V , vSphere для виртуальных машин. Но в таком случае есть вероятность нарушить работу ОС. Лучше использовать более «мягкий» способ сброса зависшего при перезагрузке сервера.
С другого компьютера при помощи оснастки Службы (Services) – services.msс удаленно подключимся к зависшему серверу.
В списке служб сервера несложно найти службу Windows Modules Installer (Установщик модулей Windows), находящуюся в состоянии Stopping . Очевидно, именно эта служба мешает выполнению процедуры корректной перезагрузки сервера.
Кнопки управления службой при этом не доступны. В свойствах службы можно узнать имя исполняемого файла: C:\Windows\servicing\TrustedInstaller.exe
Наша задача – принудительно завершить данный процесс. Проще всего воспользоваться сценарием, описанным в статье Как принудительно завершить зависшую службу с учетом того, что эти действия придется выполнить удаленно.
На любом компьютере откройте окно командой строки и для завершения процесса TrustedInstaller.exe на сервере с именем corp-man02 выполнить следующую команду.
taskkill.exe /s corp-man02 /u corp\admin_name /p P@ssw0rd! /im TrustedInstaller.exe
То же самое действие можно выполнить с помощью утилиты Pskill из набора PSTools:
pskill.exe \\corp-man02 TrustedInstaller.exe
psexec \\corp-man02 taskkill /IM TrustedInstaller.exe /F
После этого на экране зависшего сервера должна появиться надпись Shutting down и через несколько мгновений он должен корректно перезагрузится.
Проблема встречается не только на серверных версиях Windows, но и на клиентских Windows 7 / Windows 8 / Windows 10.
Сервер Windows сам выключается – событие user32 event 1074
Привет. Недавно столкнулся с очень неприятной ситуацией — часть серверов начала самопроизвольно выключаться. Какой — либо закономерности в выключениях проследить не удавалось. Единственное что объединяло серверы — это то что на них была установлена ОС Windows Server 2012 или выше, и большая их часть имеет роль терминальных. Ах да, еще все эти серверы — виртуальные и работают под управлением Hyper V. Хочу сегодня рассказать, в чем была проблема.
Конечно, любая диагностика должна начинаться с анализа логов. И вот какое событие удалось обнаружить непосредственно перед выключениями серверов – событие 1074, user32:
The process C:\Windows\system32\winlogon.exe (DC) has initiated the power off of computer DC on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found
Reason Code: 0x500ff
Shutdown Type: power off
По ним становится понятно, что работа завершается штатно. Что в общем то позволяет исключить влияние железа, хотя оно и так было исключено, т. к. все серверы виртуальные. Под подозрение попал гипервизор, но рысканье вдоль и поперек по логам ни какого результата не дало. События относящиеся к завершениям работы не имели отношения к инициализации завершения работы. Говорят, что виртуальные машины могут в редких случаях произвольно выключаться, если есть проблемы со свободной памятью, но в моем случае памяти было более чем достаточно.
В общем думаю хватит томить, и пора рассказать вам, в чем же в итоге было дело. Подключившись по RDP, я сидел и размышлял, что же может быть причиной подобного завершения работы. И вот из-за бездействия меня выбило на экран ввода пароля, где я обнаружил вот такой экран:
Обратите внимание на нижний угол:
Да, это мать его, завершение работы системы. Оказывается с 2012 винды MS сделали эту кнопку доступной при подключении по RDP.
Отвечает за эту кнопку параметр в групповой политике —
Computer Configuration – Policies – Windows Settings – Local Policies – Security Options – Shutdown: Allow system to be shut down without having to log on.
Отключаем его и всё, возможности выключить сервер у пользователей не будет.
Почему в моем случае этот параметр оказался включенным — остается загадкой. Скорее всего кто-то когда-то давным-давно его включил. Хотя, не исключаю, что он оказывается включенным при переходе с 2008 домена, проверять, честно говоря, лень. Кто в курсе, напишите в комментариях, в каком состоянии находится этот параметр при добавлении контроллера домена Windows 2012 в домен с уровнем 2008r2 или ниже.
В общем и целом, после изменения этого параметра мистические выключения прекратились.
Сервер с windows server 2012 r2 вместо перезагрузки выключается
Доброго дня! Ошибки отключения от сети на время продолжаются.
chrdsk c:/f/r делала — ошибок нет. или я так и не нашла его протокол
sfc /scannow дал следующий протокол: Лог
В просмотре событий каждый раз после таких вылетаний есть 2 сообщения в приложениях:
1. Ошибка . Application error: Код 1000 Категория задачи (100)
Имя сбойного приложения: AUDIODG.EXE, версия: 6.2.9200.17590, метка времени: 0x56607f45
Имя сбойного модуля: rdpendp.dll, версия: 6.2.9200.16384, метка времени: 0x50107ef3
Код исключения: 0xc0000005
Смещение ошибки: 0x00000000000172f8
Идентификатор сбойного процесса: 0x32ec
Время запуска сбойного приложения: 0x01d1b63ca6f6c6d5
Путь сбойного приложения: C:\Windows\system32\AUDIODG.EXE
Путь сбойного модуля: C:\Windows\system32\rdpendp.dll
Идентификатор отчета: 8035c341-2230-11e6-94be-0025907bee05
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:
2. Ошибка . Winlogon Код 4005 без категории задач:
Вход был неожиданно завершен.
Подробнее: Имя журнала: Application
Источник: Microsoft-Windows-Winlogon
Дата: 25.05.2016 11:32:49
Код события: 4005
Категория задачи:Отсутствует
Уровень: Ошибка
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: Server-Oculus
Описание:
Вход был неожиданно завершен.
Xml события:
Имя журнала: Application
Источник: Application Error
Дата: 25.05.2016 11:23:59
Код события: 1000
Категория задачи:(100)
Уровень: Ошибка
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: Server-Oculus
Описание:
Имя сбойного приложения: AUDIODG.EXE, версия: 6.2.9200.17590, метка времени: 0x56607f45
Имя сбойного модуля: rdpendp.dll, версия: 6.2.9200.16384, метка времени: 0x50107ef3
Код исключения: 0xc0000005
Смещение ошибки: 0x00000000000172f8
Идентификатор сбойного процесса: 0x32ec
Время запуска сбойного приложения: 0x01d1b63ca6f6c6d5
Путь сбойного приложения: C:\Windows\system32\AUDIODG.EXE
Путь сбойного модуля: C:\Windows\system32\rdpendp.dll
Идентификатор отчета: 8035c341-2230-11e6-94be-0025907bee05
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:
Xml события:
1000
2
100
0x80000000000000
465784
Application
Server-Oculus
AUDIODG.EXE
6.2.9200.17590
56607f45
rdpendp.dll
6.2.9200.16384
50107ef3
c0000005
00000000000172f8
32ec
01d1b63ca6f6c6d5
C:\Windows\system32\AUDIODG.EXE
C:\Windows\system32\rdpendp.dll
8035c341-2230-11e6-94be-0025907bee05
Эта ошибка меня уже достала и я не имею представления почему она на них затыкается. Если сбойные сектора на них — почему я их копирую с другого места и они нормально копируются (с админовскими правами). Надо их в безопасном режиме копировать? . это нудно. надо ещё до этого время найти. — подготовиться с правами заморачиваться. Кстати там есть странный пользователь TrustedInstaller — Его пока нет в правах безопасности файла audiodg.exe. Все оригиналы вышеназванных файлов находится видимо в патчах, потому наверное ещё не распакованы? Хотя не так, потому, что размеры файлов совпадают.
Расположение файла в патче:
Хотя есть другой патч C:\Windows\WinSxS\amd64_microsoft-windows-audio-audiocore_31bf3856ad364e35_6.2.9200.21709_none_d04e7812873c45dc\audiodg.exe
Может дело в этом и надо скопировать последний ехе-шник из последнего патча на место?
Моего мозга не хватает, копать очень нелегко, потому помогите.