Тонкости BSOD 7B при переносе на другую материнскую плату.

Предупреждение первое: случай редкий, ранее в моей практике подобных заскоков при переносе не наблюдалось.
Предуперждение второе: много букв и крайне полезно наличие знаний о порядке загрузки Windows, иначе будет довольно сложно.

Сначала немного теории.

Речь пойдет о старой доброй Windows XP, эта ось крайне неохотно покидает офисное железо. А железо стареет. А два переезда равны одному пожару.
Как известно, BSOD 7B при переезде возникает, так как на определённом этапе загрузки система перестаёт взаимодействовать с контроллерами хардов через BIOS-овский INT 19h, и пытается  “начать жить своим умом”. То есть выясняет в реестре, какой драйвер отвечает за HDD контроллеры и начинает того дёргать.  Так как на новом железе контроллер иногда случается от другого вендора, а гадалки у XP не водится, система принимается паниковать.

В большинстве случаев помогает маленький сборничек mergeide. В его состав входят несколько штатных драйверов для HDD контроллеров и reg-файл, содержащий PnP-ID наиболее популярных контроллеров и привязку их к тем штатным драйверам.

В качестве примера: кусок реестра с привязкой VIA HDD контроллера к родным VIA-драйверам:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_1106&dev_0571]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”videX32”

Тот же кусок, но после импорта reg-файла от mergeide выглядит чуть по-другому
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_1106&dev_0571]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=“pciide”

К сервису pciide привязан штатный, базовый драйвер pciide.sys, через его посредство система умеет работать с любым (по идее) IDE-контроллером, что, собственно, и требовалось.

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

Получается ситуация, отдалённо напоминающая замену видеокарты – для новой ещё не установлены родные драйвера, а на базовых хоть что-то, БОЛЬШИМИ БУКВАМИ, но видно.

Почему это может не сработать? При учёте радиуса кривизны Ваших рук, коллега, близком к нулю?
Первое: в reg-файле от mergeide нет PnP-ID нужного контроллера. Лечится опять же через ERD запуском утилитки siw (или аналога), нахождением нужного PnP-ID. После чего по образу и подобию создаётся правильный ключик, и вносится в реестр. Процедура легко гуглится.
Второе: имеются хвосты драйверов старого контроллера в дальних уголках реестра.

Переходим к практике.

На руках имеются: пациент – комп на базе материнки с чипсетом SiS, донор (можно сказать, пересаживаемый огран) – более шустрая материнка на базе чипсета Intel и сосед – ещё один комп на базе материнки с чипсетом SiS, такой же, как и у пациента. Задача вроде проста – пересадить донора пациенту и оживить систему.

Открутили-вынули-вставили-закрутили-подцепили_провода. Загрузка, ожидаемый BSOD 7B (так, для себя, чисто поржать), ERD, mergeide… И снова BSOD 7B, только чуть позже, чем обычно, секунд на 10-15.

Ржать расхотелось. Ситуация нерасчётная. И вот тут я делаю не вполне логичный шаг. Но именно он помог мне в последствии приблизиться к разгадке. А именно: нахожу в C:\windows\system32\drivers все драйвера с начальными буквами sis (siside.sys, sisagp.sys и ещё штуки три или четыре), и сношу их в другую папку, с мыслью – зачем чипсету Intel дрова от SiS, вдруг мешают?
(Правильнее было бы: не переносить файлы драйверов, а запретить через реестр загрузку их сервисов, заменив параметр “Start” c 0 {запуск в процессе загрузки} на 4 {отключен}. Хотя, скорее всего, итог был бы тем же)

Результат отрицательный – система не грузится. Дальше были два часа размышления, гугления, тюнинга реестра, перепроверок всего & вся, неизменного BSOD 7B и выкипания мозга. Где-то в реестре живут старые хвосты, которые mergeide не поборол – не научен.

Сотрудник без компа сидит, работа без сотрудника стоит, идей нет. Признаю поражение, запихиваю в пациента его родную SiS-ку. И… правильно, коллега, получаю BSOD 7B. Как так? Родной хард, родная мать, да ещё отсылка к родным драйверам заменена на отсылку к штатным, а штатные на месте, туеву хучу раз перепроверено… Значит, мысль о хвостах подтверждается. Вспоминаю, что я делал самовольно, за пределами методики, и возвращаю на прежнее место пачку sis*.sys. Система бодро и безошибочно грузится.

Чисто из любопытства ищу хвост.
И тот, похоже,  находится:
ide1

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\IDE\Disk{HDD-Name}\{набор_циферок_типа_этого}5&1a760bd3&0&0.0.0\Control]
“ActiveService”=“Disk”

Только вместо “Disk” стояло имя сервиса от SiS, с которым был связан один из перемещённых мною sis*.sys драйверов. Похоже, коллизия с этоим драйвером и кидала систему в BSOD 7B. На доноре сначала из за конфликта с железом – SiS-овский драйвер не дружил с Intel-овским контроллером; а после перемещения sis*.sys в другую папку и вовсе из за ступора – запись в реестре есть, а драйвера нет, как страшно жить. А на пациенте ступор продолжился, пока я не вернул драйвера на прежнее место.

Вы спросите – “А причём тут тогда сосед?” Напомню, его материнка такая же, как у пациента. И когда пациент впал в ступор, я полез в реестр к соседу. Обнаружилось всякое отсутствие следов IDE драйверов от SiS  (вероятно, систему ставил другой человек и на это драйвер просто не стал заморачиваться, и так работает). И, как следствие, отсутствие подраздела “Control” в уже знакомой ветке:
ide2

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\IDE\Disk{HDD-Name}\{набор_циферок_типа_этого}5&1a760bd3&0&0.0.0\Control] – отсутствует

 Вывод: если после штатной процедуры переноса (mergeide), пациент продолжает падать в BSOD 7B, можно попытаться либо подставить в ключ “ActiveService” подраздела “Control”  значение “Disk”, либо экспортировать весь раздел “Control” в надёжное место, а затем удалить и повторить попытку загрузки.
Жаль, но проверить этот вывод у меня не получилось, поджало время.