Microsoft advices to use /3Gb switch in Boot.ini in order to get more memory for a process running on 32bit system.

Currently I need a lot of memory for devenv process (Visual Studio 2008) because I have a complex solution that has a lot of projects and forms and consumes a lot of resources in design time.

I would like to ask, if anybody knows, what are negative aspects of using /3Gb switch, are there any circumstances where it is not recommended to use it.

  • Thanks to all who answered, all posts are very informative and there are lot of considerations to be taken into account. I also read some documentation and noticed that for MS SQL Server you dont need this even for 32 bit systems, you could enable Address Windowing Extensions (AWE) technet.microsoft.com/en-us/library/ms190673.aspx
    – Bogdan_Ch
    Jun 18, 2009 at 8:53

7 Answers 7


On a desktop machine, there are likely no problems. The kernel paged pool is smaller on a W2K3 / WXP machine w/ the /3GB switch set. This is probably not an issue for a desktop machine because you shouldn't be coming close to exhausting your kernel paged pool. On a server, exhausting the kernel paged pool will cause you problems, and it's much more likely you could exhaust it.

Here's some good detail about the kernel memory considerations associated with the /3GB switch. If you really want to, you can fire up the NT kernel debugger and profile your system before and after the change w/ the information in this doc: http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx

  • 3
    I always wonder, when I get downvotes, why I'm getting downvotes. I don't believe anything in this posting is factually incorrect, but if it was I'd want to know so that I could either delete the post or correct it. I'm curious what the problem the downvoters have is with it... (and, of course, I realize that they'll never come back to respond to this comment... oh, well...) Jun 19, 2009 at 3:23

You will have less memory available to your kernel - the switch adjusts the kernel mode address space/user mode address space split, previously 2GB to 2GB, to 1GB to 3GB. Read Raymond Chen's post on /3GB, and the follow-ups, before proceeding.


Before making any changes, you should first check if the processes you want to run are linked with the LARGEADDRESSAWARE flag. With the flag, there will be no changes to how the process uses memory.

You can use the SDK Tools for this:

dumpbin /headers exeName

The headers spit out should include:

Application can handle large (>2GB) addresses

I did the check on devenv.exe and in VS2008 it does include the flag.


Plenty of drawbacks. By default, Windows will allocate a 4GB memory pool to every process, which is split 50/50 between the kernel mode processes (common to all apps) and user mode processes (unique for each app) (simplified explanation). An app running on the system therefore has 2GB of memory to play with, while the system itself has it's own 2GB. Important note: this second 2GB is the same 2GB for all apps running on the system.

The /3GB switch adjusts the split so that kernel mode gets 1GB and user mode gets 3GB.

Now consider the apps you're running. Some of them will require more kernel mode space, some will require more user mode space. As the kernel mode pool is shared, you can very quickly run out of memory there if you're running apps that put kernel mode memory under pressure. On the other hand, if your apps use lots of user mode memory, implementing /3GB will give them the headroom they require.

So it's really down to the nature of the applications you want to run. The golden rule is to consult the app vendor and read the documentation; in particular if the app vendor doesn't have a recommendation either way you should start becoming suspicious... have they properly tested their app or not? This is basic stuff that every vendor should know.

There's a pretty good discussion of it all here: http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx

In your particular case, I think switching to 64 bit and getting more RAM will be a more viable solution, as /3GB won't really get you what you want (does it even work on XP?)

  • I think, instead of "kernel mode pool" better to say "kernel virtual address space". Also "shared" means for me "identical for all applications". Is it so?
    – dma_k
    Oct 12, 2012 at 13:57

We've used it on a couple of systems that were running image processing apps on lots of large images, and never noticed any problems. In any situations where you need the extra Gig of application memory, you're probably going to let the app run and not do anything else with the system, so there's probably not going to be much impact.


I have seen it interfere with video cards in odd ways. But any driver can misbehave with this switch if it's not written properly.

Sometimes these issues can be worked around with the addition of the /USERVA switch.



It only works reliably (except for debugging drivers etc) on an enterprise server OS for LARGEADDRESSAWARE binaries.

devenv is not such a binary. SQL Server and Exchange are, for example.

You'd need an x64 bit OS and VS x64 edit: LARGEADDRESSAWARE is detected on x64 to break the 2GB limit.

  • actaully devenv.exe is largeaddressaware. Jun 17, 2009 at 17:06
  • correct, I missed that on my edit about x64. Edited again
    – gbn
    Jun 17, 2009 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.