Pull to refresh

Как отлаживают графику Windows в Microsoft

Development for Windows
Я в MS уже больше двух лет, и все равно в отладчике провожу большую часть полезного времени (больше только в Outlook).
Раньше я делал Windows Imaging Component, новую библиотеку для работы с изображениями, а теперь DXGI — инфраструктуру hardware acceleration. Первое целиком в user mode, второе и в kernel, и в user, но общий экспириенс дебага в общем-то тот же.


Кто бы не нашел баг и где бы не свалилось — всегда пришлют remote, то есть удаленную отладку. Причем почти всегда — сразу, без напоминаний. После репорта о краше сразу законнектиться и посмотреть — самое естественное действие.
Стоят symbols servers, чтобы для main builds вынимать символы. Из source control взять нужные версии сорсов по номеру билда.
Если ты несколько дней не реагировал и машина простаивала в краше — тогда full memory dump.

На инструментированном билде, опять же, если попросишь, попытаются повторить. В этом смысле, опять же очень помогает автоматическое тестирование — повторить становится сильно проще. На удивление, это требуется очень редко, скорее всего, потому что умеют отлаживать без.

Remote, разумеется, для джедайских дебаггеров. Forget visual studio. Дебаггеров в Виндовс (во всяком случае, в unmanaged-части) два — cdb и windbg, один другого кошернее.

cdb — чисто консольный дебаггер. g, bp, чтения регистров, дампы памяти и стека, номер линии и название сорс-файла как средство просмотра сорcов.
windbg — поверх этого умеет немного из привычного простым смертным. Показывает код, показывает в нем брекпойнты красным, есть даже окна watch и call stack. Watch работает отвратно, апдейтиццо по настроению, сложные выражения не понимает и так далее. Почему так? Потому что не нужно это все настоящим джедаям. Самая ценная часть windbg — все равно консоль, вся круть там.

И при этом они очень мощные. Ставят все возможные брекпойнты — на загрузку dll, на загрузку драйвера, на доступ в куда угодно. Залезут в DLL unload, могут зарелоадить символы, покажут версию exe и прочее. Чтобы узнать все фичи, думаю, надо несколько лет плотных занятий. А, да, еще забавное занятие — коллективная отладка, когда в одной дебаг-консоли законнекчено несколько человек.

Люди умеют отлаживаться на _очень_ низком уровне, начинают смотреть на асм-код и голый стек-трейс не моргнув глазом. У моего бывшего лида всегда с собой волшебная бумажка, на которой нарисовано где и как при вызове функции складываются на стек ip и esp, что идет в ebp, куда кладутся локальные переменные. Магический ортефакт, +2 к debugging skills. И это нужно было не раз и не два. Раньше я бы просто послал нафиг, послал дебаг-билд и сказал делать репро с ним, или на неделю бы засел в корпение с изменением кода, тысячью printf и миллионом перезапусков, а тут оказывается такое умеют отлаживать без.

Чтобы проиллюстрировать — расскажу любимую историю.
Упало далеко и в релизном билде Висты, дали remote, хочется посмотреть переменные функции в середине стека. До this дебаггер размотать не может. Понятно почему — this был в ecx, потому что call внутренний, его пушнули на стек при вызове следующей функции, он где-то в середине стек-фрейма и дебаггер его найти никак не может.
Лид запускает любимый cdb, достает артефактную бумажко, начинает смотреть на дамп стека. Указателей рядом много разных, просто так не смотрится. Говорит — придется серьезней, будем смотреть на асм-код в месте вызова, посмотрим как он пушнул this на стек. Надо распечатать дизасм функции.
Набирает консольную команду, которая распечатывает код с lines tags по имени функции. Оно распечатывает только почему-то только половину, видимо ограничение по количеству вывода. Мучается с параметрами, не помогает.
Раздраженно говорит «Forget these fancy new commands, lets do it old-fashioned way». Берет адрес кода этой функции, смотрит какая идет в сорс-файле следующей, берет ее адрес, дампит голый дизасм между ними. Находит в нем пуши и нужный call, хэппи-энд.

То есть, команда которая автоматически по имени функции дизасм ее с линиями — это новомодная непривычная херовина, то ли дело дамп между двумя адресами.
Что же тогда такое VS debugger?

И пока — я не видел в Виндовс багов, какие beyond debugging. Бывает, что сидишь несколько дней, бывает что нужна помощь мужиков из другой команды, бывает, что баг баунсится много раз (или коллективно отлаживается), но тем не менее, если оно регулярно падает (даже не обязательно постоянный репро) — найдеццо.

Short recap:


1) Уметь делать отовсюду и всегда remote debug. Иметь базу символов на все билды.
2) Не бояться низкого уровня.
3) Инвестировать в этот энвайронмент.

И вот по этим всем поводам — когда дома в Винде что-то падает или тормозит, начинают приходить крамольные мысли законнектиццо к символам.
И отладить.
Tags:я работаю в microsoftdebugwindowsgraphicsprogrammingpracticesmicrosoft
Hubs: Development for Windows
Total votes 179: ↑144 and ↓35+109
Views1.7K

Popular right now

Top of the last 24 hours