One colleague asked me that question in order to answer one of his customer's multiple questions.

The answer is four gigs (4GB), no matter whether boot.ini includes /3GB or not. In fact in x64 OS, that switch is simply ignored by the OS.

In case what the different documents about this fact (like KB294418) weren't convincing enough, I wanted to show him by example that it was actually the case.

So I ran my SQL Server 2000 (32bit) SP4 Developer Edition under the control of a debugger and set a breakpoint in the function which initializes SQL Server's Buffer Pool, where we query for system memory settings like the total amount of physical memory, free physical memory, or total virtual address space (MEMORYSTATUSEX.ulTotalVirtual), which is the value we're interested in.

To begin, let me show you how my boot.ini is free of any 3GB switch:

[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /fastdetect /NoExecute=OptIn

To begin, let me show you how my boot.ini is free of any 3GB switch:

0:000:x86> p
sqlservr!BPool::Init+0x160:
00000000`0059e4b8 52              push    edx

0:000:x86> p
sqlservr!BPool::Init+0x161:
00000000`0059e4b9 c745bc40000000  mov     dword ptr [ebp-44h],40h ss:002b:00000000`001cf84c=001cf854

0:000:x86> r
eax=7d4ec2f0 ebx=7d4e5257 ecx=00000000 edx=001cf84c esi=00c45e80 edi=7d4c0000
eip=0059e4c0 esp=001cf7c8 ebp=001cf890 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
sqlservr!BPool::Init+0x168:
00000000`0059e4c0 ffd0            call    eax {kernel32!GlobalMemoryStatusEx (7d4ec2f0)}

0:000:x86> p
sqlservr!BPool::Init+0x16a:
00000000`0059e4c2 8b45e4          mov     eax,dword ptr [ebp-1Ch] ss:002b:00000000`001cf874=fffe0000

0:000:x86> dt 001cf84c MEMORYSTATUSEX
   +0x000 dwLength         : 0x40
   +0x004 dwMemoryLoad     : 0x3e
   +0x008 ullTotalPhys     : 0x1`35748000
   +0x010 ullAvailPhys     : 0x73a46000
   +0x018 ullTotalPageFile : 0x1`9e500000
   +0x020 ullAvailPageFile : 0xee0d6000
+0x028 ullTotalVirtual  : 0xfffe0000
   +0x030 ullAvailVirtual  : 0xfc76f000
   +0x038 ullAvailExtendedVirtual : 0

0xfffe0000 bytes in decimal are 4294836224 bytes, equivalent to 4194176 KB or 4095.875 MB or 3.9998 GB, that is 4 GB.


0:000:x86> lmv msqlservr
start             end                 module name
00000000`00400000 00000000`00cbb000   sqlservr     (private pdb symbols) 
<Path_Removed_Intentionally>\sqlservr.pdb
    Loaded symbol image file: sqlservr.exe
    Image path: sqlservr.exe
    Image name: sqlservr.exe
    Timestamp:        Wed May 04 09:00:55 2005 (42787327)
    CheckSum:         008C2D98
    ImageSize:        008BB000
    File version:     2000.80.2039.0
    Product version:  8.0.2039.0
    File flags:       0 (Mask 3F)
    File OS:          40000 NT Base
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04e4
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft SQL Server
    InternalName:     SQLSERVR
    OriginalFilename: SQLSERVR.EXE
    ProductVersion:   8.00.2039
    FileVersion:      2000.080.2039.00
    FileDescription:  SQL Server Windows NT
    LegalCopyright:   © 1988-2004 Microsoft Corp. All rights reserved.
    LegalTrademarks:  Microsoft® is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Corporation
    Comments:         NT INTEL X86

It's worth mentioning that this is not the case for every 32bit process running under WOW, but only to those which, like sqlservr.exe, have been linked using the /LARGEADDRESSAWARE option.

And it is also good to remind you that all that glitters is not gold, and therefore I recommend you reading Slava's post "Be Aware: 4GB of VAS under WOW, does it really worth it?"

Hope you liked this post!