Ведь есть готовые универсальные драйверы libusb-win32 или WinUSB. Зачем мучить себя написанием собственного драйвера?

Даже не знаю, что и ответить... Ну, чтоб уметь, наверное! А если мне не универсальный нужен?

В таком случае, извините за

Если кому интересно, то причина моей проблемы крылась в настройках компиляции ддкшного драйвера. Синий экран подсказал)

Интересно. Поделитесь. Что стандартных установок для компиляции драйвера недостаточно?

Компиляция под дебаг (chk) при возникновении assertов требовала дебаггера, о чем говорил номер ошибки в синем экране. В free версии все работает, хотя не плохо было бы узнать, что за assert (или breakpoint) срабатовал и требовал отладчика для продолжения работы. Буду продолжать эксперименты)

А что, DbgView молчит? Уж он то assert диагностику должен показать. Что-то странноватое у вас происходит. Может компилируете не в том DDK/WDK или не под вашу версию Windows?

А я на локальной машине DbgView использовал, он то может что-то и показывал, только я этого не видел. Для меня вывод один: kerel-mode отладку надо вести на сторонней машине.

С версиями DDK и Wndows я разобрался

Сообщение отредактировал Тёмыч - May 22 2011, 20:05

Может я старый стал, но никак не пойму стиля обсуждения топика. Chk версия вываливается в синий экран, а free - нет? Assert что-то показывает в DbgView, или сразу все накрывается? Странно все это (если это так). Обычно проблемы при переходе от chk --> free. Невнятно как то все это излагается, я до конца в проблематику не въезжаю.

Все накрывалось сразу и ни в каком дебагвью не успеешь посмотреть (так как он на той же машине был запущен). Включил отображение синего экрана. Выяснилось. что ошибка 0x7E -> 0x80000003: STATUS_BREAKPOINT indicates a breakpoint or ASSERT was encountered when no kernel debugger was attached to the system. Вывод: надо подключать внешний отладчик, либо компилить без ассертов этот драйвер. Что ж я тут не правильно излагаю?

Я не говорил ни слова про "неправильно", а говорил "про непонятно". ASSERT - чистая диагностика. Как правило, вылавливание неинициализированных переменных, выход за границы массивов, попытки чтения/записи по NULL указателю. Вариантов, на мой взгляд, два:
1. Неудачно реализован сан assert.
2. На самом деле ошибка, которую вылавливал assert, как была, так и осталась, только пока это не приводит к экрану смерти. Хотя и странно это.

Верно, я понимаю, что вызов ассерта не есть хорошо. Поэтому буду экспериментировать с отладчиком. Хотя возможно это был чисто отладочный (тестовый) брейкпоинт от Майкрософт.

Большие сомнения про breakpoint. Откуда он может взяться? Его именнo в отладчике только и можно установить. Как понимаю, нет отладчика, нет и breakpoint'a.

Припоминая давние времена, usbbulk валился у меня, при некоректно описанных дескрипторах в usb device или перепутанных (ввод/вывод) endpoint'aх. Надо все это внимательно перепроверить.

Ну почему же? Можно из драйвера передать управление отладчику, как раз такая штука в этом драйвере (bulkusb) и стоит. И стоит она как раз в месте эвента по отсоединению устройства.

DbgBreakPoint называется, кажется.

Осталось выяснить, кто DbgBreakPoint там поставил и зачем? В WDK в драйвере bulkusb ничего такого не используется.