ТИПОВІ ПОМИЛКИ BUILDER

У цьому розділі зібрано типові проблеми, які можуть виникати під час роботи з:

• Windows Setup

• WinPE

• Audit Mode

• Sysprep

• DISM

• install.wim

• boot.wim

Усі приклади засновані на реальних експериментах та практичних дослідженнях.

Builder Rule 😏☕

Більшість помилок виникає не через Windows.

Більшість помилок виникає через неправильні припущення про те, як працює Windows.

Помилка №1 Відсутня папка Mount

Симптом

Під час виконання команди:

DISM /Mount-Wim /WimFile:"D:\install.wim" /Index:1 /MountDir:"D:\Mount"

DISM завершує роботу з помилкою:

Error: 0xc1420115

 The user attempted to mount to a directory that does not exist.

Причина

Папка, вказана в параметрі:

/MountDir

не існує.

DISM не створює каталог автоматично.

Неправильний підхід

Виконати Mount-Wim до створення папки.

Правильний підхід

Створити каталог:

mkdir D:\Mount

Після цього повторити команду монтування.

Перевірка

Перед монтуванням переконатися, що каталог існує:

dir D:\Mount

Рішення

1. Створити папку Mount.

2. Повторити команду Mount-Wim.

3. Переконатися, що помилка зникла.

Builder Observation 😏☕

Якщо DISM скаржиться на відсутній каталог, проблема не в install.wim.

Проблема в точці монтування.

Статус

☑ Практично підтверджено

Помилка №2 Монтування на Removable Drive

Симптом

Під час виконання команди:

DISM /Mount-Wim /WimFile:"D:\install.wim" /Index:1 /MountDir:"D:\Mount"

DISM завершує роботу з помилкою:

Error: 0xc1420134

The drive of the specified mount path is not supported.

Please mount to a volume on a fixed drive.

─────────────────────────────────────

Причина

DISM дозволяє монтувати образи лише на Fixed Drive.

Папка Mount може існувати.

Файл install.wim може бути справним.

Однак якщо каталог монтування знаходиться на Removable Drive, операція буде відхилена.

─────────────────────────────────────

Дослідження

Перевірка типу дисків:

wmic logicaldisk get deviceid,drivetype

─────────────────────────────────────

Результат:

DeviceID  DriveType

C:    3

D:    2

─────────────────────────────────────

Розшифрування

DriveType 3

↓

Fixed Drive

──────────────────────────────────────

DriveType 2

↓

Removable Drive

─────────────────────────────────────

Неправильний підхід

Монтування образу до:

D:\Mount

коли диск визначається як Removable Drive.

─────────────────────────────────────

Правильний підхід

Створити каталог:

C:\Mount

та виконати:

DISM /Mount-Wim /WimFile:"D:\install.wim" /Index:1 /MountDir:"C:\Mount"

─────────────────────────────────────

Рішення

1. Перевірити тип диска.

2. Використовувати Fixed Drive.

3. Повторити монтування.

─────────────────────────────────────

Builder Observation 😏☕

DISM може читати install.wim з Removable Drive.

Але монтувати образ дозволяє тільки на Fixed Drive.

─────────────────────────────────────

Статус

☑ Практично підтверджено

Помилка №3 Системний диск не завжди C:\

Симптом

Під час роботи у WinPE користувач виконує команди, вважаючи, що встановлена Windows знаходиться на:

C:\

Однак потрібні файли відсутні або команди працюють не з тим розділом.

Причина

У середовищі WinPE літери дисків можуть відрізнятися від тих, що використовуються у встановленій системі.

Наприклад:

Звичайна Windows

↓

C:\

──────────────────────────────────────

Після завантаження у WinPE

↓

D:\

або

E:\

або інша літера

Неправильний підхід

Автоматично вважати, що системний розділ завжди має літеру:

C:\

Правильний підхід

Перед виконанням Capture, Apply або інших операцій визначити фактичне розташування Windows.

Наприклад:

diskpart

↓

list volume

або

dir C:\

dir D:\

dir E:\

Можливі наслідки

• Capture не того розділу.

• Apply не на той диск.

• Помилки під час копіювання файлів.

• Втрата часу на пошук неіснуючої проблеми.

Рішення

1. Завантажитися у WinPE.

2. Перевірити літери томів.

3. Знайти фактичний системний розділ.

4. Лише після цього виконувати робочі команди.

─────────────────────────────────────

Builder Observation

У WinPE найбільш небезпечне припущення:

"Я точно знаю де C:"

Зазвичай саме після цієї думки і починаються пригоди 😄

─────────────────────────────────────

Статус

☑ Практично підтверджено

Помилка №4 Вважати install.esd основним файлом встановлення

Симптом

У каталозі:

sources

одночасно знаходяться:

install.wim

та

install.esd

Користувач очікує, що Windows Setup використає install.esd.

Причина

Поширене припущення:

install.esd

=

головний файл встановлення Windows.

Практичний експеримент

У каталозі sources були одночасно присутні:

install.wim

та

install.esd

Під час встановлення система використала:

install.wim

Результат

install.esd не був використаний.

Інсталяція завершилася через install.wim.

Неправильний підхід

Вважати, що Setup автоматично обирає install.esd.

Правильний підхід

Перед експериментами перевіряти:

• які файли знаходяться у sources;

• який формат використовується;

• який файл має пріоритет.

Попередній висновок

За наявності одночасно:

install.wim

та

install.esd

Windows Setup віддає пріоритет install.wim.

══════════════════════════════════════

Builder Observation 😏☕

Факт існування install.esd ще не означає, що Setup буде використовувати саме його.

══════════════════════════════════════

Статус

☑ Практично підтверджено

Помилка №5 Недооцінка ролі boot.wim

Симптом

Після заміни boot.wim Windows Setup починає поводитися не так, як очікувалося.

Можливі прояви:

• повідомлення про відсутність драйверів;

• зміна поведінки Setup;

• неможливість продовження встановлення;

• завантаження іншого середовища встановлення.

Причина

Поширене припущення:

install.wim

=

Windows

boot.wim

=

другорядний файл

Реальність

boot.wim містить:

• WinPE;

• Windows Setup;

• середовище встановлення;

• драйвери середовища інсталяції.

Практичне спостереження

Під час експериментів зміна install.wim не впливала на запуск Setup.

Проте зміна boot.wim призводила до зміни поведінки середовища встановлення.

Неправильний підхід

Замінювати boot.wim без розуміння його призначення.

Правильний підхід

Перед будь-якими змінами пам'ятати:

boot.wim

↓

запускає Setup

↓

Setup працює через WinPE

↓

WinPE встановлює install.wim

Попередній висновок

Якщо install.wim можна порівняти з майбутньою Windows,

то boot.wim є середовищем, яке цю Windows встановлює.

══════════════════════════════════════

Builder Observation

Багато Builder-ів бояться змінювати install.wim.

Насправді набагато обережніше слід поводитися саме з boot.wim.

══════════════════════════════════════

Статус

☑ Практично підтверджено

Помилка №6 Запуск Sysprep без розуміння наслідків

Симптом

Після запуску Sysprep система поводиться не так, як очікував користувач.

Можливі прояви:

• повторний запуск OOBE;

• зміна облікових записів;

• скидання частини налаштувань;

• необхідність повторного налаштування системи.

Причина

Поширене припущення:

Sysprep

=

звичайне перезавантаження Windows

Реальність

Sysprep виконує підготовку Windows до розгортання.

Після його запуску система може:

• видалити унікальні ідентифікатори;

• підготувати систему до Capture;

• повернутися до OOBE;

• завершити поточний цикл налаштування.

Неправильний підхід

Запускати Sysprep "для перевірки що буде".

Правильний підхід

Перед запуском відповісти на питання:

Для чого запускається Sysprep?

• Capture?

• Підготовка образу?

• Перехід до OOBE?

• Тестування?

Рекомендація

Передпершим запуском використовувати:

Віртуальну машину.

Builder Observation 😏☕

Sysprep не ламає Windows.

Він просто дуже сумлінно виконує те, що йому наказали.

Проблеми зазвичай виникають тоді, коли Builder сам не знає, що наказав 😄

══════════════════════════════════════

Практична порада

Перед запуском Sysprep бажано створити:

• Snapshot;

або

• резервну копію віртуальної машини.

Статус

☑ Практично підтверджено

Помилка №7 Виконання Capture без Sysprep

Симптом

Створений образ успішно захоплюється (Capture).

Образ успішно встановлюється.

Однак після встановлення можуть виникати:

• некоректні профілі користувачів;

• дублювання системних ідентифікаторів;

• проблеми з активацією;

• проблеми в мережевому середовищі;

• непередбачувана поведінка системи.

Причина

Поширене припущення:

Capture можна виконувати одразу після налаштування Windows.

Реальність

Capture зберігає поточний стан системи.

Якщо система не була підготовлена через Sysprep, у образ можуть потрапити:

• унікальні SID;

• службова інформація поточного встановлення;

• дані користувачів;

• залишки налаштувань середовища.

Неправильний підхід

Windows

↓

Налаштування

↓

Capture

Правильний підхід

Windows

↓

Audit Mode

↓

Налаштування

↓

Sysprep

↓

Shutdown

↓

WinPE

↓

Capture

Практична рекомендація

Перед створенням еталонного образу виконати:

Sysprep /Generalize та завершити роботу системи.

Builder Observation

Capture не виправляє помилки.

Capture чесно зберігає все, що знаходиться у системі.

У тому числі й помилки

Builder Rule

Спочатку Sysprep.

Потім Capture.

Не навпаки.

Статус

☑ Практично підтверджено

◐ Потребує додаткових експериментів із SID та розгортанням на декілька машин

Помилка №8 Apply Image на неправильний розділ

Симптом

Команда Apply Image завершується без помилок.

DISM повідомляє:

The operation completed successfully.

Однак після перезавантаження:

• Windows не запускається;

• потрібний розділ залишився порожнім;

• файли з'явилися не там, де очікувалося.

Причина

Поширене припущення:

Системний розділ завжди має літеру:

C:\

Реальність

У WinPE літери томів можуть відрізнятися від тих, що використовуються у встановленій системі.

Наприклад:

Windows

↓

C:\

──────────────────────────────────────

WinPE

↓

D:\

або

E:\

або інша літера

Неправильний підхід

Виконати:

DISM /Apply-Image

без перевірки фактичного призначення дисків.

Правильний підхід

Перед Apply Image визначити розділи.

Наприклад:

diskpart

↓

list volume

або

dir C:\

dir D:\

dir E:\

Рекомендований порядок

1. Завантажитися у WinPE.

2. Перевірити томи.

3. Визначити системний розділ.

4. Перевірити букву розділу.

5. Лише після цього виконати Apply Image.

Builder Observation 😏☕

DISM не знає, який диск ти мав на увазі.

Він чесно записує образ саме туди, куди ти вказав.

Builder Rule

Перед Apply Image перевіряй розділи.

Кожного разу.

Без винятків.

Практичний приклад

Неправильно:

Apply Image

↓

Припущення що Windows = C:\

──────────────────────────────────────

Правильно:

WinPE

↓

Перевірка томів

↓

Визначення системного розділу

↓

Apply Image

Статус

☑ Практично підтверджено

Помилка №9 Capture не того розділу

Симптом

Capture завершується успішно.

DISM повідомляє:

The operation completed successfully.

Створюється новий WIM-файл.

Однак після Apply Image виявляється, що:

• система не запускається;

• відсутні потрібні файли;

• образ містить не ту Windows;

• образ має неправильний розмір.

Причина

Під час Capture було вибрано неправильний розділ.

Поширене припущення

Windows завжди знаходиться на:

C:\

Реальність

У WinPE літери томів можуть змінюватися.

Після завантаження середовища:

Windows може опинитися на:

D:\

E:\

або іншому томі.

Неправильний підхід

DISM /Capture-Image

без попередньої перевірки розділів.

Правильний підхід

Перед Capture перевірити:

diskpart

↓

list volume

або

dir C:\

dir D:\

dir E:\

Практичний приклад

Неправильно:

Capture розділу

C:\

лише тому, що він має літеру C.

──────────────────────────────────────

Правильно:

Перевірити фактичне розташування Windows.

Лише після цього запускати Capture.

Builder Observation 😏☕

DISM не знає, який розділ ти хотів захопити.

Він захоплює саме той розділ, який ти вказав.

Навіть якщо це був неправильний розділ 😄

Builder Rule

Перед Capture перевіряй розділи.

Перед Apply перевіряй розділи.

Після перевірки ще раз перевіряй розділи.

Практичний статус

☑ Особисто перевірено автором

☑ Типова помилка Builder

☑ Повністю підтверджено практикою

Помилка №10 Виконання команд без перевірки результату

Симптом

Команда завершилася повідомленням:

The operation completed successfully.

Builder вважає, що все виконано правильно.

Однак пізніше виявляється:

• образ порожній;

• зміни не збереглися;

• Capture виконано не того розділу;

• Apply виконано не туди;

• результат відрізняється від очікуваного.

Причина

Поширене припущення:

Якщо DISM не показав помилку — усе виконано правильно.

Реальність

DISM перевіряє правильність виконання команди.

DISM не перевіряє правильність задуму Builder-а.

Приклад

Неправильно:

Capture виконано.

↓

Файл створено.

↓

Все добре.

──────────────────────────────────────

Правильно:

Capture виконано.

↓

Перевірити розмір файлу.

↓

Перевірити індекси.

↓

Перевірити Get-WimInfo.

↓

Переконатися, що образ містить потрібну Windows.

══════════════════════════════════════

Рекомендовані перевірки

Після Capture:

DISM /Get-WimInfo

──────────────────────────────────────

Після Mount:

DISM /Get-MountedWimInfo

──────────────────────────────────────

Після Commit:

DISM /Get-WimInfo

──────────────────────────────────────

Після Apply:

Перевірити структуру файлів.

Builder Observation 😏☕

"The operation completed successfully" не означає

"Builder усе зробив правильно."

Воно означає лише:

"DISM виконав те, що йому наказали."

Практичний приклад

Під час одного з експериментів Capture завершився без помилок.

Файл образу був створений.

Однак пізніше з'ясувалося, що захоплено неправильний розділ.

Результат:

Формально успішний Capture.

Фактично непридатний образ.

Статус

☑ Особисто перевірено автором

☑ Повністю підтверджено практикою