I have this same problem, the server hosts 4 VMs but only one of the machines suffers from this problem.
they are all the same OS build and patch level, just the application that it runs is different.
I submitted logs a while back and I expect it will be fixed in beta 2 although I've not seen anything definite to say this will be the case.
until Beta 2 turns up I have resorted to pinging the guest and if it doesnt respond, the restart the VMWareHostd service on the host which will bring the guest back online again (providing the machine is set to autostart)
unfortunately it would also restart any other guests on that host so its not ideal if you have multiple guests.
if I could have got the Perl API working then I hopefully could have scripted just a start of that guest again instead of taking the drastic measure of restarting the hostd service.
I searched high and low, and was thinking I was the only one seeing this.ve now got 2 VM's running on the host, so I'll see if it affects just the one guest or both. I'm considering going back to 1.05 or even the M$ solution since there hasn't been any patches or releases since November on beta 2.
just a thought althought it might be just coincidence.
when I mentioned about the script I wrote to ping the guest and restart the server on the host if the ping wasnt responsive.
I just realised that the guest hasnt had the mmuInfo.c crash since I started that scheduled task to ping it.
also noticed prior to the script being there, that the server usually crashed when it was idle.
and now this doesnt happen, it makes me wonder whether this simple ping is stopping it from crashing. its certainly made a noticeable difference for me since I dont have to go and check/restart the VM regularly any more.
hopefully it will help you but as I said, this might all be just coincidence.