Nas versões de 32 bits, o espaço de endereçamento virtual é de 4 GB no total; 2 GB para espaço do usuário e 2 GB para o sistema. Quando você recebe 3 GB para o espaço do usuário, você só deixa 1 GB para o espaço do sistema. Isso significa que é duas vezes mais fácil esgotar o espaço de endereço do sistema, portanto, você pode encontrar problemas de driver no nível do kernel (coisas como controladores de disco e outras E / S).
Encontrei este excelente artigo no TechNet que explica algumas das armadilhas: " Gerenciamento de memória - Desmistificando / 3GB " ...
Aqui está uma sinopse aplicável:
Remember that we only have a 4GB total address space to work with. If we have to allocate an additional 1GB of this address space to the user-mode space, then the System space is cut in half. Drivers, Heap, Paged & NonPaged Memory all have only half the resources to work with now. However, because of the way memory mapping works, cutting the kernel space in half does a lot more than just reducing the address space. Many of the structures within the kernel virtual memory space are cut back by far more than 50%. For example, we took a Windows Server 2003 Enterprise R2 machine with 1GB of RAM installed and compared some values with and without the /3GB switch enabled.
Default OS Build:
Free System PTE's: 251,980 (1,007,920 kb)
NonPaged Pool Max: 206,848 kb
With /3GB enabled:
Free System PTE's: 34,884 (139,536 kb)
NonPaged Pool Max: 129,312 kb
As you can see, the Free System PTE's drops by over 200,000. Keep in mind that this is only a test server that isn't under any sort of load. A machine under medium to heavy load could quite easily run out of free PTE's - meaning that the system can no longer map system pages such as I/O space, kernel stacks and memory descriptor lists. In addition, look at NonPaged Pool after the /3GB parameter is enabled.