I found a new version of OpenCL (AMD APP, Stream SDK, whatever they want to call it) in a leaked version of a beta driver.  This driver supposedly gives Windows 8 support.  Anyway, I don't give a bleep about the driver, just the OpenCL versions.

On Catalyst 12.3 with OpenCL version "2.6" my DLL versions are:
amdocl(64).dll       10.0.831.4
opencl.dll             1.2.0.0

From this leaked driver the DLL versions are:
amdocl(64).dll       10.0.898.1
opencl.dll             1.2.1.0

Uninstalled version "2.6", deleted the DLL's manually in System32 and SysWOW64 (necessary step going between versions!), then installed this new leaked version.  Deleted my kernel bins in cgminer dir as usual, then launched...

Can't really see any change in performance.  Hopefully this gives ckolivas and the kernel devs something to chew on and progress forward, though.

Driver link:  http://jumbofiles.com/h2l4qczhjkb4
I will host just the 32 and 64bit versions of the OpenCL.msi myself for those who don't care about the whole driver:  http://www.delta9IT.com/OpenCL32.rar  http://www.delta9IT.com/OpenCL64.rar

Happened again after about 5 hours.  I have a couple 2 gig RAM rigs running cgminer just fine with 3 gpu's each... its the rigs that have 6 gpus each that it occurs on after 5ish hours..  No sign of trouble right now... after 2 hours running, I have 738Meg free out of 2 Gigs.  Full logs are located at:

http://pastebin.com/8MDeRMkD

Anyone have any ideas to help me troubleshoot whats happening?

Comes from Guru3d forums, which has been around for a long time. Sorry, forgot that link to close the loop on where this came from, here:  http://forums.guru3d.com/showthread.php?t=360108

No. That's a workaround for the diablo kernel when you're using it on a 2.6 SDK that performs terribly (like 25mhash) by default. The poclbm kernel is actually faster than diablo with -na so there is no point.

It's a crash in the driver or sdk code, therefore I can't do a thing about it apart from recommend a different driver version.

Yep you really have run out of ram. The only time I've seen cgminer itself waste lots of ram is when people have the submit-stale feature enabled and it caches lots of old work and keeps trying to submit them for extensive outages, creating more and more network threads since there is no upper limit to how long it will hold onto this work and try repeatedly to send them. I guess I should make them all time out and give up in a future version. I don't ever suggest using the submit-stale feature and I also recommend enabling the --net-delay feature. Why does the submit stale feature exist then? Because people asked for it. Nowadays it's redundant in my opinion.

Thanks... I don't use the submit-stale option...  When i start it uses about 174 meg of mem, then a couple hours later, its using closer to 400 meg

this is my start script

I'm not sure whats going on...

Neither am I. But I can recommend dropping intensity since 10 does not help anything less than a 7970 and consumes more CPU and makes hashrate more unstable. 7-9 depending on card is optimal.  There is a value, beyond which, the hashrate does not go up. 8 for most cards, 9 for 69x0s and 11 for 79x0s (only with export GPU_USE_SYNC_OBJECTS=1 on linux, otherwise again 9).

Your machines run out of memory.

You mentioned those are not dedicated mining rigs running web servers as well.
Just add a $12 memory module. As a stop gap, create a swap file.
Quest complete, you gain 200 experience points.