Восстановление работоспособности Server 2019 Datacenter with GUI.
Уважаемые коллеги!
Подскажите, возможно ли оживить Server 2019 Datacenter with GUI (работает как домашняя персоналка) после неудачного обновления? Суть проблемы - после, внешне удачной, установки обновления 10.0.17763.379 перезагрузил Сервер и он завис при старте на крутящемся колечке. Точек отката на Сервере нет. Попытки восстановить хранилище компонентов Сервера из системы Windows 10 Pro 1903 x64, установленной на другом жёстком диске, безуспешны: DISM /Image:H:\ /Cleanup-Image /ScanHealth Cистема DISM Версия: 10.0.17763.1 Версия образа: 10.0.17763.349 [==========================100.0%==========================] Хранилище компонентов восстановить невозможно. Операция успешно завершена. Команда проверки целостности файлов также не справляется: sfc /scannow /offbootdir=H:\repair\ /offwindir=H:\Windows Начато сканирование системы. Этот процесс может занять некоторое время. Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз. При старте Сервера он, по-прежнему, зависает на крутящемся колечке. Последние строки в файле ntbtlog.txt во время старта зависающего Сервера: BOOTLOG_LOADED \SystemRoot\System32\drivers\tcpipreg.sys BOOTLOG_LOADED \SystemRoot\System32\DRIVERS\srvnet.sys BOOTLOG_LOADED \SystemRoot\System32\DRIVERS\srv2.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\condrv.sys Команда DISM /image:H:\ /Cleanup-Image /RestoreHealth /Source:H:\server\sources\install.wim:4 /ScratchDir:H:\1 (источник - распакованный MSDN-исошник Сервера 2019) заканчивается так: Cистема DISM Версия: 10.0.17763.1 Версия образа: 10.0.17763.349 [==========================100.0%==========================] Сбой восстановления. Не найден источник восстановления, или хранилище компонентов восстановить невозможно. Ошибка: 0x800f081f Сбой DISM. Операция не выполнена. Команда dism /image:H:\ /ScratchDir:H:\1 /cleanup-image /RevertPendingActions завершается так: Cистема DISM Версия: 10.0.18362.1 Версия образа: 10.0.17763.349 Удаление незавершенных действий из образа... Ошибка: 14003 Произошла ошибка, вызывающая удаление из образа незавершенных действий. Дополнительные сведения см. в файле журнала. Обновление установленного Сервера при загрузке с флешки с записанным дистрибутивом Сервера не удаётся: "Система не предназначена для обновления". |
Продолжаю попытки восстановить Сервер 2019 уже больше из спортивного интереса. :)
При поисках в инете нашёл такой совет по исправлению ошибки "Образ больше не обслуживается". Подключил куст реестра Сервера под Вин 10 х64 и исправил атрибут параметра "Unserviceable" с "1" на ноль в разделе "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ComponentBased" . После этого команда /Cleanup-Image /ScanHealth отработала с результатом "Повреждение хранилища компонентов не обнаружено." Команда проверки целостности файлов по-прежнему выдаёт: sfc /scannow /offbootdir=H:\repair\ /offwindir=H:\Windows Начато сканирование системы. Этот процесс может занять некоторое время. Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз. Сервер при перезагрузке, по-прежнему, зависает на крутящемся колечке. В ntbtlog.txt такие же последние строчки: BOOTLOG_LOADED \SystemRoot\System32\DRIVERS\srv2.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\condrv.sys В ntbtlog.txt на рабочей десятке после этого condrv.sys идут следующие строки: BOOTLOG_LOADED \SystemRoot\System32\DRIVERS\srvnet.sys BOOTLOG_LOADED \SystemRoot\system32\drivers\mmcss.sys BOOTLOG_LOADED \SystemRoot\System32\DRIVERS\srv2.sys BOOTLOG_LOADED \SystemRoot\system32\drivers\peauth.sys и так далее... То есть, затык при загрузке нерабочего Сервера происходит на драйвере srvnet.sys. Подскажите, в каком логе или разделе реестра неработающего Сервера можно увидеть причину, почему не загружаются те или иные драйверы? |
Ещё немного информации по нерабочему серверу.
При сравнении файлов ntbtlog.txt Сервера и рабочей Вин10 х64 Про нашёл, что при старте Сервера почему-то не загружаются такие файлы: FSFilter Bottom SystemRoot\System32\drivers\fileinfo.sys (Start=3) FSFilter Encryption system32\drivers\filecrypt.sys (Start=1) FSFilter Anti-Virus system32\drivers\wd\WdFilter.sys (Start=0) FSFilter Top SystemRoot\system32\drivers\bindflt.sys (3) Base SystemRoot\System32\Drivers\Beep.SYS (3) и system32\drivers\WudfRd.sys (3) PNP_TDI System32\DRIVERS\NDProxy.sys (3) NDIS System32\drivers\tunnel.sys (3) network system32\drivers\csc.sys (Start=4) PNP Filter SystemRoot\system32\drivers\ksthunk.sys (3) и System32\drivers\WpdUpFltr.sys (3) а также без указания группы: SystemRoot\system32\drivers\mmcss.sys (3), SystemRoot\System32\drivers\rassstp.sys (3), SystemRoot\System32\drivers\AgileVpn.sys (3), SystemRoot\System32\drivers\rasl2tp.sys (3), SystemRoot\System32\drivers\raspptp.sys (3), System32\DRIVERS\raspppoe.sys (3), System32\DRIVERS\ndistapi.sys (3), SystemRoot\System32\drivers\ndiswan.sys (3), system32\drivers\wd\WdNisDrv.sys (3). Все эти файлы присутствуют в нужных папках Сервера и являются правильными, не битыми и не зараженными. Информация по загрузке этих драйверов есть в реестре Сервера, куст System. В файле cbs.log при старте Сервера есть только такие строчки: CBS TI: --- Initializing Trusted Installer --- CBS TI: Last boot time: 2019-07-11 06:41:15.500 CBS Failed to initialize COM security. [HRESULT = 0x800706ba] CBS Starting TrustedInstaller finalization. CBS Ending TrustedInstaller finalization. По информации в инете, эта ошибка - [HRESULT = 0x800706ba - RCP_S_SERVER_UNAVAILABLE]. В реестре Сервера присутствует информация по запуску службы rpcss (Start=2), нужные файлы rpcss.dll, combase.dll и svchost.exe есть в папках Сервера. Подскажите, возможно ли "заставить" Сервер загружать указанные драйверы и таки запустить службу RCP_S_SERVER для последующей нормальной загрузки? |
Вложений: 1
Для продолжения темы ещё немного информации.
В ходе "борьбы" выяснилось, что у многих системных и программных папок слетели права доступа. Пришлось их восстанавливать в ручном режиме. После этого удавалось в оффлайн-режиме, в работающей "десятке" х64, последовательно накатывать кумулятивные обновы windows10.0-kb4507469-x64.msu (17763.615) и windows10.0-kb4505658-x64.msu (17763.652). После первого CU при загрузке сервера стал выпадать голубой BSOD CRITICAL_PROCESS_DIED с ошибкой в ntoskrnl.exe. Хотя, DISM и sfc проблем в системе не находили. Откат до билда 17763.349 происходил корректно, загрузка Сервера по-прежнему останавливалась на крутящемся колёсике. После установки CU 17763.652 загрузка Сервера стала доходить до чёрного экрана с курсором, у которого периодически появлялись "песочные часы". Сервер стал определяться в домашней сети, в сетевые шары можно заходить и работать с файлами. По RDP можно подключиться в системной учётной записи "Администратор" с паролем. Но, при подключении также виден чёрный экран с мышкой и через 4-5 секунд удалённое соединение закрывается. Благодаря утилите PsExec.exe из комплекта ps tools М.Руссиновича можно открыть командный режим на Сервере, просмотреть запущенные приложения, службы и драйверы. При сравнении аналогичной информации с работающей "десяткой" х64 существенных различий не вижу. При проверки Учётных записей из командной строки учётки админа и гостя есть и не заблокированы. Можно запускать приложения, только никакие окна на чёрном фоне с курсором не появляются. /ScanHealth пишет, что всё в порядке. sfc находит только проблемы в "Warning: Overlap: Duplicate ownership for directory" - около 50-ти системных и программных папок. Поиск в инете даёт информацию, что это не критично для запуска и работы системы. В безопасном режиме сейчас загрузка Сервера доходит до выпадения ошибки файла LogonUI.exe "Обнаружено переполнение стекового буфера в данном приложении. Это переполнение может позволить злоумышленнику получить управление над данным приложением." Информации в инете по поводу реальной причины ошибки в файле LogonUI.exe немного. Др.Вебом и Каспером все папки Сервера проверил - чисто, /RestoreHealth - всё в порядке, удалял все файлы для встроенного видеоадаптера Intel G45 и возвращал их на место - ошибка возникает. В безопасном режиме с сетевыми драйверами, даже на фоне этой ошибки с LogonUI.exe, Сервер виден в сети. Комбинация клавиш Contrl+Shift+win+B срабатывает во всех режимах. Осталось нормально загрузить Рабочий стол. В реестре путь к профилю "Администратор" правильный. Вроде бы остался последний шаг до восстановления работы Сервера, но - он трудный самый. :) Буду рад советам и помощи. Скрин ошибки с LogonUI.exe приложил. |
Цитата:
Цитата:
|
Цитата:
Лицензию, конечно же, купил? |
Цитата:
Цитата:
Команда Dism.exe /Image:H:\ /Cleanup-Image /AnalyzeComponentStore из под работающей Вин 10 х64 выдаёт в итоге: Число освобождаемых пакетов : 0 Рекомендуется очистка хранилища компонентов : Нет Charg, Разумеется. |
Нарыл следующую инфу:
- KB3097877 может вызывать такую ошибку. Если у вас установлено это обновление, то попробуйте удалить его. - Загрузитесь с LiveCD или подключите HDD к другому ПК. Затем натравите на ваш сервер утилиту Autoruns. Если каких-то файлов для запуска служб или драйверов будет не хватать, то она подсветит их желтым цветом. Также имеет смысл временно отключить (через нее же) все не-Майкрософтовые драйвера и службы. |
Цитата:
Autoruns-ом проверял систему: отсутствующих драйверов и служб нет. В файлах регистрации ошибок приложений (ProgramData\Microsoft\Windows\WER\ReportQueue) нашёл, что падение LogonUI.exe связано с файлом Windows.UI.XamlHost.dll Вот кусок из одного такого файла (Report.wer): Sig[0].Name=Имя приложения Sig[0].Value=LogonUI.exe Sig[1].Name=Версия приложения Sig[1].Value=10.0.17763.1 Sig[2].Name=Отметка времени приложения Sig[2].Value=5ab44f80 Sig[3].Name=Имя модуля с ошибкой Sig[3].Value=Windows.UI.XamlHost.dll Sig[4].Name=Версия модуля с ошибкой Sig[4].Value=10.0.17763.1 Sig[5].Name=Отметка времени модуля с ошибкой Sig[5].Value=0e34a79b Sig[6].Name=Смещение исключения Sig[6].Value=000000000000afc1 Sig[7].Name=Код исключения Sig[7].Value=c0000409 Sig[8].Name=Данные исключения Sig[8].Value=0000000000000007 Поиски решения проблемы в связке этих двух файлов пока безрезультатны. |
Так может просто переместить куда-нибудь временно эту dll'ку? Возможно, система согласится без нее загружаться.
|
Цитата:
Что-то ещё мешает загрузить файлы ресурсов системы и нормально отразить рабочий стол. Кстати, через PsExec.exe обновил определения Защитника Виндовс, он работает и проверяет файлы (видно по отчётам в папках Защитника). |
onkolog, ТимВивер я бы на вашем месте грохнул первым делом. Эта хрень конкретно задрала меня, я уже устал отключать его службу на различных компах, из-за которых порой дико стопорится загрузка ОС. Ну и ucrtbase.dll тоже куда-нибудь деньте в другое место на время.
Ctrl + Shift + Escape тоже не работает, кстати? |
Цитата:
Кажется, нашёл причину зависания при входе на рабочий стол: служба "Диспетчер подключений Windows" находится в состоянии - Запуск. Все службы, от которых она зависит, автозапускаются и работают (Служба интерфейса сохранения сети, Удаленный вызов процедур (RPC), Модуль запуска процессов DCOM-сервера, Сопоставитель конечных точек RPC, NSI Proxy Service Driver). Остановка службы через taskkill /PID хххх /F и последующий запуск службы приводит к ошибке "Ошибка 1053. Служба не ответила на запрос своевременно." Поиск решения проблемы привёл к рекомендации Микрософт для 2003-го Сервера - https://support.microsoft.com/az-lat...o-the-start-or По умолчанию у зависающей службы вход в систему с "Локальная служба". Галку на параметре "Разрешить взаимодействие с рабочим столом" можно поставить только если сменить на вход "С системной учётной записью". Пока не решился сменить тип входа в систему: не хочется потерять последний вариант удалённого контроля над Сервером. Службу ТимВивера отключил. |
Цитата:
|
Цитата:
Оказалось, что при старте Сервер упорно грузится в учётную запись USERPROFILE=C:\WINDOWS\system32\config\systemprofile. Несмотря на корректные записи в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList и в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. После переименовывания этой записи (S-1-5-18) Сервер грузится в учётной записи USERPROFILE=C:\Users\Default. Картина загрузки при этом не меняется - тот же самый чёрный экран с курсором, доступ по сети есть. Разбираясь со службами на работающем Сервере исправил запуск и работу "Журнал событий Windows", "Координатор распределенных транзакций - MSDTC" и "KtmRm для координатора распределенных транзакций - KtmRm". Несмотря на применение различных вариантов решения проблемы, упорно не запускаются и не работают "Служба политики диагностики - DPS", "Узел системы диагностики - WdiSystemHost", "Узел службы диагностики - WdiServiceHost" и "Защита программного обеспечения - sppsvc" - все с ошибкой "Системная ошибка 5. Отказано в доступе." Службы "Вспомогательная служба IP - iphlpsvc" и "Помощник по подключению к сети - NcaSvc" - с ошибкой "Ошибка 1068. Не удалось запустить дочернюю службу." У обоих проблема из-за незапускающейся службы "Служба автоматического обнаружения веб-прокси WinHTTP - WinHttpAutoProxySvc" (сообщите разработчику специфический для этой службы код ошибки 5). Осталась главная проблема - невозможно загрузиться под встроенной учёткой "Администратор", которая и была основной. |
Полагаю, все ваши проблемы из-за нехватки прав доступа. Во-первых, выполните чек-диск для диска С. Ну так, на всякий случай. Далее. Поставьте ту же редакцию на второй раздел (или на виртуальную машину), после чего тормозните какую-нибудь из тех служб, что у вас не запускаются. Затем с помощью Process Monitor'а отследите куда она обращается при ручном запуске. Далее грузимся с LiveCD и проверяем вашу дохлую систему на наличие \ отсутствие соответствующих прав доступа в ключевых местах (папки и ветки реестра). Таких ключевых мест (типа C:\Windows\system32) вряд ли будет слишком много, их вполне реально проверить вручную.
Конечно, в идеале нужно было бы запустить Process Monitor на Сервере и посмотреть где там прав не хватает, но вы писали что все запущенные приложения закрываются, так что легкий и быстрый вариант вам недоступен, судя по всему. |
Цитата:
Я раньше уже писал, что после обновления слетели права у многих системных папок. В ходе восстановления сервера у части папок нужные права вернул, но главной проблемой, почему не загружался рабочий стол, оказался файл C:\Windows\Globalization\Sorting\SortDefault.nls. Вычислил его благодаря Process Monitor-у, который удалённо запускал из командной строки. Для сбора бутлога импортировал из той же ком. строки нужный параметр реестра для Process Monitor-а перед перезагрузкой сервера. Полученный .pmb файл переносил в папку Windows рабочей десятки и уже в ней сохранял как .pml лог. Попытка просто открыть .pmb лог из папки Windows Сервера приводила к падению Process Monitor-а. После успешной загрузки рабочего стола и дальнейшего обновления Сервера до 17763.720 несколько часов потратил на запуск не работавших служб. А на следующий день Сервер загрузился с такими проблемами: отсутствие надписей у ярлыков и в окнах многих приложений (слетели разрешения у папки Fonts) и перестала работать Служба "Защита программного обеспечения", что привело к слёту активации Сервера. Эти проблемы разрешил, относительно быстро, восстановлением нужных прав у системных папок, до которых раньше не дошли руки. Сейчас, по данным Process Monitor-а, особых проблем в работе Сервера нет. Остались только такие баги - не вызывается меню на левой кнопке в панели задач и не выезжает справа панель сообщений. Также, при запуске, появляется окно Защитника Windows и тут же закрывается. Эти баги, похоже, зависят от ACCESS DENIED у файлов C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe и C:\WINDOWS\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\SearchUI.exe. Все правильные разрешения на требуемые папки выставил, но баги пока сохраняются. Главное - Сервер успешно воскрес. :) Спасибо за участие и помощь. |
Обновление kb4541331 опять поломало Сервер: при старте загрузки получаю BSOD CRITICAL_PROCESS_DIED с ошибкой в ntoskrnl.exe. Удаление обновки восстанавливает работоспособность Сервера.
При анализе краш-дампа вижу строки: PROCESS_NAME: wininit.exe CRITICAL_PROCESS: wininit.exe EXCEPTION_CODE: (NTSTATUS) 0xf0c8f080 - <Unable to get error code text> ERROR_CODE: (NTSTATUS) 0xf0c8f080 - <Unable to get error code text> DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT_SERVER Похоже, что какой-то драйвер крэшит загрузку. Изучил ntbtlog.txt: до падения грузятся только драйверы встроенной интеловской видеокарты и реалтековской сетевой карты. Удаление файлов этих драйверов вместе с файлами звуковой карты Realtek (на всякий случай) из Windows\System32\drivers проблему не решило. Подожду ближайшего кумулятивного апдейта. UPD. Кумулятивы kb4554354 и kb4549949 также крэшат Сервер с той же ошибкой. Откат до рабочей сборки 1098 проходит корректно. Подмена обновленных драйверов из указанных кумулятивов на драйверы из сборки 1098 ситуацию не исправляют. Краш-дампы в Микрософт уходят. Подождём... :) |
Выпущенные Микрософтом, после моего последнего сообщения, 8 кумулятивных обновлений проблему с BSOD-ом не решили.
В итоге успешно обновился из-под работающего Сервера сборки 1098 до Windows Server Insider Preview (Windows Server vNext LTSC Preview - Build 20201 (with GUI)). Потестирую обновку. :) |
Время: 06:17. |
Время: 06:17.
© OSzone.net 2001-