FireWall-1 FAQ: user32.dll Problems
Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.
I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.
If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)
I am running FW-1 3.0b enterprise with VPN and patch 3055 on an HP LH PRO NT box with 128Mb Ram and a 200Pro processor. Every week I have to reboot. I get an error like “user32.dll failed “.
You will need to implement the registry hacks documented in Microsoft Tech Notes Q142676 and/or Q184802. Here is some background information on these hacks that I got from Check Point Technical Support:
NT only supports 48 megs of memory for desktop heap (i.e. background processes). By default, each background process takes up 3 megabytes, which means 16 background processes would fill up that heap space. By reducing the heap size for each process to 512k (as the tech note suggests), more processes can potentially be created (96 versus 16). However, problems can still occur if ~96 background processes get created and/or one of those processes has a memory leak. The easiest way to see if you have a memory leak is to start up the Performance Monitor and watch the parameter “page pool memory.” If that number steadily increases, you have a memory leak somewhere. Stop services until the page pool memory stops increasing.
One way to insure this problem does not occur is to make sure you are running the latest versions of all your drivers, services, and service packs.
If the registry hack does not work for you, Yinal Ozkan suggests the following:
In my case I discovered that the bug was with the “Alert” on track field of Rulebase (Instead of long,short…) Because it consumes windows resources and fills the event log until the machine crashes.