0 / 0 / 0
Регистрация: 22.12.2015
Сообщений: 11
|
|
1 | |
Дебаг драйвера в WinDBG12.10.2016, 01:34. Показов 3530. Ответов 3
Метки нет (Все метки)
Здравствуйте все! Многократно извиняюсь, если подобная тема уже была на форуме - я ее не нашел.
Проблема заключается в следующем: есть написанный драйвер(.sys, .inf, .pdb). WinDBG подключен к виртуалке через VirtualKD и работает в режиме отладки системы. Как загрузить/установить драйвера на виртуалку и надо ли это, или можно загрузить его просто через windbg. Я делал так: 0.Ставлю точку остановы(kd>bp KMDF_Hello_World!DriverEntry) 1.В Symbol File Path... указывал путь к .pdb файлу(D:\VS2015\Projects\KMDF_Hello_world\Debug), 2.В Source File Path... - путь в дирректорию с проектом(D:\VS2015\Projects\KMDF_Hello_world) 3.Вожу kd>.reload KMDF_Hello_world.pdb, но выдает ошибку: "KMDF_Hello_world.pdb" was not found in the image list. Debugger will attempt to load "KMDF_Hello_world.pdb" at given base 00000000. Please provide the full image name, including the extension (i.e. kernel32.dll) for more reliable results.Base address and size overrides can be given as .reload <image.ext>=<base>,<size>. Unable to add module at 00000000 Перепробовал все возможные комбинации на пути к файлам, все возможные .reload (с адрессами к .sys и не только), добавил в Image File Path... путь к директории с проектом(D:\VS2015\Projects\KMDF_Hello_world), ничего не помогло. Благодарю за внимание Добавлено через 36 минут Уточню, так как криво сформулировал: меня не интересует установка драйвера как таковая, мне важно продебажить драйвер, и если можно, пошагово описать, чт оя должен сделать в WinDBG и с файлами драйвера, чтобы начать его отладку. Добавлено через 1 час 5 минут Нашел, как установить драйвер на виртуалку: sc create KMDF_Hello_world type= kernel start= demand error= normal binPath= C:\KMDF_Hello_world\KMDF_Hello_world.sys net start drivername Теперь постоянно winDBG выдает такое: *** Fatal System Error: 0x0000007f (0x0000000D,0x00000000,0x00000000,0x00000000) Break instruction exception - code 80000003 (first chance) A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. Connected to Windows 7 7601 x86 compatible target at (Wed Oct 12 01:30:07.545 2016 (UTC + 3:00)), ptr64 FALSE Loading Kernel Symbols ............................................................... ................................................................ ........... Loading User Symbols Loading unloaded module list ......... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7F, {d, 0, 0, 0} Probably caused by : memory_corruption Followup: memory_corruption --------- Почему?
0
|
12.10.2016, 01:34 | |
Ответы с готовыми решениями:
3
Отладчик WinDBG Изучение отладчика WinDbg 86/64 WinDBG - отладчик ядерного уровня Break по условию стека (Windbg) |
Ушел с форума
|
|
12.10.2016, 17:20 | 2 |
Сообщение было отмечено arch3r как решение
Решение
Есть три варианта:
1. Копируем драйвер ручками через сетевую папку / Shared Folder или что-то еще. 2. Используем директиву .kdfiles отладчика WinDBG. То есть, задается соответствие между драйвером в виртуалке и .sys-файлом на хостовом компьютере. Каждый раз, когда в виртуалке будет запускаться драйвер, его образ будет подтягиваться из указанного файла. 3. Использование provisioning driver package (только в последних версиях Visual Studio). Эффектно. Но сложно, глючно и иногда непереносимо. Я делаю так: закидываю драйвер на виртуальную машину. В отладчике уже прописаны пути к отладочным символам сервера Microsoft. Все, больше ничего делать не нужно. Как только срабатывает точка останова, ассерт или выбрасывается bugcheck, отладчик останавливается, сам подтягивает нужные символы (а путь к ним он берет из исполняемого файла - .sys) и показывает в своем окно точное место, где произошла остановка. Ошибка в драйвере, очевидно же. Только не видя кода, невозможно сказать где именно.
1
|
0 / 0 / 0
Регистрация: 22.12.2015
Сообщений: 11
|
|
14.10.2016, 01:03 [ТС] | 3 |
Спасибо огромное!
А как запускать в виртуалке драйвер? Если запускать драйвер так:
sc create driver1 type= kernel start= demand error= normal binPath= C:\driver1.sys net start driver1 ,то перезапустить его(если я скажем, когда дебажил, дошел до последней строчки и вышел из нее) можно только через перезапуск виртуалки, а это долго. Еще вопрос возник(правда по смежной теме), относительно дебага через студию(все настройки выполнены в соответствии с советами статей msdn(https://msdn.microsoft.com/en-... s.85).aspx)). Если через студию подключаться(Atach to the process) к виртулке и нажать Break, то система на виртуалке останавливается(дебагер подключен), но если попробовать прямо из проекта драйвера(настроив его предварительно, всё как советует msdn) закомпилить его(Debugging Tools for Windows - Kernel Debugger), т.е. продебажить драйвер на виртуалке то выдает такое: Deploying driver files for project "D:\VS2015\Projects\driver2\driver2\driver2.vcxproj". Deployment may take a few minutes... Could not connect to the remote computer for deployment. Проверял во вкладке Driver>Test>Configure Devices(в студии).Если перенастроить мой "виртуальный девайс" (выбрав Provision Device and choose Debugger Settings), то выдает такое(пробовал подключаться и через COM порт и через TCP, т.е. Network) - 1ая картинка под текстом. Вот еще странность: на 2ой картинке пишет Driver Test Configuration: Unavailable. Причем, если выключить виртуалку и попробовать задебажить снова, то при деплойменте будет тот же сбой(Could not connect to the remote computer for deployment.) Очень странно, что я могу приатачится к виртуалке, но при деплойменте драйвера студия не может уже подключиться к этой же виртуалке. Вы поймите, я не ленивый) И много искал, особенно на англоязычных форумах информации, прочитал кучу статей на мсдн, но нет никакой точной информации, как пофиксить такую проблему. Для меня важен абсолютно любой намек на решение подобной проблемы. Огромное спасибо еще раз за внимание и за помощь!
0
|
Ушел с форума
|
|
14.10.2016, 11:00 | 4 |
Я обычно стараюсь в драйверах поддерживать DriverUnload, тогда дело
движется немного быстрее. Хотя не для всех драйверов можно сделать выгрузку. Еще советую, если финансы позволяют, обзавестись SSD и в качестве виртуалки использовать VMware с Win8 или выше, тогда перезагрузка будет занимать считанные секунды. Мне кажется, пользоваться всеми этими 'auto-deploy driver to virtual machine' и т.п., которые появились в последних "Студиях", пока не стоит. Эти вещи еще очень сырые и недоработанные, иногда вылезают какие-то ошибки, которые очень трудно пофиксить. Я как-то пытался, особых успехов не добился и работало это строго под Hyper-V. Еще нужна сетевая карта специальная. Еще виртуалка должна быть специальным образом подготовлена. И т.д. Слишком много "но" и "если". Старый дедовский способ, т.е. WinDBG + com/pipe + .kdfiles - это то, что нужно, каждый такой инструмент прост, как пробка, там просто нечему глючить и конфликтовать. Подготовка одной виртуальной машины для отладки и авто-деплоя через .kdfiles занимает от силы пару минут.
1
|
14.10.2016, 11:00 | |
14.10.2016, 11:00 | |
Помогаю со студенческими работами здесь
4
Точка останова (бряк) в WinDbg WinDbg Не хочет показывать ассемблерный код Система краш-дампов, WinDbg и XE2 C++ Builder WinDbg: почему dt показывает экспортируемое не у всех модулей? Расшифровка мини-дампа, после программы WinDbg WinDbg: не срабатывает бряк на точке входа в х64 системе Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |