Yeah I found it at the end: Desktop Heap
There is a form of limit in Windows that affects the NT family of systems - usually referred to as the "desktop heap". Hitting the limit is manifested as either a DLL initilization error for USER32.dll or an out of memory error. Fortunately, the limit it tweakable (after NT 4 Service Pack 2 at least), but the default settings are low enough that the limit is easily hit.
To tweak the limit, take a look in the registry at HLKM/System/CurrentControlSet/Control/Session Manager/SubSystems - there is a key called "Windows" that contains (among other things) "SharedSection=1024,3072". Changing the SharedSection entry to "1024,3072,512" increases the size of the "hidden" desktop heap. If that doesn't work, try increasing the second of the comma delimited values (e.g. 3072 -> 4096), which is the size limit of any particular desktop heap.
I'm not sure if this is the limit the poster of this Ask Slashdot is hitting, but I do know that we have problems with this particular limit at work. We run an interpreted language/database/remote development environment, including customer applications as Windows Services. After stopping and starting the service multiple times, we get a USER32.DLL error for one or more of the executables running under that service - the only resolution is to reboot the machine, even after applying the aforementioned registry tweaks.