VMware Communities
Nazgulled
Contributor
Contributor

Arch Linux Guest Crashes/Freezes Windows Vista Host - PLEASE HELP!

Hi,

I just installed Arch Linux in VMware Workstation 6.5 and after the first boot just right after the installation (meaning, nothing else but the base system was installed/configured) I can barely use the virtual machien without having the host freezing. I'm just there, in the console and it freezes everything without me doing nothing. Most of the times, I just type "reboot" and it freezes the host machine. Other times, I could type other things, like "ls", or "cd <dir>" and then "cd ..", and after a few seconds, boom, host freezes.

By freezes I mean I have to press the power off button for a few seconds to turn off the computer and reboot (laptop, no reset button).

I've been searching google for the past hours and couldn't find the cause and/or solution for the problem, this is driving me nuts. I installed VirtualBox just to test if the same thing happened and it didn't, it works fine on VirtualBox, but due to other issues, I can't swap to VirtualBox at the moment.

Please, somone, help me out fix this issue in VMware, I can't understand why it crashes the host system, there's no reason for that to happen...

Message was edited by: oreeh

Reason: removed the emoticon from the subject

Oliver Reeh

VMware Communities User Moderator

Reply
0 Kudos
69 Replies
Nazgulled
Contributor
Contributor

The symbols are set up fine, that error about not finding symbols for netw2v32.sys is occurring because it is not a Microsoft driver (it's from Intel) and as such the debugging symbols for it can't be found on the Microsoft Symbol Server. Bottomline, is it can be safely ignored.

Ok Smiley Happy

I'm looking at your newest attached files, and this is absolutely, positively, definitely networking related. The stack trace for the two threads engaged in the deadlock are entirely full of networking system calls. You should be looking into ensuring everything networking related is updated to the latest versions, direct from manufacturer if LG can't provide recent drivers. So, ensure all Windows Updates are applied, and all networking equipment is running the latest drivers. Number one on the list to check should be Intel networking drivers.

Like I said, as far as I know, all drivers are updated to their latest versions. And I just opened up the laptop and it's written Intel 2200BG on the network card. But are you sure this problem is related to the wireless network card? Couldn't be the ethernet card for instance?

Also, all Windows Updates are applied...

EDIT:

I should point out, there is the (very unlikely) possibility this isn't even related to your VMware problem. There's no doubt that there are some very badly behaving drivers on your system, but that doesn't mean that these are the ones causing the VMware problem. Regardless, you won't know until you fix this particular problem Smiley Wink

Yeah, I know...

Attached is the log from a full dump.

Reply
0 Kudos
Nazgulled
Contributor
Contributor

One thing though... Shouldn't this problem be gone if I uninstall all NIC's drivers and/or disable the NIC's?

Reply
0 Kudos
ralish
Enthusiast
Enthusiast

If you uninstall all the NIC drivers, then yes, it should be gone, but you'd obviously lose all networking functionality. I'd be less certain disabling them would do so. Of course, if you do either, and you continue to get similar crash dumps, you know they aren't properly disabled.

Looking at your crash dump, close to everything is related to networking, most importantly in the deadlock analysis. The references to NDIS are to do with Windows internal networking API, which network drivers will be interfacing with. I'm unfamiliar with NWIFI, but I would assume it's wireless related extensions to NDIS. Both are Microsoft system files, and are as a result far less likely culprits. Experience with kernel crashes over the years has taught me that faults in Microsoft drivers core to the OS are very rare; a 3rd party driver is responsible the vast majority of the time.

NETw2v32 is an Intel networking driver that appears to be wireless related (from a quick google search), and is featured prominently across the crash dump analysis. I'd place my bets that it's the culprit, but it's all but certain this is networking related.

Your idea about getting rid of the networking drivers sounds like a good one to me, quicker than hunting down and installing updated drivers. So, give it a shot. If the system is stable and VMware works, you've found your culprit, if you get a crash dump, then we'll have to take a look at the crash dump... Smiley Happy

Reply
0 Kudos
ralish
Enthusiast
Enthusiast

If you find the actual driver on your system, it should be in %systemroot%\system32\drivers or possibly %systemroot%\system32, right click on it, choose properties, and go to the details tab. You may find some descriptive information that'll help to identify what precisely the driver is responsible for.

Alternatively, open Device Manager, go to the properties of the network adapters on your system, and check which files/drivers are associated with each adapter in the device properties. You should be able to establish which network adapter(s) are using the driver we're interested in.

Reply
0 Kudos
Nazgulled
Contributor
Contributor

Your idea about getting rid of the networking drivers sounds like a good one to me, quicker than hunting down and installing updated drivers. So, give it a shot. If the system is stable and VMware works, you've found your culprit, if you get a crash dump, then we'll have to take a look at the crash dump... Smiley Happy

The idea is to prevent the BSoD (with Driver Identifier activated) at startup to see if I can at least run VMware and do more resting... Cause I think I've disabled this in the past, uninstalled everything and VMware still freezed. If the VMware freezes come from other place, I want to debug that instead. The kernel may have a problem with the driver and cause a BSoD with DV enabled, but the network has been running fine since ever.

Dunno if it matters, but see the image attached please.

Reply
0 Kudos
ralish
Enthusiast
Enthusiast

Well, you definitely know what device that driver is associated with. Rather than uninstall the driver, it may be easier to just disable coverage of it in driver verifier. Choose to manually select which drivers to verify, and select everything but that driver.

Reply
0 Kudos
Nazgulled
Contributor
Contributor

Well, you definitely know what device that driver is associated with. Rather than uninstall the driver, it may be easier to just disable coverage of it in driver verifier. Choose to manually select which drivers to verify, and select everything but that driver.

I actuall uninstalled the drivers and all associated software and when Windows found new hardware, it installed some "default" drivers for my card, which don't produce the startup BSoD.

Now I can properly debug VMware...

The freezes I'm having in VMware only happened, so far, after booting the virtual machine, logging in into the console and starting to type something would eventually make the machine freeze. At the moment, running Driver Verifier, it produces a BSoD as soon as the virtual machine starts to boot... I don't even see the VMware virtual machine BIOS, it just crashes. I'm te process of analysing the crash dump right now...

Reply
0 Kudos
Nazgulled
Contributor
Contributor

To conclude this topic...

Ralish helped me to debug this thing properly in the IRC and his conclusion is that the problem lies on the VMware virtualization driver. There's nothing any of us could do more, this is a problem for the VMware support team to solve.

Since I have a student license from the "VMware Academic Program" and I can't contact VMware's technical support directly but I already sent an e-mail to my university's IT department.

Anyway, I'll create a new topic with a more proper subject than the current one explaining the issue, what ralish found and with some logs.

Thanks to everyone that tried to help out.

Reply
0 Kudos
ralish
Enthusiast
Enthusiast

Just for the record, I'm not saying conclusively this is VMware's problem, but we were able to repeatedly cause the machine to BSoD when powering on a virtual machine under VMware Workstation with Driver Verifier running.

A basic analysis of the crash dump consistently shows vmx86 driver calls in the stack trace immediately leading up to the crash, with the only other calls being low-level OS functions. The analysis does seem to point towards vmx86 being a likely culprit.

This may not be a fault with VMware's code but it's also plausible that it could be and may well be worth a look.

Disclaimer: I'm not a professional kernel debugger or even particularly experienced, this is just a best effort troubleshooting a difficult problem. If I'm completely wrong, I apologise to both Nazgulled and any VMware technician that might choose to take a look out of charity.

Reply
0 Kudos
Nazgulled
Contributor
Contributor

No need to apologize to me, you are just trying to help.

Which I'm very thankful for... Smiley Happy

Reply
0 Kudos