Embedded Files
Розслідування Error 32 та перевірка Capture у Windows 11
Практичне дослідження процесу створення install.wim та install.esd із використанням DISM, WinPE та VirtualBox.
Передумови
Під час роботи над Builder-проєктами було помічено нестабільну поведінку команди:
DISM /Capture-Image
У ряді випадків створення install.wim або install.esd завершувалося помилкою Error 32.
Спочатку існувало припущення, що проблема пов'язана з новими збірками Windows 11, оскільки попередні версії іноді проходили Capture успішно, а нові — ні.
Особливу підозру викликали збірки Windows 11 за 2026 рік.
Метою дослідження стало визначення реальної причини виникнення Error 32.
Симптоми Error 32
Симптоми Error 32
Типове повідомлення:
Error: 32
The process cannot access the file because it is being used by another process.
На перший погляд повідомлення вказувало на блокування файлу install.wim або install.esd.
Перевірка показала:
• флешка працює справно;
• запис на носій можливий;
• install.wim видаляється без проблем;
• створення тестових файлів проходить успішно;
• DISM запускається коректно.
Таким чином причина виявилася складнішою за звичайне блокування файлу.
Початкові гіпотези
Початкові гіпотези
Розглядалися наступні варіанти:
Пошкодження флешки.
Недостатні права доступу.
Помилка VirtualBox.
Несумісність нових збірок Windows 11.
Зміни у DISM.
Проблема із Sysprep.
Неправильне середовище запуску Capture.
Усі версії поступово перевірялися експериментально.
Аналіз середовища запуску
Аналіз середовища запуску
У процесі тестування було виявлено ключову закономірність.
Після завантаження через інсталяційний ISO Windows та натискання Shift+F10 відкривалося середовище:
X:\sources>
або
X:\Windows\System32>
Саме в цьому середовищі Capture працював коректно.
Натомість після запуску встановленої системи команда виконувалася з:
C:\Windows\System32>
і саме в цьому випадку регулярно виникав Error 32.
Даний факт став ключовим для подальшого розслідування.
Відмінність середовищ запуску
Відмінність середовищ запуску
X:\sources>
Середовище Windows PE.
Запуск здійснюється з інсталяційного ISO.
Рекомендовано для Capture.
Ризик Error 32:
Мінімальний.
──────────────────────────────────────
X:\Windows\System32>
Середовище Windows PE.
Також підходить для Capture.
Рекомендовано.
Ризик Error 32:
Мінімальний.
──────────────────────────────────────
C:\Windows\System32>
Запущена встановлена Windows.
Система використовує той самий розділ, який намагаються захопити через DISM.
Може призводити до Error 32.
Рекомендовано уникати використання цього середовища для Capture.
Тестування install.wim
Тестування install.wim
Виконано Capture у середовищі WinPE.
Створено файл:
install.wim
Перевірка:
DISM /Get-WimInfo /WimFile:"install.wim"
Результат:
The operation completed successfully.
Файл успішно читається DISM.
Образ визнано коректним.
Тестування install.esd
Тестування install.esd
Виконано Capture у середовищі WinPE.
Створено файл:
install.esd
Перевірка:
DISM /Get-WimInfo /WimFile:"install.esd"
Результат:
The operation completed successfully.
Образ успішно читається DISM.
Структура файлу коректна.
Перевірка створених ISO
Перевірка створених ISO
На базі install.wim та install.esd були створені окремі ISO-образи.
Було проведено тестове встановлення системи.
Результати:
ISO з install.wim → Установка успішна.
ISO з install.esd → Установка успішна.
Помилок під час інсталяції не виявлено.
Результати
Результати
Capture install.wim
→ Успішно.
Capture install.esd
→ Успішно.
Перевірка Get-WimInfo
→ Успішно.
Створення ISO
→ Успішно.
Установка з install.wim
→ Успішно.
Установка з install.esd
→ Успішно.
Висновки
Висновки
Проведене тестування показало, що останні версії Windows 11 продовжують повноцінно підтримувати:
• install.wim;
• install.esd;
• DISM Capture;
• створення ISO;
• подальше встановлення системи.
Основною причиною появи Error 32 виявилося не пошкодження збірок Windows і не зміни в DISM.
Ключовим фактором стало середовище запуску Capture.
***
Builder Note 😏☕
Під час тестування виникла підозра, що нові збірки Windows 11 більше не підтримують створення install.wim та install.esd.
Подальше дослідження показало, що проблема була пов'язана з виконанням Capture із середовища встановленої системи.
Після переходу до WinPE:
X:\sources>
або
X:\Windows\System32>
створення install.wim та install.esd виконувалося успішно навіть на найновіших доступних збірках Windows 11.
══════════════════════════════════════
Статус Error 32
══════════════════════════════════════
Причина встановлена.
Випадок закрито.
Рішення:
Виконувати Capture із WinPE.
Результат:
install.wim ✅
install.esd ✅
ISO Build ✅
Installation ✅
Error 32
Статус:
Звільнений за власним бажанням 😄☕
Вплив режимів UEFI та Legacy на поведінку VirtualBox після Sysprep
Вплив режимів UEFI та Legacy на поведінку VirtualBox після Sysprep
Категорія:
VirtualBox
Windows 11
Sysprep
WinPE
Мета дослідження:
Перевірити, чи впливають:
• режим завантаження UEFI/Legacy;
• версія VirtualBox;
на поведінку системи після виконання Sysprep та подальшого запуску віртуальної машини.
══════════════════════════════════════
Передумови
══════════════════════════════════════
Під час розслідування Error 32 було помічено дивну поведінку.
В одних випадках після Sysprep команда Capture виконувалася успішно.
В інших випадках відкривалося зовсім інше середовище, що призводило до неможливості виконання Capture.
Виникла гіпотеза, що причина може бути пов'язана:
• з новими версіями VirtualBox;
• з режимом UEFI;
• зі способом завантаження Windows після Sysprep.
Для перевірки було проведено окреме дослідження
══════════════════════════════════════
Методика тестування
══════════════════════════════════════
Для кожного тесту використовувалася однакова схема:
Встановлення Windows 11.
Вхід до Audit Mode.
Виконання Sysprep.
Вибір Shutdown.
Повторний запуск ВМ.
Перевірка середовища запуску.
Особлива увага приділялася командному рядку після запуску.
══════════════════════════════════════
Результати тестування
══════════════════════════════════════
VirtualBox | Режим | UEFI | Командний рядок | Capture
7.2.8 | Legacy | OFF | X:\Windows\System32> | Успішно
7.2.8 | UEFI | ON | C:\Windows\System32> | Не рекомендовано
6.1.50 | Legacy | OFF | X:\Windows\System32> | Успішно
6.1.50 | UEFI | ON | C:\Windows\System32> | Не рекомендовано
══════════════════════════════════════
Аналіз результатів
══════════════════════════════════════
Було встановлено:
VirtualBox 6.1.50 та VirtualBox 7.2.8 демонструють однакову поведінку.
Залежність від версії VirtualBox не підтвердилася.
Натомість підтверджено залежність від режиму завантаження.
──────────────────────────────────────
UEFI OFF (Legacy)
Після запуску доступне середовище:
X:\Windows\System32>
Дане середовище належить WinPE.
Саме в ньому успішно виконувалися:
• DISM /Capture-Image
• створення install.wim
• створення install.esd
──────────────────────────────────────
UEFI ON
Після запуску доступне середовище:
C:\Windows\System32>
У цьому випадку система працює з установленою Windows.
Для Capture даний варіант не рекомендується.
══════════════════════════════════════
Додаткове спостереження
══════════════════════════════════════
Під час тестування Windows 11 було помічено, що при ввімкненому UEFI завантаження часто відбувається не через WinPE, а через встановлену систему.
Це може призводити до:
• повернення в OOBE;
• запуску встановленої Windows;
• появи C:\Windows\System32> замість X:\Windows\System32>.
══════════════════════════════════════
Порівняння з Windows 10
══════════════════════════════════════
Під час попередньої роботи з Windows 10 подібна поведінка не спостерігалася.
На момент написання документа причина відмінності між Windows 10 та Windows 11 остаточно не встановлена.
Потребує подальшого дослідження.
══════════════════════════════════════
Висновки
══════════════════════════════════════
1 Версія VirtualBox не впливає на результат.
Підтверджено для:
• VirtualBox 6.1.50
• VirtualBox 7.2.8
2 Основним фактором є режим завантаження.
UEFI OFF (Legacy)
→ X:\Windows\System32>
→ WinPE
→ Capture працює.
UEFI ON
→ C:\Windows\System32>
→ встановлена Windows
→ Capture не рекомендується.
3 Для Builder-проєктів рекомендовано виконувати Capture лише із середовища WinPE
══════════════════════════════════════
Builder Note 😏☕
Під час розслідування існувала підозра, що нові версії VirtualBox змінили поведінку після Sysprep.
Порівняння VirtualBox 6.1.50 та 7.2.8 показало однакові результати.
Підозра знята.
VirtualBox 6.1.50:
невинний ☕
VirtualBox 7.2.8:
невинний ☕
Справжнім підозрюваним виявився режим UEFI
Windows Boot Manager, UEFI та механізм завантаження Windows 11.
══════════════════════════════════════
Builder Note ☕
Під час дослідження було перевірено:
• install.wim
• install.esd
• WinPE
• Sysprep
• VirtualBox 6.1.50
• VirtualBox 7.2.8
• UEFI
• Legacy BIOS
Усі результати були підтверджені практичними тестами.
Статус Error 32:
Причина встановлена.
Випадок закрито.
GPT, UEFI та Windows Boot Manager
GPT, UEFI та Windows Boot Manager
Категорія:
Windows 11
UEFI
GPT
Windows Boot Manager
══════════════════════════════════════
Передумови
══════════════════════════════════════
Після завершення дослідження B.11 виникло нове питання.
Було встановлено, що після Sysprep та запуску системи в режимі UEFI командний рядок відкривався як:
C:\Windows\System32>
У режимі Legacy:
X:\Windows\System32>
Це привело до додаткового дослідження механізму завантаження Windows 11.
══════════════════════════════════════
Мета дослідження
══════════════════════════════════════
Встановити:
• яку роль виконує Windows Boot Manager;
• чи використовує Windows 11 GPT;
• чи залежить завантаження системи від UEFI;
• який фактичний ланцюг завантаження використовується сучасними збірками Windows 11.
══════════════════════════════════════
Початкові гіпотези
══════════════════════════════════════
Причиною є лише режим UEFI.
Причиною є Windows Boot Manager.
Причиною є зв'язка:
GPT
+
EFI System Partition
+
Windows Boot Manager
+
UEFI.
══════════════════════════════════════
Тестування
══════════════════════════════════════
Перевірка 1
Розмітка диска.
Результат:
GPT.
──────────────────────────────────────
Перевірка 2
Інсталяція Windows 11 при:
UEFI = OFF
Secure Boot = OFF
Результат:
Інсталяція неможлива.
Відображається повідомлення про несумісність системи.
Перевірка 3
Інсталяція Windows 11 при:
UEFI = ON
Secure Boot = ON
Результат:
Інсталяція виконується успішно.
──────────────────────────────────────
Перевірка 4
Дослідження BCD.
Команда:
bcdedit /enum all
Отримані результати:
Windows Boot Manager
path
\EFI\Microsoft\Boot\bootmgfw.efi
──────────────────────────────────────
Windows Boot Loader
path
\Windows\system32\winload.efi
══════════════════════════════════════
Аналіз результатів
══════════════════════════════════════
Було встановлено, що система використовує:
bootmgfw.efi
та
winload.efi
Обидва компоненти належать до механізму UEFI-завантаження.
Також підтверджено використання GPT-розмітки диска.
══════════════════════════════════════
Фактичний ланцюг завантаження
══════════════════════════════════════
GPT
↓
EFI System Partition
↓
bootmgfw.efi
↓
Windows Boot Manager
↓
winload.efi
↓
Windows 11
══════════════════════════════════════
Висновки
══════════════════════════════════════
1 Windows 11 встановлена на диск GPT.
2 Система використовує механізм UEFI-завантаження.
3 Windows Boot Manager є штатним компонентом процесу завантаження.
4 При вимкненні UEFI встановлення Windows 11 у проведених тестах було неможливим.
5 Отримані результати підтверджують використання зв'язки:
GPT
↓
UEFI
↓
Windows Boot Manager
↓
Windows 11
══════════════════════════════════════
Підсумок дослідження
══════════════════════════════════════
Гіпотеза про використання GPT підтвердилася.
Гіпотеза про використання Windows Boot Manager підтвердилася.
Гіпотеза про використання UEFI підтвердилася.
Механізм завантаження встановлено експериментально.
══════════════════════════════════════
Статус дослідження
══════════════════════════════════════
Завершено.
Результат підтверджено практичними тестами.
Подальші питання щодо:
• Secure Boot;
• змін BCD після Sysprep;
• відмінностей між Windows 10 та Windows 11;
винесено до наступних досліджень.
══════════════════════════════════════
Builder Note ☕
Під час дослідження було встановлено, що Windows Boot Manager не є причиною проблеми.
Навпаки, він є штатною частиною механізму завантаження Windows 11.
Отримані результати підтверджують використання сучасної схеми:
GPT
→ UEFI
→ Windows Boot Manager
→ Windows 11
Статус розслідування:
Механізм встановлено.
Справу закрито.
Поведінка Windows 11 в умовах повноцінного Legacy BIOS
Поведінка Windows 11 в умовах повноцінного Legacy BIOS
Мета дослідження:
Встановити фактичну поведінку Windows 11
при відсутності UEFI та Secure Boot.
Дослідити:
• запуск інсталятора;
• перевірку сумісності;
• реакцію на Legacy BIOS;
• реакцію на MBR;
• можливість завершення інсталяції;
• можливість першого запуску системи.
Основне питання:
Чи може сучасна Windows 11
працювати в середовищі Legacy BIOS
без використання UEFI?
Початкова гіпотеза:
Windows 11 визначає відсутність UEFI
ще під час перевірки сумісності
та блокує інсталяцію.
Очікуваний результат:
Повідомлення про несумісність системи.
Статус:
Планується.
_____________________________________
UEFI = ON
Secure Boot = OFF
↓
TPM version = OFF
↓
ISO запускається ✅
↓
Інсталятор запускається ✅
↓
Вибір редакції Windows ✅
↓
Перевірка сумісності ❌
↓
"Цей ПК не відповідає
мінімальним вимогам Windows 11"
___________________________________
UEFI = ON
Secure Boot = ON
↓
TPM version = 1.2
↓
ISO запускається ✅
↓
Інсталятор запускається ✅
↓
Вибір редакції Windows ✅
↓
Перевірка сумісності ❌
↓
"Цей ПК не відповідає
мінімальним вимогам Windows 11"
Примітка: в обидвох випадках I/O APIC✅
__________________________________
UEFI = ON
Secure Boot = ON
↓
TPM version = 2.0
↓
ISO запускається ✅
↓
Інсталятор запускається ✅
↓
Вибір редакції Windows ✅
↓
Перевірка сумісності ✅
↓
Вибір розділу для інсталяції ✅
ПРИМІТКИ:
1 Функцію features вимкнути не можливо
2 Усі вище згадані операції проводилися у режимі GPT. Переформатування у MBR не можливе. Система видає повідомлення:
"Invalid drive specification"
3 При вимкненні UEFI інсталятор Windows 11 запускається успішно.
Блокування відбувається під час перевірки сумісності системи.
Page updated
Google Sites
Report abuse