Всем привет. Вот понадобилось кое-что посмотреть-отладить. Ок, уже давно была установлена варька с windbg 6.11.0001.404. Символы берутся с сервера, вроде всё намази (хотя бы раньше так было), но вот незадача: если попробуем ввести dt nt!_peb addr, то получим что-то такое: Код (Text): kd> dt nt!_peb 7ffd7000 +0x000 InheritedAddressSpace : ?? +0x001 ReadImageFileExecOptions : ?? +0x002 BeingDebugged : ?? +0x003 SpareBool : ?? +0x004 Mutant : ???? +0x008 ImageBaseAddress : ???? +0x00c Ldr : ???? ... +0x200 SystemDefaultActivationContextData : ???? +0x204 SystemAssemblyStorageMap : ???? +0x208 MinimumStackCommit : ?? Memory read error 7ffd7208 Странно. На !peb addr (длл'ка с расширениями присутствует, кстати), выдаёт Код (Text): kd> !peb 7ffd7000 PEB at 7ffd7000 error 1 InitTypeRead( nt!_PEB at 7ffd7000)... Также происходит ругань на !object: Код (Text): kd> !object 80559c20 80559c20: Not a valid object (ObjectType invalid) В общем непонятно. Старая версия сегодня себя повела так-же (не помню версию)... Странно, ведь до этого прекрасно пользовался. Гугл и его друзья молчат по этому поводу. Может кто-нибудь сталкивался с такой траблой?
Igor1024 dt nt!_peb 7ffd7000 -- а контекст процесса учитывается? Насчет !object -- можно увидеть дамп памяти по этому адресу?
Данные точные - от !process 0 0 Потому и спрашиваю, в принципе. А !object выдаёт лишь то, что я написал.
Igor1024 В смысле? !process 0 0 показывает список всех процессов. Не факт, что останов произошел в целевом процессе. Насчет !object я ошибся -- надо -0x18 байт (для 32битной системы) от тела объекта. В общем, хочется посмотреть на заголовок объекта -- может это и правда не объект. Например, для команды '!object 80559c20' надо посмотреть на 'dd 80559c20-18'.
И еще: это можно проделать самому: если 'dt _object_header objaddr-0x18' (на 32битной системе) показывает что-то "осознанное" (например, корректный указатель POBJECT_TYPE), то да, проблема в WinDbg (он почему-то не узнает в объекте объект), а если там мусор, то это, видимо, все же не объект. И неплохо бы узнать, откуда пришел адрес объекта.
Поэксперементировав, выяснил: все команды дебаггера прекрасно работают, пока не притрагиваешься к оси на виртуалке - в моём случае, мне нужно было запустить одну юзермодную прогу, чтобы лучше разобраться с одной нативной функой. Код (Text): kd> !peb 7ffd5000 PEB at 7ffd5000 InheritedAddressSpace: No ReadImageFileExecOptions: No BeingDebugged: No ImageBaseAddress: 01000000 Ldr 00191e90 Ldr.Initialized: Yes Ldr.InInitializationOrderModuleList: 00191f28 . 00194308 Ldr.InLoadOrderModuleList: 00191ec0 . 001942f8 Ldr.InMemoryOrderModuleList: 00191ec8 . 00194300 Base TimeStamp Module 1000000 498c0dae Feb 06 20:15:10 2009 C:\WINDOWS\system32\wbem\wmiprvse.exe 7c900000 49900c02 Feb 09 20:57:06 2009 C:\WINDOWS\system32\ntdll.dll 7c800000 49c4f2fe Mar 22 00:00:30 2009 C:\WINDOWS\system32\kernel32.dll 77c00000 4803825b Apr 15 03:12:11 2008 C:\WINDOWS\system32\msvcrt.dll 77dc0000 49900c03 Feb 09 20:57:07 2009 C:\WINDOWS\system32\ADVAPI32.dll 77e70000 49e5fc7d Apr 16 02:25:49 2009 C:\WINDOWS\system32\RPCRT4.dll 77fe0000 4a43386e Jun 25 19:42:22 2009 C:\WINDOWS\system32\Secur32.dll 7e360000 480381e1 Apr 15 03:10:09 2008 C:\WINDOWS\system32\USER32.dll 77f10000 490071d3 Oct 23 23:45:07 2008 C:\WINDOWS\system32\GDI32.dll 75250000 480381e7 Apr 15 03:10:15 2008 C:\WINDOWS\system32\wbem\wbemcomn.dll .........//ну и далее Потом волшебная команда: Код (Text): kd> g Попробуем посмотреть peb тот же самый снова (процесс wmiprvse.exe (возьмём его, к примеру), так что он живёт ещё и радуется): Код (Text): kd> !peb 7ffd5000 PEB at 7ffd5000 error 1 InitTypeRead( nt!_PEB at 7ffd5000)... Однако !object addr и dt _object_header addr-18 работают: Код (Text): kd> !object 8202f650 Object: 8202f650 Type: (823c8e70) Process ObjectHeader: 8202f638 (old version) HandleCount: 1 PointerCount: 5 kd> dt _object_header 8202f650-18 nt!_OBJECT_HEADER +0x000 PointerCount : 5 +0x004 HandleCount : 1 +0x004 NextToFree : 0x00000001 +0x008 Type : 0x823c8e70 _OBJECT_TYPE ..........//ну и далее Не могу понять, где могут быть косяки...
Вообще всё это нужно, чтобы понять полностью, как работает NtQueueApcThread. Когда проводил тесты, оказалось, что если шлёшь APC потоку-потомку (тестил с помощью __asm("mov 0,%eax") - фолт самый хороший показатель), то всё происходит как положено - обработчика сеховского нет, кроме дефолтного, выполнение приложения завершается. Однако я пробовал послать APC другой проге, главный и единственный поток которой был в alertable состоянии, и она продолжила работать. Это навело на мысль, что скорее всего, при исполнении APC-routine, устанавливается сеховый обработчик, который просто abort'ит routine, если что-то не так. Я читал код ReactOS, apc.c, если быть точным, и там всё дело в KernelRoutine - там вызывают эту функу чтобы выполнить код APC-routine, как думаю. И я не нашёл определение этой KernelRoutine (и указатель на неё не передаётся в функу KiDeliverApc), потому и взялся за отладчик.
Ок, моя догадка с сехом подтвердилась http://www.cnblogs.com/sunkang/archive/2011/05/06/2038787.html (там трудно ориентироваться, ибо это кривой копипейст). В принципе, всё эта статья мне разъяснила. Проблема с kd так и не решена. Завтра поставлю другую, более "чистую" версию без тулзов, отпишусь.
Вообщем смотри сюды http://analyze-v.com/?p=336 но помни про .pagein .cache forcedecodeuser Как то так.
Ок, теперь хотя бы стало понятно, что не так - до этого кд не говорил, что не смог загрузить символы для ntdll.dll с сервера; Одни говорят, что проблема у мелкомягких - мол, эту багу никак не пофиксят, другие - мол, преват, ничего удивительного... Странно... Ребят, может у кого-нить есть .pdb ntdll.dll для свиньи sp3? shchetinin Спасибо, а то бы лажанулся, когда начал отлаживать.
Если путь к символам установлен то .reload ntdll это не совсем баг, точнее баг но очень сложгы, это связано с тем что отладчик ядра. и подгрузкой памятью.
shchetinin можно поточнее, не совсем понял? ntdll.pdb нашёлся в пакете, который я стянул с сайта мелкомягких, осталось заставить дебаггер с ним подружиться... Пока он на него отказывается смотреть. Хех, ntdll.pdb в списке загруженных модулей (спасибо локальным символам и symstore), но ничего не поменялось... Печально.
Всё, тему можно закрывать - я разобрался сам с кд. Дело было просто-напросто в том, что nt == ntkrnlpa.pdb ntdll==ntdll.pdb; Вот просто из-за невнимательности (как всегда ) искал отладочные символы в другом модуле.
