After installing the 2022 January Windows Update, some users report that their Windows Server 2019 getting stuck in a reboot loop. This post from MiniTool introduces how to fix the “Windows Server 2019 boot loop after update” issue.
Microsoft released the Windows Server 2012 R2 KB5009624 update, the Windows Server 2019 KB5009557 update, and the Windows Server 2022 KB5009555 update as part of the January 2022 Patch Tuesday.
However, some users report that Windows Server 2019 is getting stuck in a reboot loop after installing the 2022 January Windows Update. The following is a related forum from Microsoft:
I have a Windows Server 2019 HyperV that after KB5009557 installation, crashes at the login screen, restarts, and then goes to Automatic Repair mode which finishes the repair process, but it crashes the same way.Microsoft
What causes the “Windows Server 2019 boot loop after update” issue?
- Update failure.
- Corrupted RAM sticks.
- Outdated drivers.
- Bad Registry entries.
- Hard drive issues.
- …
If you are suffering from this “Windows Server updates cause PC boot loops” problem, read on to find a solution to deal with it.
Related posts:
- How to Factory Reset Windows Server 2022? Here Are 2 Ways!
- How to Fix Windows Server 2019 Slow File Sharing? [3 Ways]
- Is Windows Server Slow? How to Speed up Windows Server?
Fix 1: Remove USB devices
Some systems have been found to experience the “Windows Server 2019 boot loop after update” issue when a USB drive is connected to the PC. Try removing other USB devices and see if that helps. This way you can identify the USB that might be preventing your computer from starting.
If your PC can boot normally after removing USB devices, you had better back up the computer since there are a lot of troubles that occur while using the computer. Regardless of what system issues occur on your computer, system image recovery is a better solution provided that a system image was created beforehand.
If your PC is still stuck on the Windows Server 2019 boot loop, you can try the rest solutions. Once the PC boots normally, you had better back up the PC in time.
Back up Your PC in Time
To do this, we highly recommend using the Server backup software – MiniTool ShadowMaker since it offers a variety of rich features to meet most of your server backup needs. It enables you to back up files, disks, partitions, and systems and clone SSD to larger SSD.
Besides, you set the automatic backups in four different modes – daily, weekly, monthly, and on event. The tool supports various backup destinations, including internal/external hard drives, network shares, NAS devices, etc. It is compatible with Windows Server systems and Windows PC systems.
You can use it for free within 30 days, so just download it and have a try.
MiniTool ShadowMaker TrialClick to Download100%Clean & Safe
Now I will show you how to use MiniTool ShadowMaker to back up the system step by step.
1. Launch MiniTool ShadowMaker at first.
2. MiniTool ShadowMaker backs up the operating system and selects the destination by default. If you want to change the backup destination, you can click DESTINATION to select it. It’s recommended to choose the external hard drive as the destination.
3. After confirming the backup source and backup destination, then click Back Up Now.
4. When the backup process finishes, you can go to Tools > Media Builder to create a bootable media. Once your system can’t boot, you can restore your system to the normal state with the media.
Fix 2: Re-Seat Your Memory Card
Thus, you should try to re-seat your memory card to fix the “Windows Server 2019 not booting after update” issue. Here is how to do that:
1. Open the cabinet of your PC and you can see the internal structure.
2. Find the location on the motherboard where the memory card is installed.
3. Release each memory card and pull it out of the slot.
4. Plug it back in again and try to restart your computer.
Tips:
Corrupted memory is also the reason for the “Windows Server 2019 boot loop after update” issue. In the latter case, there is no choice but to replace the memory.
Fix 3: Check the Motherboard
When the Windows Server 2019 fails the POST (Power On Self Test) state during startup (the visual cue is a black screen while loading and nothing else happens), this is the biggest sign that something is wrong with the hardware rather than with Windows operation.
The worst-case scenario is that the entire motherboard could fail. There are some signs you might look for, such as a swollen capacitor that may be damaged. Likewise, the failure of other components installed on the motherboard may also be the reason why the server cannot start. Thus, you need to replace the motherboard.
Fix 4: Uninstall Windows Server 2019 KB5009557 in Safe Mode
The last method for you to fix the “Windows Server 2019 not booting after update” issue is to uninstall Windows Server 2019 KB5009557 update. You need to follow the steps below.
1. Insert the Windows Server 2019 installation CD/DVD into the PC and change the boot drive in the BIOS to boot from it.
2. When prompted with Press any key to boot from CD or DVD, press a key to continue.
3. Select your preferred language, time and currency format, and keyboard or input method, and click on Next.
4. Select Repair your computer and click Next to proceed.
5. Then, choose the Command Prompt option.
6. Run the following command to remove the Windows Server 2019 KB5009557 update:
Windows Server 2019: wusa /uninstall /kb:KB5009557
For Windows Server 2012 R2 or Windows Server 2022, run the following commands.
- Windows Server 2012 R2: wusa /uninstall /kb:KB5009624
- Windows Server 2022: wusa /uninstall /kb:KB5009555
Final Words
This article aims to solve the “Windows Server updates cause PC boot loops” issue. It is strongly recommended to use the best backup software – MiniTool ShdowMaker to back up your Windows Server 2019 to avoid data loss.
-
-
#1
Hi all, good day. After i upgrade to the latest version 7.1-1, the windows server 2019 can’t boot up. The VM was created with best practice.
In addition, a huge amount of logs was written to /var/log. I got like 100G in around 5 minutes after the win 2019 boots.
Is there any workaround to have the current win 2019 vm to work like last time.
Here’s my pve info
root@pve1:~# pveversion -v
proxmox-ve: 7.1-1 (running kernel: 5.13.19-5-pve)
pve-manager: 7.1-10 (running version: 7.1-10/6ddebafe)
pve-kernel-helper: 7.1-12
pve-kernel-5.13: 7.1-8
pve-kernel-5.11: 7.0-10
pve-kernel-5.4: 6.4-4
pve-kernel-5.13.19-5-pve: 5.13.19-10
pve-kernel-5.13.19-4-pve: 5.13.19-9
pve-kernel-5.13.19-2-pve: 5.13.19-4
pve-kernel-5.11.22-7-pve: 5.11.22-12
pve-kernel-5.4.124-1-pve: 5.4.124-1
pve-kernel-5.4.106-1-pve: 5.4.106-1
ceph-fuse: 14.2.21-1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.1
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-6
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-3
libpve-guest-common-perl: 4.1-1
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.1-1
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.11-1
lxcfs: 4.0.11-pve1
novnc-pve: 1.3.0-2
proxmox-backup-client: 2.1.5-1
proxmox-backup-file-restore: 2.1.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-7
pve-cluster: 7.1-3
pve-container: 4.1-4
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-5
pve-ha-manager: 3.3-3
pve-i18n: 2.6-2
pve-qemu-kvm: 6.2.0-1
pve-xtermjs: 4.16.0-1
qemu-server: 7.1-4
smartmontools: 7.2-pve2
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.2-pve1
————————————
root@pve1:/var/log# ls -lah /var/log
total 311G
drwxr-xr-x 7 root root 4.0K Mar 2 10:34 .
drwxr-xr-x 11 root root 4.0K Apr 27 2021 ..
-rw-r—r— 1 root root 1.9K Mar 2 10:34 alternatives.log
drwxr-xr-x 2 root root 4.0K Mar 2 08:21 apt
-rw-r—— 1 root adm 12K Mar 2 10:35 auth.log
-rw-rw—- 1 root utmp 0 Mar 2 08:16 btmp
-rw-r—— 1 root adm 580K Mar 2 11:12 daemon.log
-rw-r—— 1 root adm 27K Mar 2 10:34 debug
-rw-r—r— 1 root root 902 Mar 2 08:21 dpkg.log
-rw-r—— 1 root adm 104G Mar 2 11:12 kern.log
-rw-rw-r— 1 root utmp 292 Mar 2 10:35 lastlog
drwxr-xr-x 2 root root 4.0K Mar 2 08:16 lxc
-rw-r—— 1 root adm 4.1K Mar 2 10:34 mail.info
-rw-r—— 1 root adm 4.1K Mar 2 10:34 mail.log
-rw-r—— 1 root adm 1.9K Mar 2 10:34 mail.warn
-rw-r—— 1 root adm 104G Mar 2 11:12 messages
drwx—— 2 root root 4.0K Mar 2 08:16 private
drwxr-xr-x 3 root root 4.0K Mar 2 08:15 pve
-rw-r—r— 1 root root 1.2K Mar 2 10:34 pve-firewall.log
drwxr-xr-x 2 root root 4.0K Mar 2 08:34 pveproxy
-rw-r—— 1 root adm 104G Mar 2 11:12 syslog
-rw-r—— 1 root adm 4.2K Mar 2 11:12 user.log
-rw-rw-r— 1 root utmp 21K Mar 2 10:35 wtmp
Last edited:
-
-
#2
can you show us part of the log from where the vm started ?
also what does
he windows server 2019 can’t boot up.
mean exactly? does it hang somewhere? do you get an error on vm start?
-
-
#3
can you show us part of the log from where the vm started ?
also what does
mean exactly? does it hang somewhere? do you get an error on vm start?
it hangs on the Windows logo
pardon me, not really an expert on pve.
where can i locate the logs for the vm?
Last edited:
-
-
#4
where can i locate the logs for the vm?
no i meant from the syslog file (the big one)
you can show the current log with ‘journalctl’ . with ‘-f’ you can ‘follow’ the log while trying to start for example, and when appending ‘> /tmp/filename’ you can output it into a file, then with ctrl+c abort it
so you can start
Code:
journalctl -f > /tmp/journal.logtry to start the vm, and then press ctrl+c to abort the journalctl command, then upload the /tmp/journal.log file
-
-
#5
no i meant from the syslog file (the big one)
you can show the current log with ‘journalctl’ . with ‘-f’ you can ‘follow’ the log while trying to start for example, and when appending ‘> /tmp/filename’ you can output it into a file, then with ctrl+c abort it
so you can start
Code:
journalctl -f > /tmp/journal.logtry to start the vm, and then press ctrl+c to abort the journalctl command, then upload the /tmp/journal.log file
thanks for the information.
I have uploaded the log to my google drive. you can download it from:
https://drive.google.com/file/d/1XYZbUOuJj9U85lIpSqao5gRTRfFG-0kW/view?usp=sharing
-
-
#6
issue resolved after i upgraded to a newer version. Here’s the info after upgrade/
proxmox-ve: 7.1-1 (running kernel: 5.13.19-6-pve)
pve-manager: 7.1-10 (running version: 7.1-10/6ddebafe)
pve-kernel-helper: 7.1-13
pve-kernel-5.13: 7.1-9
pve-kernel-5.11: 7.0-10
pve-kernel-5.4: 6.4-4
pve-kernel-5.13.19-6-pve: 5.13.19-14
pve-kernel-5.13.19-5-pve: 5.13.19-13
pve-kernel-5.13.19-4-pve: 5.13.19-9
pve-kernel-5.13.19-2-pve: 5.13.19-4
pve-kernel-5.11.22-7-pve: 5.11.22-12
pve-kernel-5.4.124-1-pve: 5.4.124-1
pve-kernel-5.4.106-1-pve: 5.4.106-1
ceph-fuse: 14.2.21-1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: not correctly installed
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.1
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-6
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-3
libpve-guest-common-perl: 4.1-1
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.1-1
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.11-1
lxcfs: 4.0.11-pve1
novnc-pve: 1.3.0-2
proxmox-backup-client: 2.1.5-1
proxmox-backup-file-restore: 2.1.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-7
pve-cluster: 7.1-3
pve-container: 4.1-4
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-6
pve-ha-manager: 3.3-3
pve-i18n: 2.6-2
pve-qemu-kvm: 6.1.0-3
pve-xtermjs: 4.16.0-1
qemu-server: 7.1-4
smartmontools: 7.2-pve2
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.2-pve1
В этой статье мы разберемся, как восстановить загрузчик Windows 10 или 11 на современном компьютере, на котором используется UEFI интерфейс вместо классического BIOS и таблица разделов диска GPT (вместо MBR). Повреждение загрузчика Windows может быть вызвано установкой второй ОС (Dual Boot — конфигурация), повреждением файловой систему, некорректным восстановлении Windows после сбоя, удалением скрытых разделов, вирусом-вымогателем и рядом других причин.
Данная статья содержит подробную пошаговую процедуру восстановления поврежденного или удаленного загрузчика ОС в Windows 11/10/8.1 и Windows Server 2022/2019/2016/2012R2 на компьютерах, которые работают в нативном (не legacy) режиме UEFI. Инструкцию можно использовать как для восстановления бинарных файлов загрузчика Windows, так и конфигурационного файла загрузчика EFI\Microsoft\Boot\BCD (в случаях, когда Windows не загружается из-за отсутствия или повреждения файла конфигурацией загрузка BCD.
Содержание:
- Не загружается Windows: Boot configuration data is missing EFI\Microsoft\Boot\BCD
- Автоматическое восстановление загрузчика Windows
- Ручное восстановление загрузчика Windows с помощью BCDBoot
Не загружается Windows: Boot configuration data is missing EFI\Microsoft\Boot\BCD
UEFI компьютер с Windows, установленной в наивном режиме, не сможет загрузиться при повреждении EFI загрузчика Windows. При попытке загрузиться с диска с повреждённым или отсутствующим EFI загрузчиком появится BSOD (синий экран смерти) с ошибкой:
The boot configuration data for your PC is missing or contains errors. File :\EFI\Microsoft\Boot\BCD Error code: 0xc000000f
или
Error code: 0xc000014c
В русской версии Windows ошибка может быть такая:
Ваш компьютер нуждается в ремонте Данные конфигурации загрузки для вашего ПК отсутствуют или содержат ошибки Файл:\EFI\Microsoft\Boot\BCD Код ошибки: 0xc000000f
Эта ошибка говорит о повреждении или даже полном удалении конфигурации загрузчика Windows — Boot Configuration Data (BCD). Если вы попытаетесь восстановить загрузчик на UEFI компьютере с помощью утилиты
bcdedit
, вы получите такую ошибку:
The boot configuration data store could not be found. The requested system device cannot be found.
Дело в том, что если Windows 10/11 установлена в нативном режиме UEFI на GPT диск, то EFI загрузчик Windows (Windows Boot Manager) хранит программу управления загрузкой и конфигурацию BCD на отдельном скрытом разделе EFI (размером 100 мб с файловой системой FAT32). Утилита bcdedit не видит этот EFI раздел, и соответственно не может управлять конфигурацией загрузчика на нем.
Если при загрузке Windows появляется только черный экран с надписью “Operating System not found”, скорее всего у вас полностью удален загрузчик Windows. Следуйте инструкции по ссылке.
Автоматическое восстановление загрузчика Windows
Процедура автоматического восстановления загрузчика, зашитая в среду восстановления Windows (WinRe), как правило, в таких случаях бессильна. Но попробовать все-же стоит:
- Загрузитесь с диска загрузочного диска, диска восстановления или установочной флешки с Windows 10 или 11;
- На экране установки нажмите кнопку Восстановление системы;
- Затем выберите пункт Поиск и устранение неисправностей -> Восстановление при загрузке и выберите ОС, загрузчик которой нужно попытаться восстановить;
- Но скорее всего результат будет отрицательный: Восстановление при загрузке не удалось восстановить компьютер
Ручное восстановление загрузчика Windows с помощью BCDBoot
Перейдем к процедуре ручного восстановления EFI загрузчика Windows на UEFI компьютере.
Для восстановления конфигурации загрузчика (BCD), вам нужно загрузить компьютер с оригинального установочного диска с Windows (диска восстановления или специально подготовленной установочной USB флешки с Windows ). После загрузки в среде восстановления нужно открыть окно командной строки: выберите Восстановление системы -> Диагностика -> Командная строка (System Restore -> Troubleshoot -> Command Prompt).
Командную строку также можно запустить, если у вас под рукой есть только установочный диск с Windows. Для этого достаточно на самом первом этапе установки Windows (при выборе языка и раскладки клавиатуры) нажать комбинацию клавиш Shift+F10 (или Shift+Fn+F10 на некоторых моделях ноутбуков).
В открывшейся командной строке выполните запустите утилиту управления дисками, набрав команду:
diskpart
Выведите список дисков в системе:
list disk
На этом этапе очень важно определить тип таблицы разделов на диске, на котором установлена Windows: MBR или GPT. Дело в том, что EFI загрузчик используется только на дисках с GPT разметкой.
Если у диска в столбце Gpt указана звездочка (
*
), тогда на диске используется таблица разделов GPT, если нет – MBR.
Если с помощью diskpart вы определили, что на вашем диске используется GPT разметка, следуйте дальнейшим шагам инструкции по восстановлению загрузчика.
Если у вас разметка MBR, тогда данная инструкция не применима к вашему компьютеру. Скорее всего у вас компьютер с BIOS, или в настройках UEFI включен режим совместимости Legacy/Compatibility Support Module/CSM.
На MBR дисках загрузчик хранится на отдельном разделе System Reserved, а не на EFI разделе (ни в коем случае не конвертируйте таблицу разделов MBR в GPT, пока не исправите загрузчик!!) Используйте другую инструкцию по восстановлению BCD загрузчика на MBR (Master Boot Record) диске.
Выберите диск, на котором установлена ваша Windows (если жесткий диск в системе один, его индекс должен быть равен 0):
sel disk 0
Выведите список томов и разделов в системе:
list partition
list volume
В нашем примере видно, что загрузочный раздел EFI имеет индекс Partition2 (он же Volume 5 с меткой Hidden). Проще всего определить EFI размер по файловой системе FAT32, размеру 100 Мб (это стандартный минимальный размер для Windows компьютеров, в редких случая размер раздела может быть). Чаще всего для него используется метка — System EFI или ESP/ EFI System Partion).
В нашем примере основной раздел, на который установлена Windows, имеет индекс volume 2, отформатирован в файловая система NTFS и ему назначена буква C:.
В вашем случае назначенная буква диске может отличаться. Это зависит, как вы загрузили свой компьютер в среде WinPE. Проще всего определить его по размеру. Если вы не уверены, нужно проверить что на этом диске есть каталог Windows. Выйдите из утилиты diskpart (команда exit) и выполните команду:
dir C:\
Убедитесь, что на этом диске есть каталоги
Windows
,
Program Files
,
Users
и прочие.
Если этих каталогов нет, значит вашему диску с Windows назначена другая буква диска. Проверьте содержимоет дисков с другими буквами.
Запомните букву диска, назначенную разделу с Windows, чуть ниже мы будем использовать ее в качестве одного из аргументов команды bcdboot.
В таблице также обязательно должен быть раздел MSR (Microsoft System Reserved) размером 16 мб в Windows 10/11 (или 128 Мб в Windows 8.1).
Назначьте скрытому EFI разделу произвольную букву диска (например, M:):
select volume 5
assign letter M:
Должна появится строка, свидетельствующая об успешном назначении буквы диска разделу EFI:
DiskPart successfully assigned the drive letter or mount point.
Завершите работу с diskpart:
exit
Перейдите в каталог с загрузчиком на скрытом разделе:
cd /d m:\efi\microsoft\boot\
В данном случае M: это буква диска, присвоенная разделу EFI чуть выше. Если каталог \EFI\Microsoft\Boot\ отсутствует
The system cannot find the path specified
), попробуйте следующие команды:
cd /d M:\Boot\
или
cd /d M:\ESD\Windows\EFI\Microsoft\Boot\
На этом этапе многие рекомендуют выполнить следующие команды, которые должны перезаписать загрузочную запись раздела, найти установленные Windows и добавить их в BCD:
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd
или даже:
bootrec /FixMbr
(восстановление MBR записи для GPT диска выглядит странным)
Все эти команды применимы только для дисков с MBR. Если ваш компьютер загружается в UEFI режиме, то на нем обязательно используется таблица разделов GPT (как раз наш случай). Поэтому при запуске команд
bootrec
вы увидите ошибку:
access is denied
Для исправления загрузочных записей на EFI разделе нужно использовать утилиту
BCDBoot
, а не bootrec.
Утилита BCDBoot позволяет восстановить файлы загрузчика на EFI разделе, скопировав их системного каталога на разделе с Windows. Конфигурация загрузчика BCD пересоздается с помощью шаблона %WINDIR%\System32\Config\BCD-Template.
С помощью команды
attrib
снимите атрибуты скрытый, read-only и системный с файла BCD:
attrib BCD -s -h -r
Удалите текущий файл с конфигурацией BCD, переименовав его (так вы сохраните старую конфигурацию в качестве резервной копии):
ren BCD BCD.bak
С помощью утилиты bcdboot.exe нужно скопировать из системного каталога критические файлы среды загрузки UEFI в загрузочный EFI раздел и пересоздать конфигурацию загрузчика в хранилище BCD:
bcdboot C:\Windows /l en-us /s M: /f ALL
где,
- C:\Windows – путь к корневому системному каталогу Windows на диске (это ваш диск, на который была установлена ваша Windows, мы узнали его ранее с помощью команды diskpart);
- /f ALL – означает, что необходимо скопировать файлы среды загрузки Windows, включая файлы для компьютеров с UEFI и BIOS (теоретическая возможность загружаться на EFI и BIOS системах). Чтобы скопировать только EFI загрузчик, используйте команду /f UEFI;
- /l en-us — определяет языковой стандарт, который используется при инициализации хранилища BCD. По умолчанию используется en-US — английский язык (США);
- /s M: — скопировать файлы EFI загрузчика на указанный раздел;
- /с – эта новая опция BCDBoot в Windows 10, которая позволяет перезатереть имеющиеся загрузочные записи при создании нового хранилища (в том числе debugsettings). Используйте этот параметр, чтобы игнорировать старые настройки и создать полностью чистую конфигурацию BCD загрузчика;
- /v – используется для включения режима вывода подробной информации BCDBoot..
Теперь, если выполнить команду bcdedit, вы увидите следующую картину:
В секции диспетчера загрузки Windows (Windows Boot Manager) должна появится запись, указывающая на полный путь к файлу управления загрузкой UEFI. В этом примере он находится на разделе 2 (
partition=\Device\HarddiskVolume2
), путь
\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
.
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume2
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
bootshutdowndisabled Yes
default {CURRENT}
resumeobject {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.efi
description Windows Server 10
locale en-US
inherit {bootloadersettings}
recoverysequence {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
В секции Windows Boot Manager должен быть указан путь к EFI разделу (
=\Device\HarddiskVolume2
), путь к файлу управления загрузкой (bootmgfw.efi). В секции Windows Boot Loader указан раздел Windows и путь к EFI загрузчику Windows (
\Windows\system32\winload.efi
). При включении компьютер передаст управление диспетчеру загрузки EFI, который запустит загрузчик Windows.
Возможные ошибки:
Перезагрузите компьютер, отключите загрузочный диск. Если вы все сделали правильно, в выборе устройств загрузки должен появиться пункт Windows Boot Manager в котором можно выбрать загрузку нужной операционной системы. Ваш EFI загрузчик и конфигурация BCD успешно восстановлены!
В некоторых случаях после восстановления BCD загрузчика, при загрузке Windows появляется ошибка
BAD SYSTEM CONFIG INFO
. Чтобы исправить ошибку:
Убедитесь, что вы не вносили недавно изменения в настройки UEFI
Загрузитесь с установочной/загрузочной флешки и измените конфигурацию загрузчика командами:
-
bcdedit /deletevalue {default} numproc -
bcdedit /deletevalue {default} truncatememory
A customer informed us that some users were getting a black screen after logon and others could not open the start menu after they got past the black screen. The customer restarted the RDS host but the issue was not resolved.
When checking the event logs I noticed system events with ID 10001 like the one below
This led me to think there was an issue with Appx and came across some material that suggested repairing Cortana. Trying to run the suggested PowerShell command failed and upon reviewing the AppPackage Log as suggested by the failure error I noticed that the package did not install because of insufficient resources. The system had only 6GB out of 128GB ram used and CPU (8 Cores) were at 2%
Searching further, I found this technet forum post in which the cause and solution are discussed.
Basically, every time a user logs into the RDS server, a new set of firewall rules is created and are not removed when the users log off, but new ones are re-created when they login again. This appears to happen most when using User Profile Disks (UPD). You may notice at this time that when trying to open WWindows Defender Firewall with Advanced Security to view the rules, the window would take a very long time to appear and end up in a “Not Responding” state.
This was resolved in Windows Server 2016 and 2019 by installing a Windows update, link for 2016 and 2019, and manually applying a registry key.
The updates were already installed so we proceeded to add the registry key as per below using Regedit.
Add “DeleteUserAppContainersOnLogoff” (DWORD) in “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy” and set it to 1.
We logged off and logged back in and the Start menu was working again. All the other users also reported that this resolved the issue.
At this stage it is suggested that the previously created firewall rules are also deleted. These are the registry keys were the rules are stored.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules (Server 2016 and 2019)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\\RestrictedServices\AppIso\FirewallRules (Server 2019 only)
Instead of deleting the whole set of entries, we decided on taking another path and use the PowerShell script provided by user Paul Boerefijn CCS which removes the firewall rules and keeps a set of unique rules. The process was going to take over 15hrs to remove 12,000 inbound rules and we don’t know how long it was going to take to remove the outbound rules. So instead we used a different script found on stackoverflow which rather than using the “Remove-NetFirewallRule” PowerShell command it removed the rules directly from within the registry with the “Remove-ItemProperty” command which sped up the process and all 30,000 rules were deleted in 1.5Hrs. The script used is available below with some minor additions
NOTE Make sure that you change the Rule2 deletion line to match the correct registry path depending on which windows server version you are running it on. These are indicated in the script
#Script thanks to user js2010
#source https://stackoverflow.com/a/40915201
#added registry paths notes
$profiles = get-wmiobject -class win32_userprofile
Write-Host "Getting Firewall Rules"
# deleting rules with no owner would be disastrous
$Rules = Get-NetFirewallRule -All |
Where-Object {$profiles.sid -notcontains $_.owner -and $_.owner }
Write-Host "Getting Firewall Rules from ConfigurableServiceStore Store"
$rules2 = Get-NetFirewallRule -All -PolicyStore ConfigurableServiceStore |
Where-Object { $profiles.sid -notcontains $_.owner -and $_.owner }
$total = $rules.count + $rules2.count
Write-Host "Deleting" $total "Firewall Rules:" -ForegroundColor Green
$result = measure-command {
# tracking
$start = Get-Date; $i = 0.0 ;
foreach($rule in $rules){
# action
remove-itemproperty -path "HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules" -name $rule.name
# progress
$i = $i + 1.0
$prct = $i / $total * 100.0
$elapsed = (Get-Date) - $start;
$totaltime = ($elapsed.TotalSeconds) / ($prct / 100.0)
$remain = $totaltime - $elapsed.TotalSeconds
$eta = (Get-Date).AddSeconds($remain)
# display
$prctnice = [math]::round($prct,2)
$elapsednice = $([string]::Format("{0:d2}:{1:d2}:{2:d2}", $elapsed.hours, $elapsed.minutes, $elapsed.seconds))
$speed = $i/$elapsed.totalminutes
$speednice = [math]::round($speed,2)
Write-Progress -Activity "Deleting rules ETA $eta elapsed $elapsednice loops/min $speednice" -Status "$prctnice" -PercentComplete $prct -secondsremaining $remain
}
# tracking
# $start = Get-Date; $i = 0 ; $total = $rules2.Count
foreach($rule2 in $rules2) {
# action
#change path according to the Windows Server version used:
#Windows Server 2019 Path = "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\AppIso\FirewallRules"
#Windows Server 2016 Path = "HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
remove-itemproperty -path "HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System" -name $rule2.name
# progress
$i = $i + 1.0
$prct = $i / $total * 100.0
$elapse = (Get-Date) - $start;
$totaltime = ($elapsed.TotalSeconds) / ($prct / 100.0)
$remain = $totaltime - $elapsed.TotalSeconds
$eta = (Get-Date).AddSeconds($remain)
# display
$prctnice = [math]::round($prct,2)
$elapsednice = $([string]::Format("{0:d2}:{1:d2}:{2:d2}", $elapsed.hours, $elapsed.minutes, $elapsed.seconds))
$speed = $i/$elapsed.totalminutes
$speednice = [math]::round($speed,2)
Write-Progress -Activity "Deleting rules2 ETA $eta elapsed $elapsednice loops/min $speednice" -Status "$prctnice" -PercentComplete $prct -secondsremaining $remain
}
}
$end = get-date
write-host end $end
write-host eta $eta
write-host $result.minutes min $result.seconds secOnce the script completes, the rules are removed and you will notice that the Windows Defender Firewall with Advanced Security window would open normally.
Both scripts catered to avoid deleting the rules which had no owner set in the properties. Deleting these rules could case problems.
The purpose of this blog post is to try and consolidate all the information we found to resolve the issue. A big thanks goes to all the contributors in the different forums.
Hope you find it useful.
By Brian Farrugia
I am the author of Phy2Vir.com. More info can be found on the about page.