C++博客-随风-随笔分类-Windbghttp://www.cppblog.com/Alexxu/category/10098.html游戏理想 Time is lifezh-cnThu, 21 Jan 2010 14:21:24 GMTThu, 21 Jan 2010 14:21:24 GMT60FS寄存器到_TEB线程环境块http://www.cppblog.com/Alexxu/archive/2010/01/20/106066.htmlOnly SoftOnly SoftWed, 20 Jan 2010 07:10:00 GMThttp://www.cppblog.com/Alexxu/archive/2010/01/20/106066.htmlhttp://www.cppblog.com/Alexxu/comments/106066.htmlhttp://www.cppblog.com/Alexxu/archive/2010/01/20/106066.html#Feedback0http://www.cppblog.com/Alexxu/comments/commentRss/106066.htmlhttp://www.cppblog.com/Alexxu/services/trackbacks/106066.htmlint GetThreadId()
{
 int ithread = 0;
 _asm{
    xor esi , esi
    mov eax, fs:[esi+18h]     
       mov ecx, [eax+ 20h]
       mov eax, [eax+ 24h]
    mov dword ptr[ithread], eax
 }
 return ithread;
}
从FS寄存器获取当前进程ID
int GetProcessId()
{
 int iProcess = 0;
 _asm{
    xor esi , esi
    mov eax, fs:[esi+18h]
       mov ecx, [eax+ 20h]
       mov eax, [eax+ 24h]
    mov dword ptr[iProcess ], ecx
 }
 return iProcess ;
}

原理：
1.fs:18h 地址指向线程环境块_TEB
打开windbg可以证明：
0:028> dd fs:18h L1
0053:00000018  7eeb8000
0:028> !teb
TEB at 7eeb8000
    ExceptionList:        1f8ff15c
    StackBase:            1f900000
    StackLimit:           1f8fc000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 7eeb8000
    EnvironmentPointer:   00000000
    ClientId:             00001a30 . 00001408
    RpcHandle:            00000000
    Tls Storage:          133d2718
    PEB Address:          7efde000
    LastErrorValue:       0
    LastStatusValue:      c0000302
    Count Owned Locks:    0
    HardErrorMode:        0

2. 在_TEB中找到线程ID和进程ID
0:028> dt ntdll!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x01c EnvironmentPointer : Ptr32 Void
   +0x020 ClientId         : _CLIENT_ID

0:028> dt ntdll!_CLIENT_ID
   +0x000 UniqueProcess    : Ptr32 Void  >进程ID
   +0x004 UniqueThread     : Ptr32 Void  >线程ID

当然从TEB又可以找到_PEB的地址，从_PEB里面可以获取到更多的信息。暂且搁笔~~

Only Soft 2010-01-20 15:10 发表评论
]]>驱动中关于内存分配http://www.cppblog.com/Alexxu/archive/2009/11/15/101030.htmlOnly SoftOnly SoftSun, 15 Nov 2009 15:57:00 GMThttp://www.cppblog.com/Alexxu/archive/2009/11/15/101030.htmlhttp://www.cppblog.com/Alexxu/comments/101030.htmlhttp://www.cppblog.com/Alexxu/archive/2009/11/15/101030.html#Feedback0http://www.cppblog.com/Alexxu/comments/commentRss/101030.htmlhttp://www.cppblog.com/Alexxu/services/trackbacks/101030.html      分配原则：尽量使用可分页内存，但是必须注意高等级IRQL执行不允许page fault。所以不允许采用可分页内存。可以使用PAGED_CODE();宏来检查。
      非分页内存在系统中是一个有限的资源，取决于操作系统和物理内存大小. (NT VMM使用一个私有算法来计算非分页大小，这个算法使用物理内存总是作为计算因子来计算。)
     NT提供如下例程来分配内存：
       ExAllocatePool();
       ExAllocatePoolWithQuota();
       ExAllocatePoolWithTag();
        ExAllocatePoolWithQuotaTag
       调用以上例程分配内存是必须制定内存的类型：
       NonPagedPool
       PagedPool
       NonPagedPoolMustSuccessed.
       ......................

    关于非分页内存碎片问题：
     本来初始化的时候地址都是相邻的非分页池会变成碎片。而且VMM在托大的时候也不保证地址相邻。
    如果请求的分配或者释放小块内存（小于一个PAGE_SIZE）,可能导致物理内存碎片化。这回给系统带来各种各样的问题，包括降低系统性能和分配内存失败的情况。
    解决办法使用旁视列表，旁视列表是一个NT4.0开始提供的一个内存分配方式；具体请参考WDK docment.
     顺便提一下内核栈：
     每个在NT平台的线程有一个用户栈在用户模式执行的时候使用，一个内核栈在内核模式执行的时候使用。当线程请求系统服务而切换到内核模式的时候，陷阱机制会切换栈。用分配和线程的内核空间栈来覆盖用户空间栈。
在NT3.51之前，内核栈限制在两页的内存中。NT4.0开始增加到12KB.必须要谨慎的在栈上使用变量以节省占空间，防止超过限制而是系统停止。



Only Soft 2009-11-15 23:57 发表评论
]]>windbg基础篇--window APIhttp://www.cppblog.com/Alexxu/archive/2009/08/24/94232.htmlOnly SoftOnly SoftMon, 24 Aug 2009 03:20:00 GMThttp://www.cppblog.com/Alexxu/archive/2009/08/24/94232.htmlhttp://www.cppblog.com/Alexxu/comments/94232.htmlhttp://www.cppblog.com/Alexxu/archive/2009/08/24/94232.html#Feedback0http://www.cppblog.com/Alexxu/comments/commentRss/94232.htmlhttp://www.cppblog.com/Alexxu/services/trackbacks/94232.htmlWin32 API中的所有调用最终都转向了ntdll.dll，再由它转发至ntoskrnl.exe。ntdll.dll是本机 API用户模式的终端。真正的接口在ntoskrnl.exe里完成。事实上，内核模式的驱动大部分时间调用这个模块，如果它们请求系统服务。Ntdll.dll的主要作用就是让内核函数的特定子集可以被用户模式下运行的程序调用。Ntdll.dll通过软件中断int 2Eh进入ntoskrnl.exe，就是通过中断门切换CPU特权级。
Ntdll.dll 上面的相关API函数原型和参数都没有文档化(Undocumented ):  http://undocumented.ntinternals.net/ 这里提供了Ntdll.dll部分未公开函数的原型.

理解window API及函数原型对我们的调试将是非常重要的: 因为你时常需要去察看一些函数的参数,或者根据参数找到某些输入指针.

例如:
  17  Id: a84.cc4 Suspend: 1 Teb: 7ff3a000 Unfrozen
ChildEBP RetAddr  Args to Child             
187ffdb8 77845e6c 7782fc72 00001938 00000000 ntdll!KiFastSystemCallRet
187ffdbc 7782fc72 00001938 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
187ffe20 7782fb56 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0x13e
187ffe48 01b05d13 0x77c8ba60 81fa55ed 028766c8 ntdll!RtlEnterCriticalSection+0x150

从堆栈可以看出线程17 正在进入某一个临界区.  0x77c8ba60 就是传入的临界值 参数.

17> !cs 0x77c8ba60             --> !cs 是用来查看临界区信息的命令
DebugInfo          = 0x77fbde20
Critical section   = 0x77c8ba60 (GDI32!semColorSpaceCache+0x0)
LOCKED
LockCount          = 0x0
OwningThread       = 0x00000dd8
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000

可以看到 LOCKED 代表临界区是锁定状态. 即被占用.
OwningThread   即是占用线程.

临界区信息结构定义在ntdll, 可以使用如下指令进行察看.
> dt  ntdll!_RTL_CRITICAL_SECTION
   +0x000 DebugInfo        : Ptr32 _RTL_CRITICAL_SECTION_DEBUG
   +0x004 LockCount        : Int4B
   +0x008 RecursionCount   : Int4B
   +0x00c OwningThread     : Ptr32 Void
   +0x010 LockSemaphore    : Ptr32 Void
   +0x014 SpinCount        : Uint4B

察看某个动态库函数表的指令:
x ntdll!*
x kernal!*

察看结构体定义:
dt ntdll!*

任何动态库包括window 32的用户态dll 和用户自定义动态库都是生长在进程内存空间上的.
DLL 没有自己的"私有"地址空间. 它们总是被影射到应用程序的虚拟地址空间,在需要时才会被读取到物理内存中.
在本系列的其它章节我会谈到虚拟地址空间的内容.

通过指令可以看到ntdll 被映射到77800000 ~ 7793c000的内存空间中.
> x *!
77800000 7793c000   ntdll      (pdb symbols)          c:\mylocalsymbols\ntdll.pdb\F0164DA71FAF4765B8F3DB4F2D7650EA2\ntdll.pdb

当你的代码(线程)栈中出现地址范围在 77800000 ~7793c000 之间的函数调用都表示在call NTDLL.dll
比如:
   7  Id: a84.c34 Suspend: 1 Teb: 7ff3f000 Unfrozen
ChildEBP RetAddr  Args to Child             
089bfe8c 77845e6c 75a0179c 00000d98 00000000 ntdll!KiFastSystemCallRet
089bfe90 75a0179c 00000d98 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
089bfefc 75c9f003 00000d98 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
089bff14 75c9efb2 00000d98 ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
089bff28 69434fea 00000d98 ffffffff 0780c178 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
此线程中WARNING: Stack unwind information not available. Following frames may be wrong.表示windbg无法翻译或者找到对应symbols来显示code stack. 这种错误往往是保存dump file时出现的某种异常信息.window也没有给出合理的解释.
以下是MSDN的原话:
In some cases, the stack trace function will fail in the debugger. This can be caused by a call to an invalid address that caused the debugger to lose the location of the return address; or you may have come across a stack pointer for which you cannot directly get a stack trace; or there could be some other debugger problem. In any case, being able to manually walk a stack is often valuable.

这时候你需要手动的进行恢复栈调用. 如果你了解每个动态库的映射地址你就很容易进行分析了.

察看动态库中每个函数映射的地址可以采用如下指令 :
x ntdll!


手动恢复栈的大致原理如下:
1. 列出线程环境信息
 0:000> !teb

TEB at 7fffe000

    ExceptionList:        0012ff88

    StackBase:            00130000

    StackLimit:           00126000

    ……….

2. 打开整个线程栈.
0:000> dds 00126000 00130000

3. 察看内存中所有可能是函数返回值.  
>ln address





Only Soft 2009-08-24 11:20 发表评论
]]>windbg基础篇--异常上下文http://www.cppblog.com/Alexxu/archive/2009/08/22/94085.htmlOnly SoftOnly SoftSat, 22 Aug 2009 05:47:00 GMThttp://www.cppblog.com/Alexxu/archive/2009/08/22/94085.htmlhttp://www.cppblog.com/Alexxu/comments/94085.htmlhttp://www.cppblog.com/Alexxu/archive/2009/08/22/94085.html#Feedback4http://www.cppblog.com/Alexxu/comments/commentRss/94085.htmlhttp://www.cppblog.com/Alexxu/services/trackbacks/94085.html阅读全文

Only Soft 2009-08-22 13:47 发表评论
]]>