Личен блог на Георги Христов

Интерфейс към терзанията на един гийк

Дебъгване на Windows

Дебъгването не е съвсем тривиален процес. От друга страна за елементарни проблеми не са нужни сериозни познания по операционни системи, хардуер и т.н. Процесът се опростява, колкото може повече с излизането на нови версии на ОС и инструменти.

Ще започна от това какво представлява дебъгването накратко. Всъщност самото име говори достатъчно за значението на процеса, а именно – отсраняване на бъгове (грешки).  Възможни са два типа дебъгване – на потребителско ниво (user space) и на ниво ядро на операционната система (kernel space). Тук ще пиша накратко за дебъгване предимно на проблеми с драйвери (kernel space) и по-рядко библиотеки, които водят до нестабилна работа на системата (рестартиране, сини екрани, зависвания и др.).

Първата и най-важна стъпка при проблеми със стабилността на операционната система (в този случай Windows) е проверка на конфигурацията ?, за това, как се държи при такива проблеми. Това може да стане от Control Panel -> System ->Advanced System Settings -> Advanced -> Startup and Recovery ->Settings.

Windows Startup and Recovery

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Интерисува ни полето  System failure  и най-вече как ще се записва информацията при възникване на критична грешка.

 

 

 

 

Възможностите и избора по подразбиране се различават при различните версии на  Windows. Първата възможност е да не се записва никаква информация. Разбира се напредналият потребител никога не я използва.

Втората е Small memory dump (64 KB). При неин избор се записва най-необходимата информация за последващо дебъгване: съобщението за грешка,  списък на драйверите, контекста, процеса и нишката. При настъпване на следваща грешка се записва друг файл. Форматът на името на файла е следният: Mini012610-01.dmp – 26 януари 2010 година, първа грешка. Файловете се записват в %SystemRoot%\Minidump. В повечето случаи това е C:\Windows\Minidump. Разбира се може да се промени, но не винаги е възможно в графичен режим и едва ли човек, способен да промени системни променливи или къде да се записва mini dump ще чете това, затова пропускам обясненията. Важно е да се отбележи, че за да се извърши операцията е нужно наличието на поне 2 MB pagefile на системния логически дял на твърдият диск.

Следващата възможност е Kernel memory dump. Записва се всичко на ниво kernel space, което е в оперативната памет. Паметта, заделена за потребителските програми не се записва. По подразбиране информацията се записва в %SystemRoot%\MEMORY.DMP. Както се вижда на изображението по-горе има възможност при следваща грешка да се презапише върху същия файл. Нужният минимум за pagefile в този случай варира, но в никакъв случай не е повече от 2 GB.  Според мен това е най-подходящият избор в повечето ситуации.

Последната възможност е Complete memory dump. Записва се цялото съдържание на оперативната памет към момента на фаталната грешка. Файлът по подразбиране е същият, както при Kernel memory dump. Необходимият минимум на  pagefile в този случай е обемът на RAM паметта плюс 1 MB. Логично, това е най-добрият избор при дебъгване на големи проблеми. Сравнително често е ненужен. Аз лично го избягвам, защото е доста бавен процес и в повечето случаи съдържа много излишна информация за  нуждите ми.

Изброените настройки могат да се редактират директно в регистрите на Windows. Пътят до тях е: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl.  Горните четири възможности отговарят на следните стойности:

CrashDumpEnabled REG_DWORD 0x0 –> None
CrashDumpEnabled REG_DWORD 0x1 –>  Complete memory dump
CrashDumpEnabled REG_DWORD 0x2  –> Kernel memory dump
CrashDumpEnabled REG_DWORD 0x3 –> Small memory dump (64KB)

След като имаме нужната информация за дебъгване остана само да се сдобием със софтуер, с който се дебъгва. Пакетът се казва Debugging Tools for Windows и съдържа WinDbg, KD, CDB, и NTSD. Би трябвало да  се сетите откъде да си го свалите, ако не – ползвайте “фирменият сайт на фирмата Google”. Нас ни интерисуват WinDbg и KD. WinDbg е графичен аналог на конзолният дебъгер – KD. Разлика във функционалността им няма. Въпрос на предпочитания е изборът между двата. Въпреки, че по принцип предпочитам конзолата по принцип, WinDbg последно време е моят избор.

След като изтеглите и инсталирате Debugging Tools for Windows стартирайте WinDbg. След което е нужна настройка на symbols. Може да стане от File ->Symbol File Path. Ще се появи прозорец, подобен на изображението долу. По принцип се въвежда локална кешираща директория, последвана от symbol сървъра на Microsoft.  Аз ползвам C:\symbols за локално копие. Когато е нужно програмата търси първо там, а след това, ако се наложи сваля от сървъра. Ако решите да изтеглите пълен архив на символите можете  да  посочите само него. Обратното също е възможно. Може да посочите  отдалеченият сървър  без да записвате  локални копия. Синтаксисът е следният: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols.

symbol search path

Вече сме готови за дебъгване. Стартираме WinDbg. Отиваме на File->Open Crash Dump. Aз ползвам WinDbg версия 6.11.0001.404. При нея в момента на отваряне на dump файла автоматично се стартира команда !analyze и единственото, което трябва да направим е да изчакаме малко и да прочетем изхода. По-старите версии, които съм ползвал не изпълнняваха никакви команди, а чакаха да се въведе команда в командното поле в долният край на прозореца.  !analyze е винаги първата команда, която се изпълнява при дебъгване, защото може да е достатъчна.  Аналог на зареждането на дъмп-а на паметта в конзолата е:

kd -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z c:\windows\minidump\minidump.dmp.

При желание може kd да се замени с WinDbg. Ако изходът от командата ви подсказва грешка в Windows не и вярвайте! Колкото и да се говори, че Windows е “скапана” операционна система, истина е съвсем друга. Тя е една от най-добрите ОС. В над 90 % процента от случайте проблемите идват от външен софтуер. Самата ОС се тества всеки ден от специалисти, до чиито знания и опит простосмъртните никога няма да достигнат.

Няколко насоки:

  • aко искате да видите разширен изход (verbose output) от командата използвайте опция -v;
  • ако искате да прочетете грешката и параметрите използвайте !analyze -show;
  • за извеждане на заредените модули (драйвери): lm nt;
  • разгледайте  lm, !process, !thread и !devstack

Това е от мен. Не очаквах да стане толкова дълго писанието и затова претрупах нещата накрая.

Подобни публикации:

  1. Как се стартира Windows
  2. Корегиране на грешка “ERROR_FILE_CORRUPT” в Windows 7 и Windows Server 2008 R2
  3. Управление на паметта в Windows 8
  4. Linux срещу Windows – първа част
  5. Управление на паметта в Windows

Публикувано на | January 27, 2010 | 4 Коментара


Категории: операционни системи
Тагове: > > >

Мнения и коментари

  • Добавете ме в Google+

  • Последни публикации

  • Последни коментари