User32.dll,kernel32.dll,shell32.dll,gdi32.dll,rpcrt4.dll,comctl32.dll,advapi32.dll,version.dll等dll代表了Win32 API的基本提供者；
Win32 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