Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Системное программирование и WinAPI > Как удалить падающий при загрузке драйвер?

Автор: xvr 9.3.2017, 11:02

Господа, может кто сталкивался с такой проблемой? Разрабатывается PnP драйвер для одной железки (точнее NDIS MiniPort драйвер для специальной сетевой карты). Очевидно, что сразу он не заработает, а скорее всего уронит Windows в процессе загрузки (что и произошло) После чего Windows превращается в кирпич, и наотрез отказывается загружаться. Вопрос - как жить дальше? Были предприняты многочисленные попытки -  Загрузка драйвера не через PnP, а напрямую через SCM успехом не увенчалась - он сказал, что в гробу видал PnP драйвера, чем делали тем и грузите     Загрузка в Safe моде и удаление всего, чего только можно всеми способами, а именно:  Через pnputil -d <..>  Через devcon remove  Физическое удаление *.sys из Windows\System32\Drivers не помогло Система - Windows2008 server (серверная версия Win7) Физическое удаление платы с сетевухой помогает, но это не самый удобный способ (особенно учитывая тот факт, что система удаленная, и физический доступ к ней затруднен   )

Автор: vol4ek 9.3.2017, 11:43

загрузить последнюю удачную конфигурацию через F8 а потом удалить службу, загружающую ваш драйвер. из консоли както так Код sc delete имя имя службы посмотрите в inf

Автор: xvr 9.3.2017, 13:27

Цитата(vol4ek @  9.3.2017,  11:43 ) загрузить последнюю удачную конфигурацию через F8 Не получается. Last Known Good регистрируется раньше, чем начинается подниматься сетевой стек (а драйвер входит именно в него). Так что оно тоже падает    Из Safe Mode стартует (т.к. оно не подключает сетевые драйвера), но дальше проблемы с выкорчевыванием драйвера - уж очень Windows оказалась 'злопамятной', никак не хочет этот драйвер забывать    Цитата(vol4ek @  9.3.2017,  11:43 )  потом удалить службу, загружающую ваш драйвер. Эта служба - сетевой стек Windows, ее удалять черевато (да и не дадут)    Можно удалить PnP узел (через devcon и/или pnputil), но Windows при следующем старте счастливо находит 'новое оборудование' и немедленно возвращает драйвер обратно (из DriverStore) И что самое интересное - эта ситуация должна возникать практически при любой разработке любого NDIS драйвера, ниужели никто до сих пор с таким не сталкивался? MSDN хранит гордое молчание, Google наоборот многословно рассказывает, как вылечить падения при загрузке Windows, при этом все советы сводятся либо к 'переустановите или восстановите' Windows, либо снесите последнее установленное оборудование и обратитесь к разработчику. И что мне делать, если я и есть этот самый 'разработчик' ?

Автор: vol4ek 9.3.2017, 15:09

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

Автор: vol4ek 9.3.2017, 15:59

если конечно падает не в DriverEntry или каком-нибудь AddDevice Добавлено через 3 минуты и 31 секунду хотя там же pnp...  xvr,  сочувствую.

Автор: xvr 9.3.2017, 17:27

Цитата(vol4ek @  9.3.2017,  15:09 ) а в каком месте падает драйвер знаете? Если бы знал, вопросов бы не было

Автор: vol4ek 9.3.2017, 19:06

выложите код если небольшой подуплиться в него

Автор: xvr 10.3.2017, 13:07

Код как раз большой. Это переделанный пример NDIS Virtual Miniport. Вопрос не в том, как искать ошибки - это и так понятно, а в том, как сделать так, что бы один цикл разработки: запустил-упало-нашел_ошибку-исправил-запустил занимал не часы, а минуты (и не включал в себя физическую разборку компьютера на составляющие)

Автор: rudolfninja 10.3.2017, 13:22

Ответ покажется очень банальным, но вроде тут его не предлагали: Почему бы не подключить удаленно дебагер (желательно с исходниками и символами драйвера) к проблемной машине и не словить проблему? Я драйвера дебажил только через виртуалку (т.е. проверял драйвер на виртуалке), но знаю, что и к физической машине его можно подключить.

Автор: vol4ek 10.3.2017, 14:58

удаленной отладкой не занимался, но видел много тем с траблами по этому поводу

Автор: rudolfninja 10.3.2017, 17:40

Я занимался. Когда тестируемая ОС на виртуалке и со своей ОС (которая выступает как хост для тестируемой) никаких проблем не возникало. Дебагер сам подключается как только ОС начинает загружать драйвер и остновится когда драйвер свалиться. При этом в дабагере есть полный стек вызовов и состояние памяти на момент креша. Мне помогало. Проблема только в том, что все это удовольствие потребляет немало ОЗУ.

Автор: tzirechnoy 10.3.2017, 18:07

Загрузить что-нибудь ещё, открыть файл реестра (они штатно открываются виндовым regedit, и есть какой-то редактор под unix-like для жэлающих) и удалить из него службу этого драйвера.

Автор: xvr 10.3.2017, 18:20

Цитата(rudolfninja @  10.3.2017,  13:22 ) Почему бы не подключить удаленно дебагер (желательно с исходниками и символами драйвера) к проблемной машине и не словить проблему? Без проблем, но как потом этот драйвер удалить, или заапдейтить? Машина то не грузится, даже с дебагером :( Цитата(rudolfninja @  10.3.2017,  13:22 ) Я драйвера дебажил только через виртуалку С виртуалкой тоже проблем нет, но есть проблемы с самим драйвером - он хочет общаться с физической железкой, которой в виртуалке нет    Цитата(tzirechnoy @  10.3.2017,  18:07 ) удалить из него службу этого драйвера Служба 'этого драйвера' -это NDIS подсистема. Если ее удалить, то у Windows отвалится весь сетевой стек (причем навсегда)    ЗЫ. Через devcon оно удаляется - я его победил. Но все равно, с таким циклом отладки и на удаленной машине - это не жизнь

Автор: xvr 13.3.2017, 13:57

Разобрался как удалить драйвер:  devcon remove <hw driver ID>  devcon dp_enum  devcon dp_remove oem???.inf Последний пункт повторить для всех oem*.inf, которые соотвествуют драйверу (их брать из п2) Всю эту последовательность можно закатать в батник К сожалению это не решает проблемы удаленной отладки - требуется ручная перезагрузка в safe mode Это тоже решается (костыль конечно, но работает). Делается user mode утилита, которая создает event (именованный в Global\ наймспейсе) В драйвере (в DriverEntry) делается попытка открыть это событие (через ZwOpenEvent) - если такового нет, драйвер немедленно терминируется с ошибкой. Таким образом после слома можно перезагрузиться, в процессе boot'а драйвер откажется грузиться, но система взлетит. Затем запускается user mode утилита, а драйверу делают disable/enable и он взлетает (желательно с прикрепленным кернел дебагером, иначе смысла в взлете и последующем крахе будет немного   ) Более безболезненого метода пока не нашел

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)