This effectively prevents you from collecting dumps from your Windows 7 virtual machines. This problem has been purportedly addressed23 in VMWare Workstation 7.0 so you can buy your way out of it. For the rest of you, there are two choices
- find physical machines and dust off your Ghost CD and plan your serial/firewire connections while reminiscing how things used to be in pre-VMWare era.
- connect debugger to the virtual machine and do the dumping over your debugging connection (which can take a day if you are on serial connection)
Happy 2010 everyone !
1Note that complete and kernel memory dumps are overwritten by the most recent one. So by default, one will have one of either, on a Windows 7 machine if the retention policy were not to exist. What could be gained by not retaining the dump file by default, is not very clear, especially since storage is cheap and getting cheaper – you can get 1TB HDD under $100 these days. OTOH, it is in general a good thing to give administrators the control over things like how many minidumps will be stored. The default retention policy for kernel and full memory dumps, makes it hard and tricky to get information from customer machines if one needs to. It is a classic case of “solutions” creating problems where none existed before.
2This will probably be the primary reason for upgrading to VMWare 7.0. I would hazard a guess that VMWare had ample time to address this and they could have done so in 6.5.3 if they wished. I could not find any information at VMWare support regarding Windows 7 dump time hang behaviour.
3In my experience with VMWare 7.0.0 build 203739 dumping does not hang like it used to in Windows 7 VMs, but the boot right after dumping hangs. However if the VM is rebooted again, there is a memory.dmp file to look at.
- 1 2