Skip navigation
All Places > Administration > Blog > 2010 > November

Most of you probably know that on Windows 32-bit, each process (exe) has access to only half (2GB) of the maximum possible of 4GB "addressable memory" and the other half is reserved by the OS kernel (more background on this here). So when memory intensive applications like SolidWorks start reaching the 2GB addressable limit, the obvious reaction is why does the OS need as much as half the address space. Greedy Windows, you think.


You start Googling around or someone recommends using this magic switch Windows has that lets you increase the available address space to 3GB. That's better - take that, Windows. Now you can open and create larger assemblies and drawings than you could before. Fast forward to a few months later - you're starting to see the pinch in performance with your increasingly larger designs. You already have 4GB physical RAM on your 32-bit OS, so the only possible quick avenue of a performance boost (short of a full system upgrade) is to upgrade your graphics card.


So you spend time researching, spend money on the best graphics card for your money, install the latest and greatest certified drivers. Since you're in a bit of downtime, you might also install the latest system upgrades and SolidWork service pack. You can't wait to get back on your project.


Except - disaster. SolidWorks is now crashing randomly. How can that be ? You have the best card - everybody on the forum and your VAR said so, you have the latest certified drivers, the latest system updates, the latest SW service pack... Ah - that must be it. The latest service pack must be the fault. So you go back to your old service pack. But the crashes continue. Stupid software - hosed my machine again, you say. Your project is now way behind schedule and you have a bitter taste in your mouth.


What exactly happened here ?


Think back to when you turned on the /3GB switch. It's not usually very well understood, even among software developers (because most software developers operate in the "user address space", not the "kernel driver space"), what the reserved kernel address range is for. It is required for mapping all the devices, drivers and device memory you have on your system. This is colloquially known as the PCI memory hole.


On a test machine which has a mid-range workstation graphics card with 512 MB video RAM, the memory holes the PCI / AGP buses and the video card resources take up a total of 1334MB.


Now think back to that super duper video card you bought with 1 GB of VRAM - after that upgrade, Windows probably ran out of kernel addresses to map the device resources to. So smaller assemblies/drawings work fine, but when you start going up in usage of graphics card memory, it can lead to unpredictable behavior, i.e. random crashes.


So why did Microsoft introduce this /3GB switch in the first place ?


It was originally introduced for server-based processes such as SQL server or Exchange server and the like, before 64-bit became the common platform it is today. The key point here is that these server-based processes are CPU/RAM-intensive, but not device-intensive and especially not graphics card-intensive. So the server hardware doesn't have the devices that need the kernel-reserved addresses. In this case, it is indeed "greedy Windows" and the /3GB switch works well here. Of course, today no respectable IT admin would run a 32-bit server anyway, so this is no longer an issue. In fact, even at a consumer level you'd have to go to a lot of trouble to buy a new machine with 32-bit Windows. At a SolidWorks-user level, more users use 64-bit than 32-bit today.


So do yourself a favor - push the right buttons to upgrade to 64-bit. But if you can't upgrade right away for whatever reason, at least don't use the /3GB switch as a stop-gap.