Назад | Перейти на главную страницу

Как удалить все драйверы Citrix из гостевой системы Windows Server 2008 R2, если BSOD в безопасном режиме?

Я использую Citrix XenServer 5.5 и на Windows Server 2008 R2 Guest установлен Xentools 5.5, в течение года все работает хорошо. После перезапуска мы получаем BSOD с кодом остановки 7B, я думаю, это проблема с pv-драйвером Citrix, но как я могу удалить этот драйвер без графического интерфейса, безопасный режим также вызывает BSOD.

Поэтому я устанавливаю второй Windows Server на той же виртуальной машине и могу получить доступ к файловой системе гостя. В драйвере Windows / System32 / я удаляю xenvbd.sys и scsifilt.sys в реестре. Я удаляю все, что нашел с помощью xenvbd или scsifilt, но BSOD все еще здесь.

Справка Windows Startuprepair и sfc / scannow dosent.

Обновить: Все известные снимки имеют одну и ту же проблему

Восстановите сервер из заведомо исправной резервной копии.

Если вы устанавливаете драйвер Xen PV в гостевой системе и получаете BSOD с остановкой 7B, возможно, драйвер поврежден или некоторые файлы отсутствуют. Сначала вы должны узнать версию драйвера: перейдите в файловую систему и получите свойства, например, xenvbd.sys, затем перейдите на свой XenTools Installdisk и найдите следующие файлы:

xenutil.sys
xenvtchn.sys
xenvbd.sys
scsifilt.sys

После копирования этих файлов в Windows \ System32 \ Drivers \ вы можете запустить гостя в безопасном режиме. Теперь вы можете установить более новую версию Xentools из безопасного режима (вы найдете установочный файл в Xentools, который также работает в безопасном режиме), и вы получите несколько ошибок. Не перезагружайте сервер. Удалите эту программу сейчас, и начнется очистка, все поврежденные или отсутствующие файлы и записи реестра удалят и очистят вашу установку.

Теперь перезагрузитесь, и все работает!

Я рад, что проблема решена, и поддерживаю этот вопрос. Не потому, что решение имело бы какую-то искупительную ценность для других, но потому, что это должно служить предостережением.

Есть две вещи, которых не должно было произойти.

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

Во-вторых, «тестирование» изменения в аналогичной системе или разовой копии часто выявляет эти типы проблем.

Номер два может не иметь прямого отношения к этому сценарию, но часто имеет значение в средах, где отсутствует номер один.

Я бы предположил, что система могла работать нормально при перезапуске после первоначального изменения, но что-то было сломано в том году, когда это произошло.

Вот почему, когда я участвую в деятельности, которая включает в себя модификацию системы, первым делом я перезапускаю сервер, чтобы убедиться, что в случае возникновения подобных проблем они не связаны с тем, что я делаю.