L4D2 OS Paged Pool Memory Low on XP

From Steam, I installed and played Left for Dead 2 (L4D2) for a few hours without any problems.  After rebooting after an update, the warning “OS Paged Pool Memory Low” in red appeared in the game, followed shortly by bizarre visuals, halting sound, jerky game play, and ultimately, a lockup or crash.  A few days later (and after rebooting) I tried it again, and it was fine.  Until I rebooted …

It seemed that pawing at it like a confused monkey was not solving my problem, so I consulted the Internet, which recommended a curious mixture of unrelated voodoo and homeopathic remedies, and Steam themselves has a page that mumbles incoherently about drivers and suggests removing parameters that nobody has.  Those few people who have had, and solved this problem, appear to have tried hundreds of things all at once and were clueless as to what fixed the issue.

While making sure drivers are up-to-date is rarely bad advice, it’s unlikely to actually fix anything unless your current drivers happen to be buggy.

So, what’s happening, and how does one fix it?

XP has two memory pools, paged and non-paged, and without going into too much technical detail, paged memory can use disk space to expand its total pool (“virtual memory.”)  XP uses heuristics at boot time to determine how much memory to dedicate to the non-paged and paged pools.

Specifically, XP calculates a limit for the paged pool based on how much address space that other resources, like page table entries, want.  With a lot of RAM and a reasonable amount of swap, XP can still apparently get it wrong.  On the plus side, it can be tweaked manually to solve the issue.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

in the registry has all kinds of nifty knobs, and the most important one is “PagedPoolSize.”

Note:  before doing this, make sure you have a reasonable amount of physical ram and that virtual memory (My Computer->Properties->Advanced->Performance->Virtual Memory) is set either to automatic, or at least a gig or two or twice physical ram size.

PagedPoolSize is almost undoubtedly set to “0,” which means XP will automatically determine the limits.  Setting this to “0xFFFFFFFF” means “set this as high as possible,” which is a dynamic value, but based on your amount of physical RAM rather than every other knob in the system.  As a troubleshooting step, it’s reasonable to start here — reboot, then try out L4D2.

If it works, you can back this number down a bit:  some testing has shown that 256M is sufficient to play without problems (“0x10000000” hex, or “268435456” decimal) but your mileage may vary.


Launching Firefox Quickly: XP and Windows 2000

If you’re like me, a considerable amount of your computing experience takes place within Firefox.  I have a couple of old, slow computers, however, for which the actual loading speed of Firefox itself is problematic.  Either can keep up fine with web content, and their connections are fast, but Firefox itself can take a surprisingly long amount of time to come up  — which is inevitably when I need it.  Leaving Firefox open but minimized is a somewhat reasonable solution, except for Murphy’s law, which is strictly enforced here, means that I need Firefox after having just booted the machine, or just closed it without thinking.

XP has a strategy for speeding the load time of any application, which is known as “prefetching.”  There are a lot of myths and misinformation about what this is, but essentially, XP keeps track of how a program is loaded, and stores this information in its prefetch area.  Next time the same program is launched, XP consults the prefetch area to see how to load the program optimally.

N.B.:  XP prefetching is automatic and works for every application.  There’s a myth that adding “/prefetch:1” (or some other number) switches to the end of your program’s launch criteria will do something beneficial with the prefetch subsystem.  It does do something, and that is to pass the number to the hash used for prefetching.  So adding it will have the effect of first slowing down the launching of Firefox to its unprefetched speed, then the next time it’s launched, it will be as fast as it was before the switch was added.  Naturally, adding this switch is simply a waste of time.

While I’m digressing, I should point out that clearing the prefetch folder is an equally pointless waste of time and resources.  Getting rid of the trace and layout files won’t make prefetching any better, it will just force them all to be recreated, thus slowing down the initial launch of all applications until this is reconstructed.  Windows actually cleans out the folder itself whenever it needs it, so it’s best just to leave it alone.

Which brings me back around to Windows 2000, the venerable operating system on which my tablet runs Firefox.  Win2k has no prefetching system, so that alternative strategies need to be employed.

This leads to an alternative strategy called “preloading,” which is not like prefetching at all, but more like loading Firefox and minimizing it, where much of Firefox is actually in memory.  Early versions of Firefox included a “turbo launcher,” which was a little bit of software that loaded Firefox in memory so that it would be handy.  This is no longer included, but a third party built a “Firefox Preloader,” which for all intents and purposes is the same thing.

The project is essentially dead, since prefetching made preloading less useful for XP and later versions of Windows.  However, it does work for the latest versions of Firefox, and it works quite well on Windows 2000.  The installer can be downloaded here:


It works by looking for “Firefox.exe” and then loading it into memory.  Next time firefox.exe is launched, nearly everything it needs is already in memory instead of loaded from disk.  Prefetching makes this nearly pointless on XP, but the speed difference on an old Win2k box is stunning — assuming you actually have enough RAM to leave Firefox constantly in memory.