Вышла книга (на английском языке):
Windows Debugging: Practical Foundations
Я также планирую издать её на русском языке.
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Windows Debugging book has been published!
Это была длинная дорога. Сначала перелет в Штаты, Редмонд для участия в подготовке экзамена. Затем ожидание бета-экзамена. Затем в Ирландии поездом из Дублина в Корк для прохождения экзамена в одном из центров тестирования. Сегодня я получил письмо с поздравлениями об успешной сдаче экзамена и зарегистрировавшись на сайте MCP я построил это лого:
_1125.png)
Ссылка на требования к экзамену:
http://www.microsoft.com/learning/en/us/Exams/70-660.aspx
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: I’m Windows Internals certified!
Используйте этот путь:
srv*<локальная папка>*http://ctxsym.citrix.com/symbols
Детали описаны в следующей статье:
CTX118622 - How to Use the Citrix Symbol Server to Obtain Debug Symbols
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Citrix joins Symbol Server Club!
Вышел второй том антологии (на английском языке):
Memory Dump Analysis Anthology, Volume 2
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Memory Dump Analysis Anthology, Volume 2
В этой части я попытаюсь объяснить файлы символов (symbol files). Обычно их называют файлами PDB потому что их имена файлов имеют расширение .PDB. Старые файлы символов также могут иметь расширение .DBG. Файлы PDB необходимы для правильного чтения дампов памяти. Без файлов PDB, дамп памяти представляет собой простой набор чисел, содержимое памяти без какой либо интерпретации. Файлы PDB помогают инструментам и отладчикам типа WinDbg правильно интерпретировать данные и преобразовать их в читабельный формат. Грубо говоря, файлы PDB содержат соответствия между числами и их интерпретацией, выраженной в коротких строках текста:
Поскольку эти соответствия изменяются когда мы устанавливаем патч или исправленную версию программы на компьютер и у нас появился новый файл дампа памяти, нам необходимы новые файлы PDB которые соответствуют измененным компонентам DLL или драйверам.
Некоторое время назад файлы символов необходимо было загружать с сайта компании Microsoft или копировать их с дисков CD. Сейчас компания Microsoft предоставляет выделенный интернет-сервер символьных файлов и отладчик WinDbg может загружать файлы PDB автоматически. Нам только нужно ввести адрес этого сервера в диалоге File \ Symbol File Path… и выделить Reload. Адрес сервера:
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Если мы не помним этот адрес и мы первый раз запускаем WinDbg на новом компьютере, мы можем выполнить следующую команду .symfix для автоматической установки пути к серверу и задать место на диске для сохранения загруженных файлов. Мы также можем проверить текущие пути поиска и загрузки символьных файлов путём выполнения команды .sympath. После изменения пути поиска или адреса загрузки необходимо явно перезагрузить файлы символов путем выполнения команды .reload:
0:000> .symfix
No downstream store given, using C:\Program Files\Debugging Tools for Windows\sym
0:000> .sympath
Symbol search path is: SRV**http://msdl.microsoft.com/download/symbols
0:000> .symfix c:\websymbols
0:000> .sympath
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
0:000> .reload
На заметку: Используйте эту ссылку для быстрой установки отладчика WinDbg и напоминания о путях и командах загрузки символов:
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Crash Dumps for Dummies (Part 5)
В предыдущей части мы рассмотрели падение программ: Часть 3. Другой вид проблем, случающийся не менее чаще, когда нам нужен дамп памяти для анализа: зависания. Здесь существует некоторая путаница в понимании разницы между этими двумя категориями проблем: падение и зависание. Хотя, временами, зависание является прямым следствием падения, большая часть зависаний случается независимо от них. Зависания также проявляют себя отличным образом. Давайте, для начала, рассмотрим падения и зависания приложений (процессов).
Когда приложение (процесс) падает, он часто исчезает. Когда процесс зависает, приложение все еще находится в оперативной памяти: мы можем видеть его в Диспетчере Задач (Task Manager), на пример, но оно не реагирует на команды пользователя или на другие запросы как проверка реакции порта TCP/IP (pinging a TCP/IP port). Если у нас произошло падение операционной системы, то мы наблюдаем синий экран смерти (BSOD) и/или перезагрузку системы. При зависании системы все замирает.
Зависание приложений или системы легко объяснить если рассматривать взаимодействия между приложениями или компонентами системы как обмен сообщениями. Один компонент посылает сообщение другому и ждет ответа. Некоторые компоненты являются критическими, как например, реестр конфигурации и настроек (registry). Следующая картинка иллюстрирует часто встречающуюся ситуацию зависаний, когда реестр перестает отвечать на запросы. Тогда каждое приложение запрашивающее свои собственные или системные настройки перестает работать.
Очень часто встречающейся причиной зависаний является так называемый дедлок (deadlock), когда два приложения (точнее, их вычислительные пути, потоки) взаимно ждут друг друга. Здесь можно привести аналогию с заблокированной дорогой:
Для того, чтобы посмотреть, что внутри приложения (процесса) или операционной системы вызвало зависание, нам нужен дамп памяти. Как нам получить его, если приложение или служба зависла? Пока ссылки даны на еще не переведенные статьи на английском языке.
Как нам получить дамп памяти, если система зависла?
Для большинства системных зависаний достаточно выбрать дамп ядра (Kernel memory dump) в Контрольной Панели (Control Panel \ System \ Advanced \ Startup and Recovery). Дампы ядра меньше по размеру и меньше подвержены повреждениям и обрубаниям из-за не достаточного размера файла подкачки (page file). Если вы обнаружите что вам нужно посмотреть что происходит внутри приложений, то нужно будет выбрать полный дамп физической памяти (Complete memory dump).
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Crash Dumps for Dummies (Part 4)
У меня давно была мечта начать писать про английский язык и использовать для иллюстраций язык проектирования UML (Unified Modeling Language). После многих лет работы за рубежом и чтения сотен книг на английском языке, включая лингвистическую литературу, я стал замечать, что знаю грамматику английского языка лучше русского. Сегодня я расскажу про первый урок, который я усвоил в 90х во время работы, посылая новые версии программ каждую неделю американским заказчикам. Речь пойдет о настоящем совершенном времени (Present Perfect Tense). Его используют, когда хотят подчеркнуть, что действие только что произошло. Вообразим, что мы только что послали багфикс или новую версию. Если мы напишем “I sent the fix” или “I sent the new version” это будет означать что вы послали его некоторое время назад (прошедшее время, Past Tense) и многое могло измениться с тех пор. Но, если мы напишем “I‘ve sent the fix” (I have sent the fix) или “I‘ve sent the new version” (I have sent the new version), это будет означать, что мы сделали это прямо сейчас, буквально перед тем, как мы написали об этом. Можно усилить упоминание о том, что мы только что сделали это: “I‘ve just sent the fix” (Я только что послал багфикс).
Разница между двумя временами может быть проиллюстрирована на следующих двух диаграммах последовательности (sequence diagram). В названиях я использую английский язык в качестве дополнительного учебного средства.
Когда из контекста все ясно, вместо Present Perfect Tense можно использовать Past Tense. Многие так и делают, особенно в Штатах. По моим наблюдениям, использование Present Perfect Tense более специфично для европейских англоговорящих стран. Если вы сомневаетесь в правильности предложения или фрагмента используйте Google для частотного сравнения:
“I’ve sent” - 1,840,000 раз
“I sent” - 23,600,000 раз
“I send” - 14,700,000 раз (Я определенно намереваюсь послать …)
“I’ve send“ - 60,900 раз (ошибка в форме глагола)
или поиск по полной фразе:
“I’ve sent the fix” - 7 раз
“I sent the fix” - 42 раза
“I send the fix” - 5 раз (Я определенно намереваюсь послать багфикс)
“I’ve send the fix“ - 1 раз (ошибка в форме глагола)
Если вы упоминаете точное время, то нужно использовать Past Tense: ”I sent the fix yesterday” (Я послал багфикс вчера).
В следующей части мы поговорим о формах глагола.
- Дмитрий Востоков @ DumpAnalysis.org -
Новая карикатура от Narasimha Vedala:
В госпитале для сердечных больных
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Dr. Debugalov’s remote debugging disaster
Еще проясняющая карикатура от Narasimha Vedala (щелкните по картинке чтобы увеличить):
Человек-паук
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Dr. Debugalov lectures on Debugging
Сегодня я обнаружил ссылки на портал и книгу Антология Анализа Дампов Памяти в английской Википедии:
http://en.wikipedia.org/wiki/Debugging
Очень признателен тому, кто добавил их.
- Дмитрий Востоков @ DumpAnalysis.org -
Оригинальная статья: Dump Analysis on Wikipedia