0xc00002e2 windows server 2012 как решить
Обновлено: 21.11.2024
Центр обновления Windows вызывает BSOD при отработке отказа с помощью Azure Site Recovery
Используете ли вы Azure Site Recovery (ASR) и виртуальные машины Windows Server 2019? В настоящее время вы не защищены, и отработка отказа приведет к BSOD.
За последние пару месяцев мы участвовали в нескольких проектах по модернизации центров обработки данных клиентов с помощью гиперконвергентной инфраструктуры Azure Stack. Кроме того, включение таких функций Azure, как Azure Backup и Azure Site Recovery (ASR). Во время тестов на отработку отказа мы столкнулись с проблемой с виртуальными машинами Windows Server 2019.
Случай 1. Обычный отказоустойчивый тест ASR
В начале февраля 2021 г. мы завершили миграцию со среды Hyper-V на новое решение Azure Stack HCI с Azure Site Recovery в качестве решения для аварийного восстановления. Все виртуальные машины (большинство из них под управлением Windows Server 2019) были перенесены в Azure Stack HCI. Критически важные для бизнеса виртуальные машины были защищены с помощью ASR. Во время тестовой отработки отказа все виртуальные машины были успешно загружены в Azure. Затем клиент проверил доступность и функциональность.
Проверка отработки отказа прошла успешно, но из-за переноса основного приложения клиент запланировал дополнительную проверку отработки отказа, чтобы включить новое приложение после завершения миграции. Но об этом позже.
Случай 2. Проверка аварийного переключения при ошибке
В этом случае ситуация очень похожа на первый случай. Миграция в среду Azure Stack HCI и все критически важные для бизнеса виртуальные машины, защищенные с помощью ASR. В данном случае на Windows Server 2019 была только одна виртуальная машина (контроллер домена). Остальные виртуальные машины работали под управлением версий 2016, 2012 R2 и 2012.
Примерно в начале апреля 2021 года мы запланировали и выполнили тестовую отработку отказа для тестирования ASR. Почти все виртуальные машины успешно загрузились в Azure после завершения тестовой отработки отказа, за исключением одной виртуальной машины. В этом случае виртуальная машина Windows Server 2019 продолжает загружаться в диспетчер загрузки Windows с ошибкой.
После некоторых исследований и нескольких перезагрузок виртуальной машины кажется, что она загружается в Windows, но появляется BSOD на WDF01000.sys. И все мы знаем, что это нехорошо…
После BSOD виртуальная машина загружается в диспетчер загрузки Windows и зависает там. В данном случае заказчик предложил разобраться сам, на этом мы и остановились. Ожидание перехода к проверке на отказ после изучения проблемы клиентом.
Вернуться к делу 1
Тем временем, когда приложение было перенесено на новые виртуальные машины, клиент запросил дополнительный тест аварийного переключения Azure Site Recovery. На этот раз все шло не так хорошо. После тестовой отработки отказа все виртуальные машины Windows Server 2019 загружались в диспетчер загрузки Windows с тем же кодом ошибки, что и во втором случае.
Мы заметили такой же BSOD на WDF01000.sys. На этот раз мы смогли провести расследование и начали загрузку виртуального жесткого диска, чтобы получить файл memory.dmp. Дамп памяти указывает на драйвер фильтра vmstorfl.sys, используемый в качестве драйвера фильтра виртуального хранилища на виртуальных машинах Windows…
Это работало 3 месяца назад, в начале февраля, что-то сломало его почти для всех виртуальных машин Windows Server 2019.
Что произошло?
Глядя на среду, мы заметили, что после успешного теста отработки отказа было установлено февральское накопительное обновление (KB4601345). В февральском обновлении установлена версия ОС 10.0.17763.1757. В этом обновлении файл VMstorfl.sys не обновляется и остается в версии 10.0.17763.771. В майском обновлении файл VMstorfl.sys обновлен до 10.0.17763.1911, что означает, что файл изменился. К сожалению, нет доступной документации и нет упоминания об этой проблеме в февральском обновлении. То же самое относится к мартовским и апрельским обновлениям, включая майское обновление, в котором проблема не упоминается.
Мы провели собственное тестирование в лабораторной среде, чтобы исключить сторонние антивирусы, агенты резервного копирования или любое другое программное обеспечение. Мы настроили несколько виртуальных машин с чистой установкой виртуальных машин Windows Server 2019 1809. После установки февральского, мартовского или апрельского обновления на виртуальных машинах появляется BSOD.
Обновите как можно скорее и протестируйте решение для аварийного восстановления
Из-за этих двух случаев и некоторых наших собственных лабораторных испытаний. Мы обнаружили, что в февральском обновлении есть что-то, из-за чего виртуальные машины Windows Server 2019 отображают синий экран при отработке отказа в Azure.
Установив майское обновление (KB5003171), эта проблема устранена. Итак, всем компаниям, которые полагаются на Azure Site Recovery в качестве решения для аварийного восстановления центра обработки данных. Если вы используете виртуальные машины Windows Server 2019, обязательно установите майское обновление как можно скорее. В противном случае ваши решения для аварийного восстановления вообще не работают!
Кроме того, такие проблемы еще раз доказывают, что крайне важно время от времени тестировать ваше решение для аварийного восстановления. Потому что вы, вероятно, не знали, что в течение последних 3 месяцев ваше решение аварийного восстановления с Azure Site Recovery было бесполезным для ваших виртуальных машин Windows Server 2019 с примененным февральским обновлением. И он бесполезен до тех пор, пока не будет установлено и синхронизировано майское обновление.
Если вам нужна помощь или у вас есть вопросы, свяжитесь с нами!
Windows Server, работающий на виртуализированном контроллере домена, может столкнуться с подобной проблемой. Он просто не загружался должным образом и отображал сообщение об ошибке, в котором говорилось бы: «Ваш компьютер столкнулся с проблемой и нуждается в перезагрузке. Мы просто собираем некоторую информацию об ошибках, а затем перезапускаем для вас. (0% завершено). Если вы хотите узнать больше, вы можете позже поискать в Интернете эту ошибку: 0xc00002e2)».
Active Directory содержит очень важные и ценные данные, которые могут быть повреждены. Это иногда происходит, если вы внедрили центр сертификации, развернули сервер Lync, или повреждены данные в базах данных DC (контроллера домена), или просто перебои в подаче электроэнергии.
Хост-сервер/базовый сервер, на котором работает сервер Hyper-V, загрузится плавно, и вы все равно сможете видеть все виртуальные машины. Однако сервер контроллера домена или виртуальная машина будет показывать, что он перезагружается в цикле с этой ошибкой:
На вашем компьютере возникла проблема, и его необходимо перезагрузить. Мы просто собираем некоторую информацию об ошибках, а затем перезапускаем для вас. (0% завершено). Если вы хотите узнать больше, вы можете позже поискать в Интернете эту ошибку: 0xc00002e2)
В случае сбоя питания это действительно вызовет проблему, потому что у контроллера домена есть определенная кэш-память, которую обрабатывает ОС, а не RAID-контроллер. Указанный кеш будет поврежден, что приведет к ошибке 0xc00002e2.
Прежде чем делать что-либо еще, обязательно сделайте резервную копию, чтобы избежать дальнейшей потери данных.
Вот как можно решить эту проблему.
Перезапустите машину/виртуальную машину/экземпляр и нажимайте F8, пока не дойдете до меню загрузки.
Загрузитесь в режиме восстановления служб каталогов (DSRM).
Войдите в систему с учетной записью локального администратора. Это важно, поскольку в это время служба Active Directory не работает.
Откройте командную строку (Win-R, CMD, Enter)
Перейдите в папку C:\Windows\NTDS
Создайте резервную копию всего в этом месте.
Введите NTDSUTIL и нажмите Enter.
Введите «активировать экземпляр ntds» и нажмите Enter.
Введите «Файлы» и нажмите Enter.
Введите «Информация» и нажмите Enter.
Перейдите к расположению журналов и удалите (или переименуйте) файл *.log.
перезагрузитесь в обычном режиме.
Наш основной контроллер домена, содержащий все роли FSMO, аварийно завершает работу и продолжает перезагружаться с кодом ошибки в строке темы. DC находится на Hyper v 2012 r2, и мы делаем его резервную копию с помощью Unitrends. Это резервное копирование на уровне виртуальной машины. Я попытался восстановить виртуальную машину из резервной копии, сделанной несколько дней назад, но она по-прежнему не загружается.
Мы будем очень признательны за любую помощь.
xxovermetalxx
Максимальное использование гиперконвергентной инфраструктуры
2022-03-22 18:00:00 Веб-семинар UTC Веб-семинар: Dell — максимально эффективное использование гиперконвергентной инфраструктуры Сведения о событии Просмотреть все события
Лучшим решением будет захват ролей и переустановка DC.
13 ответов
ОП xxovermetalxx
Добавлен скриншот
Подождите, значит, вы восстановили из резервной копии, но эта ошибка по-прежнему возникает?
ОП xxovermetalxx
Верно.
Лучшим решением будет захват ролей и переустановка DC.
ОП xxovermetalxx
Спасибо, ребята. В итоге я его снес и восстановил. Хотел бы я знать, чем это вызвано. Я перезапустил сервер в то время, сделал ping -t, чтобы я мог наблюдать, как он отключается и снова включается, и когда это произошло, я попытался снова подключиться к RDP. Он не подключался, поэтому я подключился через хост Hyper v. . Когда я подключился таким образом, я увидел, что сервер был резервным на секунду, а затем произошел сбой.
Я немного изменил имя нового сервера, но сохранил тот же IP-адрес. На что мне следует обратить внимание? DHCP/DNS для клиентов обрабатывается маршрутизатором, поэтому мне не нужно ничего с этим делать. Я просмотрел AD и сайты и службы AD, а также DHCP и удалил все, что смог найти со старым именем и IP, прежде чем добавить новое.
Спасибо за помощь, ребята.
CrashFF
У меня было такое же сообщение об ошибке, в моем случае диск C на контроллере домена был исчерпан. Однако я не мог заметить этого, пока успешно не вошел в систему. Вот что мне нужно было сделать:
- Загрузка в режиме восстановления служб каталогов (
Устранение неполадок > Параметры запуска | Перезапустить | затем прокрутите вниз до режима восстановления служб каталогов и загрузите. Мне потребовалось две перезагрузки, прежде чем он, наконец, показал мне экран входа в систему.
Войдите под учетной записью локального администратора (если у вас нет второго AD)
Теперь, как только я вошел в систему, я заметил, что не могу делать кучу вещей (поскольку локальная учетная запись администратора не может успешно создать папку профиля), но это дало мне хороший намек на то, что система C на диске закончилось место. Если вы можете запустить CMD на этом этапе, я бы запустил
C:\Windows> DEL *.log /S /F /Q
Все, теперь перезагружаемся и входим под администратором домена (сетевым пользователем). С помощью VSphere я смог добавить больше места на диске, а с помощью управления компьютером я смог расширить диск C.
Вчера утром я обнаружил, что мой Synology NAS неожиданно отключился посреди ночи, в то время как виртуальные машины и рабочие нагрузки моей домашней лаборатории все еще работали. Это привело к тому, что обе мои базы данных контроллеров домена были повреждены, что привело к невозможности загрузки этих машин. При попытке загрузить их они застревали в цикле загрузки BSOD и отображали код ошибки Stop 0x00002e2.
После некоторых исследований я смог выяснить, как восстановить свои виртуальные машины и заставить их снова загружаться. Это случалось со мной однажды, где-то в начале этого года, и, к счастью, я вспомнил, что сделал несколько заметок о том, как это исправить, поэтому я решил, что на этот раз я составлю официальное руководство «Как:», чтобы задокументировать это для себя и надеюсь, чтобы помочь другим, столкнувшимся с этой проблемой, а также. Итак, без лишних слов… приступим!
Чтобы начать, вам нужно включить компьютер, а затем продолжать нажимать клавишу F8, чтобы открыть меню загрузки «Дополнительные параметры загрузки». Перейдите вниз к режиму восстановления служб каталогов, нажмите Enter, чтобы загрузить вас в безопасном режиме.
Когда вы дойдете до экрана входа, войдите в систему с учетной записью локального администратора, поскольку доменные службы Active Directory, очевидно, недоступны.
Оказавшись на рабочем столе, откройте окно командной строки с повышенными привилегиями.
Я считаю, что всегда разумно и важно делать резервную копию файлов, прежде чем вносить какие-либо изменения. Поскольку мы будем создавать резервную копию каталога NTDS, создайте каталог в удобном для вас месте для хранения файлов резервных копий. Я решил создать резервную папку в корне «C:\» и подкаталог с именем/датой каталога, резервную копию которого я делаю.
Затем скопируйте все из каталога «C:\Windows\NTDS» в это новое место с помощью xcopy.
После этого давайте переименуем все расширения файлов .log в каталоге NTDS в .log.old
Теперь мы подошли к самому интересному!
Сначала выполните следующую команду, чтобы восстановить базу данных.
Появится следующее предупреждающее сообщение, нажмите «ОК»
Позвольте ему сделать свое дело, и после завершения вы увидите следующее.
Теперь нам нужно использовать утилиту NTDS (ntdsutil.exe), чтобы активировать экземпляр NTDS и сжать БД в новый файл, который затем будет использоваться для перезаписи оригинала. Я буду сжимать его в новый каталог TEMP в каталоге NTDS. Команда автоматически создаст новый каталог, если он еще не существует. Введите следующие команды.
В случае успеха вам будут представлены инструкции по копированию только что сжатого файла в каталог NTDS с перезаписью оригинала, а также по удалению всех файлов .log в каталоге NTDS. Прежде чем мы сможем это сделать, нам нужно выйти из ntdsutil. Дважды нажмите quit, чтобы выйти.
Давайте следуем этим инструкциям, а также удалим файлы *.log.old, которые мы переименовали ранее.
Убедитесь, что вы все еще находитесь в каталоге NTDS, прежде чем вводить следующие команды удаления.
Сложная часть позади! Давайте продолжим и перезагрузим машину в обычном режиме.
Если все пойдет хорошо и как ожидалось, ваш компьютер успешно загрузится, и вы сможете снова войти в систему с учетной записью администратора домена Active Directory.
Отлично! Что ж, я надеюсь, что вы нашли это руководство полезным. Пожалуйста, не стесняйтесь поделиться этим и дать мне несколько отзывов/комментариев ниже. Спасибо за прочтение!
Читайте также: