Сижу я сегодня на работе, никого не трогаю, отладчиком отладчик отлаживаю. А что, отладчик – тоже человек программа. Тем более что немногим ранее я его немножко совсем поломал, пытаясь добавить поддержку некоей конфигурации, которая текущей реинкарнацией отладчика не поддерживается. Ну вот, запускаю я его примерно вот таким образом:
windbg.exe kd.exe -k com:port=com1,baud=115200
…и замечаю, что что-то не так. А именно – опять сломался наш корпоративный прокси. А я как раз хотел посмотреть в… ну скажем MSDN. Попробовал и так и сяк. Не работает, вылетает по таймауту. Ну хорошо, но тут начитают происходить еще более мистические вещи. Outlook вдруг перестает реагировать мышь и клавиатуру; IE вообще не запускается – процесс стартует, но окно не показывается. Несколько подозрительно для проблем с прокси.
Read more…
На работе понадобилось написать драйвер для сетевой карты. Я этого раньше никогда не делал и вообще с NDIS дела не имел. А тут такая возможность! Делюсь впечатлениями.
В общем и целом NDIS мне понравился. Интерфейсы довольно логичны, хотя и многочисленны. Взаимосвязь между разными компонентами в большинстве случаев после недолгой медитации становится довольно очевидной. Все структуры снабжены заголовком с сигнатурой, версией и размером, что, помимо заботы об обратной совместимости, означает меньше проблем с отладкой. При необходимости нужную структуру можно просто найти в памяти.
Read more…
Раз уж я заговорил про BUILD и NMAKE, то вот несколько простых (и, в общем-то, очевидных) способов отладки NMAKE скриптов.
- Директива препроцессора !ERROR очень полезна, когда нужно выяснить доходит ли управление до интересующей нас линии скрипта. Директива выводит указанный текст в сообщении об ошибке (U1050) и останавливает NMAKE.
- !MESSAGE пригодится для дампа макросов в лог. Например:
!MESSAGE BUILD_PASS = $(BUILD_PASS)
Выведет в лог номер прохода (PASS0, PASS1 или PASS2), в случае, если NMAKE, был запущен через BUILD в билд-окружении WDK.
- NMAKE умеет вызывать внешние команды на этапе препроцессора. Этим можно воспользоваться, чтобы, например, посмотреть параметры командной строки, которые BUILD передает в NMAKE (и массу других вещей, само собой). Достаточно добавить в SOURCES:
!if [cmd /c pause]
!endif
Дойдя до той строки, NMAKE будет ждать ввода пользователя, позволяя тем самым внимательно посмотреть на то, что происходит в данный момент:
NMAKE остановлен в момент разбора SOURCES.
Visual Studio предлагает два основных отладочных сценария:
- Собрать проект и запустить результат под отладчиком.
- Присоединиться к уже запущеному процессу.
Третьей опции, – запустить произвольный бинарник под отладчиком, явно не предлагается, что вызывает смятение и смуту в рядах программистов, не нюхавших WinDbg. Вот один из способов как этого можно добиться.
- Создаем новый проект. Тип проекта выбираем “Makefile project”.
- В качестве команды сборки, очистки и пересборки проекта указываем “echo.”. Можно с точкой; можно вывести какой-нибудь текст.
- В качестве результата сборки указываем интересующий нас бинарник.
- Жмем на Finish.
Теперь можно смело жать F5. Visual Studio «соберет» проект и запустит нужный бинарник под отладчиком.
Тут интересная дискуссия про “неработающую” OutputDebugString завязялась в комментариях, если кто пропустил. Читать вот примерно отсюда: http://blog.not-a-kernel-guy.com/2010/07/11/854#comment-15681.
Давно я про отладку не писал. Так вот пошли мы как-то с коллегой на Багов охотится. Вышли мы на двух таких матерых, опытных Багов. Их и помотали они нас…
Read more…
В очередной раз столкнулся с мифом, что, мол, release сборку невозможно отлаживать, так как символов нет. Значит так! Американцы на Луне были! Тьфу ты. В смысле, символы в release сборке включать: а) можно, б) нужно и в) полезно. Генерация отладочной информации не влияет на оптимизацию кода. Хотите, проверьте сами – сравните ассемблерные листинги с генерацией символов и без. Более того, случаи, когда это не так, однозначно трактуются как ошибки, которые можно смело отправлять в Microsoft. Мне, кстати, и самому было бы интересно посмотреть на тест-кейс воспроизводящий подобную ошибку.
Recent Comments