Господа, может кто сталкивался с такой проблемой?

Разрабатывается PnP драйвер для одной железки (точнее NDIS MiniPort драйвер для специальной сетевой карты). Очевидно, что сразу он не заработает, а скорее всего уронит Windows в процессе загрузки (что и произошло)
После чего Windows превращается в кирпич, и наотрез отказывается загружаться. Вопрос - как жить дальше?

Были предприняты многочисленные попытки -

•  Загрузка драйвера не через PnP, а напрямую через SCM успехом не увенчалась - он сказал, что в гробу видал PnP драйвера, чем делали тем и грузите   
•  Загрузка в Safe моде и удаление всего, чего только можно всеми способами, а именно:
  •  Через pnputil -d <..>
  •  Через devcon remove
  •  Физическое удаление *.sys из Windows\System32\Drivers
  не помогло

Система - Windows2008 server (серверная версия Win7)

Физическое удаление платы с сетевухой помогает, но это не самый удобный способ (особенно учитывая тот факт, что система удаленная, и физический доступ к ней затруднен   )

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

имя службы посмотрите в inf

Не получается. Last Known Good регистрируется раньше, чем начинается подниматься сетевой стек (а драйвер входит именно в него). Так что оно тоже падает   
Из Safe Mode стартует (т.к. оно не подключает сетевые драйвера), но дальше проблемы с выкорчевыванием драйвера - уж очень Windows оказалась 'злопамятной', никак не хочет этот драйвер забывать   


Эта служба - сетевой стек Windows, ее удалять черевато (да и не дадут)   

Можно удалить PnP узел (через devcon и/или pnputil), но Windows при следующем старте счастливо находит 'новое оборудование' и немедленно возвращает драйвер обратно (из DriverStore)

И что самое интересное - эта ситуация должна возникать практически при любой разработке любого NDIS драйвера, ниужели никто до сих пор с таким не сталкивался? MSDN хранит гордое молчание, Google наоборот многословно рассказывает, как вылечить падения при загрузке Windows, при этом все советы сводятся либо к 'переустановите или восстановите' Windows, либо снесите последнее установленное оборудование и обратитесь к разработчику. И что мне делать, если я и есть этот самый 'разработчик' ?   

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

если конечно падает не в DriverEntry или каком-нибудь AddDevice

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

Если бы знал, вопросов бы не было   

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

Код как раз большой. Это переделанный пример NDIS Virtual Miniport.

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

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

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

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

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

Без проблем, но как потом этот драйвер удалить, или заапдейтить? Машина то не грузится, даже с дебагером :(


С виртуалкой тоже проблем нет, но есть проблемы с самим драйвером - он хочет общаться с физической железкой, которой в виртуалке нет   


Служба 'этого драйвера' -это NDIS подсистема. Если ее удалить, то у Windows отвалится весь сетевой стек (причем навсегда)   

ЗЫ. Через devcon оно удаляется - я его победил. Но все равно, с таким циклом отладки и на удаленной машине - это не жизнь   

Разобрался как удалить драйвер:

•  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 и он взлетает (желательно с прикрепленным кернел дебагером, иначе смысла в взлете и последующем крахе будет немного   )

Более безболезненого метода пока не нашел