Before updateting to 10.7.4 everything was right.
After updating launching Fusion causes almost always a Kernel Panic.
Aha! That is precisely what I had expected, but I was unsure if AHT would find it, and it could have otherwise been difficult to prove. I haven't had much luck using AHT to find memory errors, but this time it hit the mark.
Here's the full explanation: The least-significant bit of memory location 0x61808b is defective and doesn't reliably hold a "zero" value. It is in a memory area used to hold the Mac OS kernel – the core instructions to run your Mac. The Mac OS kernel changes with each update in such a way that each new version's kernel may use a given piece of memory for a different purpose. Sometimes the defective area might have been used rarely or not at all, or sometimes it might be some critical part of the kernel (in which case your system would probably not be bootable or would crash at entirely random times). For the Mac OS 10.7.4 32-bit kernel, it falls within the part of the kernel that is responsible for loading a new Kernel Extension (kext), which is exactly what Fusion needs to do when it's launching... that's why Fusion triggers the crash, even though Fusion itself is not doing anything wrong. The defective piece of memory causes a simple request to copy 8 bytes of memory to be mutated into a request to copy 65544 (0x10008) bytes from a region which doesn't have that much data, which then causes the kernel panic you've seen.
You can actually see the evidence in each of the panic logs (if you know where to look ):
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
[...]
0xdfbd28 : 0x618093 (0xcb4cb20 0xdfbd50 0x10008 0x609339)
The second entry there is the return address, which roughly indicates what the CPU was doing a moment ago. The value 0x618093 means that the CPU has very recently executed code from the defective location in memory! The third "potential argument" inside the parentheses should always be 8 here, but it is 0x10008 – a one-bit error that would only occur consistently if there was a hardware fault or kernel memory corruption in the code that it had just executed, at address 0x61808b. The rest of the system state and panic log info are explained neatly by that one-bit error, and the crash has the same signature in every one of the panic logs you provided.
For Mac OS 10.7.3, the defective memory location was only used by the kernel once, very early in boot; likewise for Mac OS 10.7.2. So, it looks like earlier versions were unaffected simply because at the time it was used, its value may have still been correct. Or you were just very lucky. Or maybe the memory just happened to start failing at the same time as you installed the 10.7.4 update... And no-one knows what would happen when you update to Mac OS 10.7.5.
Either way, I agree that new memory modules will almost certainly lead to a happy Mac and hopefully a happy Fusion user again. :smileycool:
Cheers,
--
Darius
Panic logs? They're somewhere like /Library/Logs/PanicReporter (note this is the system library, not the one in your home folder).
Hi Koi!
bye.
Hi P@olo,
Thanks for posting those panic reports... they are exactly what we needed. It's a very strange panic, that's for sure, and it's going to require a bit more investigation before I can understand what's happening.
My first thought is that it looks quite different from the panic discussed in that other thread. Does Fusion ever crash on the first time you launch it, or does it only crash if you quit Fusion and relaunch it again? The kernel panic on 2012-05-11-180439 seems to have occurred as Fusion was being launched for the first time, but I don't fully trust that panic log.
Cheers,
--
Darius
Hi there Darius,
I am nor P@olo, but I got this message you wrote to him. I assume it was because a few hours ago I sent it a question about the same thing. Hereare some more details:
1. I click on the VMware Fusion to start it up, then a small window opens up with the following message: Unable to retrieve kernel zone sizes.
2. I click on OK and get the following message: Failed to initialize monitor device.
3. So then I click on OK again and I get this: Cannot find a valid peer process to connect to
4. Then I click again on OK and get nothing more except the black screen with the big white arrow. If I click on the big white arrow, I get the same series of answers as in 1, 2 and 3.
I have not attepted to get into Windows in quite a while, so I cannot tell you whether there is a pattern or not. The only thing I can tell you is that a couple of days ago, I received and installed an important Apple update for my OS (Lion).
I have never had this problem before (crashing) and, as I mentioned in my first message, it isn't as if I do not have Windows installed. It's all there, but, of course, cannot open.
Emile
Hello Darius,
I just sent you a comment about this problem. But I forgot to mention that I have the most up to date version 3.x.x NOT the 4.x.x
Emile
I too am having the same issue... I also have the most up to date version 3.x.x. Any idea what to do to restore my VM? I'm attempting to run Win XP Pro.
Nevermind... I had 3.1.3. After upgrading to 3.1.4 everything worked fine.
Hi Emile,
Are you sure you have the latest version? Fusion 3.1.4 was released a few weeks ago, and it specifically fixes a problem powering on VMs with Lion 10.7.4 hosts, where the exact error message is "Unable to retrieve kernel zone sizes". Please check that you have Fusion 3.1.4 installed.
Thanks,
--
Darius
Yes, that is the versión i downloaded and instales. Thanks again.
Hi!
I experienced a new Panic! This time, after a reboot of my MacBook I launch Fusion and it opens a suspended VM window: as soon as I click on PLAY the OS crashes!
Here there is the complete report that Lion is going to send to Apple, and attached you can find the panic file:
Hi P@olo,
Thanks for that update. I am a bit unclear on one thing: Does Fusion really crash every time you try to use it after the 10.7.4 upgrade (as you mentioned in the thread title), or can you still sometimes use it? One of your earlier comments gave me the impression that it might still be working occasionally, but I'd like to double-check rather than make an incorrect assumption, as it's a crucial factor in determining where the problem is.
Thanks for your patience,
--
Darius
Hi again P@olo,
OK, that's good to know.
Could I ask you to temporarily move your Iomega eGo external hard drive to use the USB connector instead of Firewire, or disconnect the drive from the host computer completely if you don't need it connected all the time? It is possible that the Firewire device or the host's Firewire port is causing the problem... I'd consider it unlikely, to be honest, but we should try to eliminate the possibility if we can.
Thanks again for your patience. Your answers are helping us to steadily move forwards in solving this mystery. :smileycool:
Cheers,
--
Darius
Thanks for doing that experiment, P@olo. I guess you can move the drive back to the Firewire port again now that we know that it did not affect the problem.
Next step: Could you please follow these instructions to run Apple Hardware Test on your MacBook and see if that reports any errors? At this point, I suspect that one of the memory modules in your MacBook is defective. It's still possible that it's a software problem, but the panic reports you have provided indicate a very specific failure that I have not seen anywhere else, so at this point it would seem most likely to be a hardware problem unique to your MacBook.
The nature of the failure is such that an AHT (Apple Hardware Test) failure might indicate that a hardware problem exists, but an AHT pass will not necessarily prove that the system is OK... it might require many runs of AHT (and perhaps a different, more intensive memory test) to rule out defective RAM as the cause.
Hopefully the document I linked above will explain the AHT process, but do feel free to ask if there's anything you're not sure about.
Cheers,
--
Darius