@ [B.S] sTrey: My similar problem was caused by the model of the HDD on which I had the BOINC data. Replacing the drive by an older, slower one that has a smaller onboard cache has solved the problem. I can now run 4 simultaneous CEP2 WUs reasonably happily with 2GB RAM under XP-32. With 4 CEP2s there is much activity on the BOINC data drive, and almost none detectable on the drive with the system & pagefile, and there are many brief instances where CPU usage drops during the HDD activity. No WUs have been "Bogart"ed since I changed the drive. I prefer to run 1 CEP2 WU and 3 WUs from other projects, because much less CPU time is lost by the dropouts.
More details in my posts in work units not finishing .

No compatibility issues with motherboard: Asus P5Q Deluxe - LGA775, with Intel P45 chipset including ICH10 Southbridge, using the ICH10 SATA controller in either IDE or AHCI Mode. The WD "Caviar Green" drive is a regular SATA II unit. It is meant to be an "internal" drive, but it's actually "external" because it & the rest of the machine are sitting out on a table.
The WD drive seemed to freeze the system for longer and to a much greater extent than the IDE units. For example, with the WD, the menu bar of the BOINC Manager window would white out when I tried to access it, but this window remains quite responsive during periods of intense HDD activity with the IDE drives. I think the WD drive was also preventing the WCG science apps from running enough to send their heartbeat signals back to BOINC, so they timed out & were killed.
I'd need more expertise and diagnostic tools to analyse what is happening at the detailed hardware level. I just know that 2 different IDE drives with smaller caches have solved the problem. (The "other" IDE drive was the current 8.4GB Seagate system drive, which fixed the problem when it held the BOINC data to run DDDT2, but which is too small for CEP2). Please see my posts in Legrandpiou's work units not finishing thread.

The start-up of a CEP2 workunit involves unzipping a bunch of files. This is a VERY IO intensive process. On some machines under some conditions, this will likely cause the research application to be non-responsive to heartbeat messages. I am assuming that BOINC decides that CEP2 isn't responding and thus kills it. If the IO is still heavy and the other applications that are loaded into memory (LAIM) have been swapped out, then we are going to see the same effect there because the apps are unable to get loaded back in memory before they are killed for being unresponsive.

To test this, can you do the following:

Create the cc_config.xml file outlined here: http://boinc.berkeley.edu/wiki/Client_configuration

Enable the following flags:

<cpu_sched>
<cpu_sched_debug>

It will look like:

<cc_config>
<log_flags>
<cpu_sched>1</cpu_sched>
<cpu_sched_debug>1</cpu_sched_debug>
</log_flags>
<options>
</options>
</cc_config>

@knreed: Thanks for your input. In my case, I don't think the WUs that died were swapped out, so LAIM is irrelevant. It was often not just the 1 CEP2 WU that died, but 2 of the 3 FAAH ones, and often the CEP2 survived. In Task Mangler Processes, what usually happened is that when the HDD LED came on & the system froze, the CEP2 went to low/zero %CPU, but the FAAHs stayed at 25% for a little while and then they too dropped to 0% one at a time. The FAAHs may have been continuing until they needed to do disk I/O, encountered the hangup, timed out & were killed. I didn't set the cpu-logging flags to confirm.
It's been several days since I changed the BOINC data HDD and there have been no WU crashes since. I am reluctant to put the previous HDD back on line.

Did you see my enquiry/suggestion in work units not finishing re introducing short delays in the "VERY IO intensive" part(s) of CEP2 to allow slow HDDs to catch up in an attempt to alleviate the timeouts problem?
I've also noticed on a machine that has never had CEP2 cause a timeout that it is very slow at opening extra programs while CEP2 is doing this I/O, so diluting the intensity of the I/O would probably also help reduce the impact of running CEP2 on machines that are being used for tasks other than WCG, over a much wider range than just those with slow HDDs.
The overall gain in system performance and perhaps in cruncher numbers should more than compensate for the few tens of seconds increase in wall-clock time for CEP2 WUs.

I don't know how you'd implement the delays to suit all machines. Are there any spare "User" parameters in cc_config.xml that you could use to make the delays tunable?

[I have no self-interst in promoting WD, but the WD Caviar Green 500GB WD5000AADS drive is still a current product and is very cheap, if you want to experiment in-house. Its stated Idle power consumption of only 2.18W is incredible for a mechanical HDD, but the downside is poor performance for demanding applications.]
HTH - Rick