!address command shows a different value for the U

问题:

I read in Windows Internals that when a thread is created, by default 1 MB of virtual memory is reserved for the user stack. Out of this 1 MB, only the first page (0x1000) will be committed.

I can see this when i dump the image header using dumpbin.exe. Here is what dumpbin shows:

However when i dump the address space of this exe in Windbg using !address command, I see a difference. Windbg shows me that the initial committed size is equal to 3 pages i.e 0x3000

Does anyone know why there is a difference between the initial stack commit size that the image header and debugger shows?

回答1:

That's a nice question and the key to the answer is understanding what the initial breakpoint is. How initial is it, for starters?

TLDR: The initial breakpoint it too late. That stack has already grown.

You haven't shared the binary you're dealing with, so I chose a binary that exhibits the same behaviour - cacls.exe on 64-bit Windows 10 (file version: 10.0.14393.0).

During the initial breakpoint we observe:

CommandLine: "c:\Windows\System32\cacls.exe"
Symbol search path is: srv*
Executable search path is: 
ModLoad: 00007ff6`83bd0000 00007ff6`83bdc000   cacls.exe
ModLoad: 00007ff8`29ce0000 00007ff8`29eb1000   ntdll.dll
ModLoad: 00007ff8`27500000 00007ff8`275ab000   C:\Windows\System32\KERNEL32.DLL
ModLoad: 00007ff8`26f30000 00007ff8`2714d000   C:\Windows\System32\KERNELBASE.dll
ModLoad: 00007ff8`280b0000 00007ff8`2814e000   C:\Windows\System32\msvcrt.dll
ModLoad: 00007ff8`29b10000 00007ff8`29bb2000   C:\Windows\System32\advapi32.dll
ModLoad: 00007ff8`273d0000 00007ff8`27429000   C:\Windows\System32\sechost.dll
ModLoad: 00007ff8`254f0000 00007ff8`25522000   c:\Windows\System32\NTMARTA.dll
ModLoad: 00007ff8`27150000 00007ff8`27245000   C:\Windows\System32\ucrtbase.dll
ModLoad: 00007ff8`277c0000 00007ff8`278e1000   C:\Windows\System32\RPCRT4.dll
(1310.17b0): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ff8`29db34e0 cc              int     3
0:000> !dh -f cacls

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
    8664 machine (X64)
       6 number of sections
57899A04 time date stamp Sat Jul 16 05:20:52 2016

       0 file pointer to symbol table
       0 number of symbols
      F0 size of optional header
      22 characteristics
            Executable
            App can handle >2gb addresses

OPTIONAL HEADER VALUES
     20B magic #
   14.00 linker version
    4C00 size of code
    3600 size of initialized data
       0 size of uninitialized data
    52F0 address of entry point
    1000 base of code
         ----- new -----
00007ff683bd0000 image base
    1000 section alignment
     200 file alignment
       3 subsystem (Windows CUI)
   10.00 operating system version
   10.00 image version
   10.00 subsystem version
    C000 size of image
     400 size of headers
    AF10 checksum
0000000000080000 size of stack reserve
0000000000002000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
    C160  DLL characteristics
            High entropy VA supported
            Dynamic base
            NX compatible
            Guard
            Terminal server aware
       0 [       0] address [size] of Export Directory
    7010 [     1CC] address [size] of Import Directory
    A000 [     7F0] address [size] of Resource Directory
    9000 [     2DC] address [size] of Exception Directory
       0 [       0] address [size] of Security Directory
    B000 [      54] address [size] of Base Relocation Directory
    6A10 [      38] address [size] of Debug Directory
       0 [       0] address [size] of Description Directory
       0 [       0] address [size] of Special Directory
       0 [       0] address [size] of Thread Storage Directory
    60E0 [      D0] address [size] of Load Configuration Directory
       0 [       0] address [size] of Bound Import Directory
    61B0 [     3B8] address [size] of Import Address Table Directory
       0 [       0] address [size] of Delay Import Directory
       0 [       0] address [size] of COR20 Header Directory
       0 [       0] address [size] of Reserved Directory

0:000> !address @rsp


Mapping file section regions...
Mapping module regions...
Mapping PEB regions...
Mapping TEB and stack regions...
Mapping heap regions...
Mapping page heap regions...
Mapping other regions...
Mapping stack trace database regions...
Mapping activation context regions...

Usage:                  Stack
Base Address:           00000049`8fbbc000
End Address:            00000049`8fbc0000
Region Size:            00000000`00004000 (  16.000 kB)
State:                  00001000          MEM_COMMIT
Protect:                00000004          PAGE_READWRITE
Type:                   00020000          MEM_PRIVATE
Allocation Base:        00000049`8fb40000
Allocation Protect:     00000004          PAGE_READWRITE
More info:              ~0k


Content source: 1 (target), length: 180

We see the initial stack commit size is 0x2000, but 0x4000 is actually committed.

But that's already very late during the process initialization process (no pun intended). All the import DLL are already loaded, for example.

The so-called "initial break-point" is simply a (more or less¹) hardcoded int 3 instruction called by the process initializtion code in NTDLL. If you look at the stack at this point you'll see the aptly named LdrpDoDebuggerBreak function which is called by LdrpInitializeProcess:

0:000> k
 # Child-SP          RetAddr           Call Site
00 00000049`8fbbee80 00007ff8`29d72e22 ntdll!LdrpDoDebuggerBreak+0x30
01 00000049`8fbbeec0 00007ff8`29da8986 ntdll!LdrpInitializeProcess+0x1962
02 00000049`8fbbf2c0 00007ff8`29d59fae ntdll!_LdrpInitialize+0x4e982
03 00000049`8fbbf340 00000000`00000000 ntdll!LdrInitializeThunk+0xe

By the time that happened the stack has already been used (for example, to load statically linked DLLs and perform their initialization code), so it shouldn't be much surprise that the stack has grown already.

To examine the process when it has just been created we need to break on the process creation event rather than on the initial breakpoint (which isn't that initial as we now understand).

We can do that either using sxe cpr and .restarting like I did or running WinDbg/NTSD with -xe cpr. Doing that reveals something interesting²:

0:000> .restart
CommandLine: C:\Windows\System32\cacls.exe

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
ModLoad: 00007ff6`83bd0000 00007ff6`83bdc000   cacls.exe
00007ff8`29d470b0 4883ec48        sub     rsp,48h

0:000> .imgscan /l
MZ at 00007ff6`83bd0000, prot 00000002, type 01000000 - size c000
  Name: cacls.exe
  Loaded cacls.exe module
MZ at 00007ff8`29ce0000, prot 00000002, type 01000000 - size 1d1000
  Name: ntdll.dll
  Loaded ntdll.dll module

0:000> !address @rsp


Mapping file section regions...
Mapping module regions...
Mapping PEB regions...
Mapping TEB and stack regions...
Mapping heap regions...
Mapping page heap regions...
Mapping other regions...
Mapping stack trace database regions...
Mapping activation context regions...

Usage:                  Stack
Base Address:           0000004a`5428e000
End Address:            0000004a`54290000
Region Size:            00000000`00002000 (   8.000 kB)
State:                  00001000          MEM_COMMIT
Protect:                00000004          PAGE_READWRITE
Type:                   00020000          MEM_PRIVATE
Allocation Base:        0000004a`54210000
Allocation Protect:     00000004          PAGE_READWRITE
More info:              ~0k


Content source: 1 (target), length: 478

The committed region size is 0x2000 - like the header says!

If we let it continue we'll eventually get to the initial breakpoint with more stack comitted.

---

¹I said more or less hardcoded because the actual code of the function is

0:000> uf ntdll!LdrpDoDebuggerBreak
ntdll!LdrpDoDebuggerBreak:
00007ff8`29db34b0 4883ec38        sub     rsp,38h
00007ff8`29db34b4 488364242000    and     qword ptr [rsp+20h],0
00007ff8`29db34ba 41b901000000    mov     r9d,1
00007ff8`29db34c0 4c8d442440      lea     r8,[rsp+40h]
00007ff8`29db34c5 418d5110        lea     edx,[r9+10h]
00007ff8`29db34c9 48c7c1feffffff  mov     rcx,0FFFFFFFFFFFFFFFEh
00007ff8`29db34d0 e88b30fdff      call    ntdll!NtQueryInformationThread (00007ff8`29d86560)
00007ff8`29db34d5 85c0            test    eax,eax
00007ff8`29db34d7 780a            js      ntdll!LdrpDoDebuggerBreak+0x33 (00007ff8`29db34e3)  Branch

ntdll!LdrpDoDebuggerBreak+0x29:
00007ff8`29db34d9 807c244000      cmp     byte ptr [rsp+40h],0
00007ff8`29db34de 7503            jne     ntdll!LdrpDoDebuggerBreak+0x33 (00007ff8`29db34e3)  Branch

ntdll!LdrpDoDebuggerBreak+0x30:
00007ff8`29db34e0 cc              int     3
00007ff8`29db34e1 eb00            jmp     ntdll!LdrpDoDebuggerBreak+0x33 (00007ff8`29db34e3)  Branch

ntdll!LdrpDoDebuggerBreak+0x33:
00007ff8`29db34e3 4883c438        add     rsp,38h
00007ff8`29db34e7 c3              ret

It does stuff like checking whether or not this thread is to be "hidden from the debugger", but basically it just breaks into the debugger.

²The .imgscan /l is needed because without it we get:

0:000> !address @rsp

No symbols for ntdll. Cannot continue.