GoogleCrashHandler64 process causes 64-bit Virtualbox VMs to throw a "HostMemoryLow" error about omaha HOT 12 CLOSED

Just to add, this is dependent on the memory assigned to the VM. For example, 
on my 8Gb Windows 7 host running only Outlook, a browser or two and VirtualBox: 
a 3Gb VM works OK but a 3.5Gb VM will report the HostMemoryLow problem within a 
few minutes of using it. As reported above, killing GoogleCrashHandler64 (or 
turning off "Automatically send usage statistics and crash reports to Google" 
in Chrome) resolves the issue.

Managed to get a repro on my end, but I'm not sure that this is a bug in the 
crash handler.  The tail from the VBox log reads:

00:01:14.394 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY 
rcAlloc=VINF_SUCCESS rcSeed=VINF_SUCCESS cHandyPages=0x8
00:01:14.394      cAllPages=0x104447 cPrivatePages=0xdedb9 cSharedPages=0x0 
cZeroPages=0x25669
00:01:14.394 GMM: Statistics:
00:01:14.394      Allocated pages: da9bd
00:01:14.394      Maximum   pages: 10009e
00:01:14.394      Ballooned pages: 0
00:01:14.395 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY 
rcAlloc=VINF_SUCCESS rcSeed=VINF_SUCCESS cHandyPages=0x7
00:01:14.395      cAllPages=0x104447 cPrivatePages=0xdedba cSharedPages=0x0 
cZeroPages=0x25668
00:01:14.395 GMM: Statistics:
00:01:14.395      Allocated pages: da9bd
00:01:14.395      Maximum   pages: 10009e
00:01:14.395      Ballooned pages: 0

It sounds like VBox is having more generic problems with acquiring large memory 
blocks.  No record of any attachments or other activity from the crash handler 
while it's running, and memory usage by the crash handler is staying steady at 
around 2MB.

I'll experiment a bit and see if I can figure out what's going on, but I 
suspect that this is a bug in VBox.

Found the root cause.  This will be fixed in .111.

Good work and prompt response as always Ryan, many thanks!
So not a VBox issue then? Care to divulge? ;)

It wasn't a VBox issue.

We had a bug (an unintended typecast) in a routine calling 
SetProcessWorkingSetSize() which caused us to request more working set than 
actually needed.  Windows largely ignores that setting with respect to normal 
memory allocation, so the vast majority of programs out there weren't affected.

However, for processes such as VM hosts that need to lock big chunks of memory, 
there is contention for working set, as calling SPWSS() is a prerequisite to 
calling VirtualLock() and Windows hands it out first-come-first-serve.

Thanks Ryan. .111 close on the horizon then? I'm just wondering as we use 
VMWare workstation at work, and I'm guessing it too might suffer the same 
problem.  Thanks.

Probably end of March at the latest.

[deleted comment]

[deleted comment]

Fixed on Google Chrome 19.0.1077.3 dev-m Windows 7 Pro SP1 x64.

Today Chrome's update module has been updated to version 1.3.21.111. An issue 
has been solved for me, VMware Player 4.0.2 is able to allocate 3072 MB RAM 
memory to virtual guest machine.

.111 works a charm, thanks Ryan!