VisualDDK - отлаживаем драйвера напрямую из Visual Studio

dag
и как мне физ.лицу купить иду?

 

Если в России то http://www.idapro.ru/buy/

 

http://www.idapro.ru/forum/viewtopic.php?t=527
Еще лучше http://www.idapro.ru/forum/viewtopic.php?t=458

 

И чем IDA лучше отладчика, встроенного в VisualStudio, когда речь идет о разработке и отладке своих драйверов? ИМХО, разные сферы применения у проектов.
Да, а, кстати, генерация пары ASM/PDB (C/PDB для HexRays) в IDA не планируется? Было бы, ИМХО, куда полезнее написания с нуля альтернативы достаточно удачному GUI студийного отладчика.

 

Сайт на английском, это одно, но вот в форум запостить кирилицей тоже не получилось (пишет не в тему "Your message contains too few characters" и не смотря на их количество не пускает кирилицу вообще).

Вобщем, всё сделал четко следуя описанию.
Практически всё для чистоты эксперимента повторил точно.
В результате, после нажтия кнопки "launch" (пункт 14) получаю "Attaching the DDK debugger to process '[0] System' on machine 'VIK' failed" (VIK - имя host машины).

host: WinXPSP3, MSVS Team System 2008, wdk7000 (хотел попробовать с ddk2600, но не нашёл в нём Debugging Tools for Windows), vmware workstation 6.5.2

guest: WinXPSP3

С разработкой драйверов не знаком вообще, увидел на васме анонс VisualDDK, решил попробовать начать знакомиться с него, в связи с чем прошу ногами не бить, а попытаться помочь разобраться.

 

Всё получилось после выполнения пункта Installation(Static patching) из этого мануала.
Хотя здесь об этом ни слова.

 

Получиться то получилось, да не совсем.
После многочисленных плясок с бубном понял, что получается только в том случае, если:
1. В папке %SystemRoot%\System32 лежит kdvm.dll из virtualkd
2. В boot.ini дописано /DEBUG /DEBUGPORT=VM
3. В момент выбора ОС запущен vmmon.exe (virtualkd)
4. Грузим ядро при помощи WinDBG (vmmon.exe сам запустит)
5. После загрузки, запускаем DDKLaunchMonitor, отключаем WinDBG, запускаем отладку.

До следующей перезагрузки можно просто запускать и останавливать отладку.

Любые другие пляски с бубном не привели ни к чему хорошему.

 

Вобщем 4 дня борьбы с VisualDDK ни к чему хорошему не привели кроме как к осваиванию WinDDK.
Автор не отвечает ни на письма, ни в созданом им же топике. Его сайт и форум не предназначен для общения на русском языке.
Из проблем, которые полностью перечёркивают все прелести VisualDDK хочу отметить отсутсвие визуализаторов для WinDDK типов. К примеру, с чем сразу столкнулся, это тип UNICODE_STRING. При помощи штатных методов студии (autoexp.dat, watch) мне не удалось визуализировать этот тип, а без него отладка оказалась невозможной.

 

Автор был временно вне зоны доступа.
Что касается UNICODE_STRING, проблема есть при сброке .c файлов, где wchar_t не является встроенным типом. В следующей версии будет workaround. autoexp.dat работать не будет, так как VisualDDK использует свою систему визуализаторов. Если скомпилировать файлы как .CPP, строки будут нормально отображаться.
Любые другие пляски с бубном не привели ни к чему хорошему.
Что происходило при попытке сначала начать сессию в VisualStudio, а потом, пока отображается диалог "connecting", запустить ОС?

 

Сессия начнётся только если VM уже включена, т.е. до загрузки ядра надо начать сессию, и если выполнены пункты 1 и 2 (см выше).
В таком случае в момент загрузки VM, devenv будет жрать кучу ресурсов процессора и отображать окошко, в ктором что то насчёт таймаута (к сожалению скопировать не удаётся из за загрузки процессора).
Если следовать моей последовательности, что я описал выше, тоже присутствуют неприятные глюки.
Выглядит это примерна так... если в момент запуска или остановки(при помощи net или fltmc) отладочной сессии, процесс отладки приостановлен (breakpoint), или в процедурах загрузки\выгрузки драйвера есть точки останова, то vsddk не может связаться с виртуальной машиной(тоже вроде что то насчёт таймаута пишет). Приходится нажимать cancel. После чего при следующем запуске сессии, она попадает как раз на эту точку остановки.
Ещё не убираются точки останова во время отладки. т.е., когда стоишь на точке, убираешь её в интерфейсе студии, жмёшь f5, и опять останавливаешься на том же месту, хотя точки в интерфейсе уже нет. После остановки отладки, точка оказывается на том же месте, как буд то её никто не удалял.
Ещё, если отладка заканчивается некорректно (нажал cancel или что то ещё случилось), то в большинстве случаев если не перезапустить студию, то при следующем сеансе отладки она или зависнет наглухо, или выкинет ещё какой нибудь сюрприз.
Так же, в этом случае отладка в большинстве случаев не начнётся без перезапуска VM (revert to snapshot) - vmxpatch не помогает.

Если у автора есть желание, то я готов всё же поучавствовать в тестировании при условии связи в реальном времени(icq, email), поскольку тестирование без связи с разработчиком съедает слишком много реального времени, и судя по моему опыту не приносит никакой пользы, по крайней мере пока. К тому же не думаю что этот форум предназначен для подобного общения.

 

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

 

tylerdurden
Это твое личное мнение. Я бы не стал на твоем месте им расбрасываться. Уверен, что многие здесь с тобой не согласятся. Я и обычные проги, а не только дрова, частенько собираю с консоли с помощью WDK.

 

Forever
ты наверно никогда по-другому их не собирал. попробуй в консоле уже не будешь

 

Не всегда.
Если проект состоит из нескольких драйверов / программ мне гораздо проще в тотале поставить курсор на батник и компилить один нужный драйвер комбинацией alt+tab, Enter чем елозить крысой по всей студии, т.к. желание перекомпилить все каждый раз отсутствует.
Все зависит от задачи / личных предпочтений / глубокой ненависти к манипулятору типа "крыса"

 

Wizard109

rebuild solution чем кнопка не устраивает? и крысой водить не надо, там есть хоткеи

 

Просто уже издревле к консоли привык.
+радует тот факт что могу извратиться как хочешь(типа компилить избранные проекты с разными настройками, одновременно копировать в папку System32/Drivers... и.т.д.).

А вообще это Холивар: command line VS gui.
Каждому - свое.

 

а это можно сделать через pre/post build events

 

Перечитал уже несколько раз QuickStart, и вообще все что смог найти по этой теме, сам драйвера никогда не писал, в этом направление полный чайник.
Создал проект, но никак не получается его запустить на отладку. Вроде как все поставилось, тестовая винда грузится, WinDbg запускается, DDKLaunchMonitor показывает что что-то идет, но при попыке запука отладки я получаю: "Attaching the DDK debugger to process '[0] System' on machine 'Имя моей машины' failed."

Обязательно ставить DDK и WDK? У меня сейчас есть только WDK который шел с msdn подпиской?
установка прошла успешно без указания пути к DDK.

Моя машина: Windows XP x64 Sp2, тестовая система на VirtualBox Windows XP Sp3

Как устанавливал: поставил WinDbg, поставил VirtualBox, поставил туда WinXP, заменил в VirtualBox VBoxDD.dll, скопировал на тестовую систему в system32\drivers kdvm.dll и kdpatch.sys, в boot.ini добавил /debug /debugport=VM.

Как запускаю: Запускаю VirtualBox, запускаю из него систему, дальше она ожидает пока я не запущу vmmon64, запускаю vmmon64 выбираю в списке свою систему, жму Run Debugger, запускается WinDbg, и тестовая система продолжает загрузку. Запускаю VisualStudio создаю проект VisualDDK, Дальше открываю Driver Launch Settings, выбираю:
VMWare Virtual Machine — WinXP
Target machine hostname or IP — 192.168.56.101(Ip адрес сетевой карты в тестовой системе)
Driver file path on the target machine: %SystemRoot%\System32\Drivers\test.sys
Enable a PnP device with Hardware ID — \root\mydriver
Disable a PnP device with hardware ID — \root\mydriver

Далее жму Launch, и вылетает ошибка: Attaching the DDK debugger to process '[0] System' on machine 'Имя моей машины' failed.

Подскажите, что я не правильно делаю?

 

Такой вариант впринципе тоже вроде прокатывал у меня, но по задумке, на сколько я понял, virtualkd здесь не должен использоваться вообще, точнее ты должен скопировать из него kdclient64.dll в папку visualddk, после чего у тебя станет возможным выбор VMWare Virtual Machine в driver launch settings.
Судя по всему ты это уже сделал.
Соответсвенно после того, как "запускаю из него систему, дальше она ожидает пока я не запущу vmmon64" ты должен запустить отладку в студии и ждать пока система загрузится.
т.е. студия будет выполнять роль обёртки для windbg

 

Я скопировал в папку visualddk и kdclient64.dll и kdclient.dll, сейчас стал пробовать, и заметил что если удалить kdclient.dll и оставить только kdclient64.dll то visualddk его не трогает, она у меня получается всегда пользуется только kdclient.dll а не kdclient64.dll.
Думаю что может быть в этом проблема?
Windows XP x64 и VisualStudio тоже при установке говорила что устанавливает все x64.