ralish's Posts

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.

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.

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...

You misinterpret me 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. 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. 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

Although I wouldn't call the crash dump in anyway conclusive, it is beginning to point at the NETw2v32.sys driver, which is a Intel wireless networking driver. Updating it shouldn't do any harm, and is certainly worth a shot. You said that LG themselves hadn't provided any driver updates, so I'd suggest just getting it direct from Intel, which shouldn't cause any problems, the wireless chipset will be straight from Intel anyway. http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=1847&lang=eng -< Download link for Intel® PRO/Wireless 2915ABG Network Connection which is what I believe your laptop has judging from some specs I pulled off the web.

Hello again, Looking at what you pasted: "BugCheck C4, {1001, 9f876ff8, 8f391330, 0}" -> DRIVER_VERIFIER_DETECTED_VIOLATION -> http://msdn.microsoft.com/en-us/library/ms796113.aspx A 0xC4 bugcheck is a Driver Verifier specific bugcheck that only occurrs when DV is active and detects a violation in kernel mode, which confirms my suspicions, something is going badly wrong in kernel mode. Looking at the handy provided table, the first parameter (0x1001) indicates that this bugcheck is specific to kernel deadlocks, which makes a lot of sense, as a deadlock occurs when two actions are waiting for each other to finish, and thus, neither ever does (this is all a simplification). You can pretty easily understand how this can translate to a complete system lockup when this happens in the kernel. This is also exactly what you are witnessing, which suggests we are definitely looking in the right direction. The second parameter (0x9f876ff8) points to the memory address of the resource that was the final cause of the deadlock. The third and fourth parameters are apparently reserved, meaning they're not in use, despite the fact the 3rd parameter in your data has a value, which might suggest the documentation is out of date or the parameter is undocumented. I would try running a !deadlock and "!deadlock 1" respectively on your crash dump in WinDbg and paste the results here. The NETw2v32.sys error can be ignored, this is an Intel networking driver, and as such, the debugging symbols for it can't be pulled from the MS Symbol Server. I would suggest changing your dump file format to a complete memory dump as it is highly probably this exact same deadlock is what is the cause for all of your crashes, and having more data to work with may be useful. Finally, you should be running !analyze -v (for verbose output). Are you all the output is in your paste? It might have been trimmed by the forums?

Some additional notes: 1. Ensure you have correctly configured kernel memory dump settings, this can be done through the Advanced tab of the System applet in Control Panel. You want a kernel memory dump at a minimum, but if you have space to spare, feel free to go for a complete memory dump, which may yield more useful data. Keep in mind a complete memory dump will require a file dump equal to the size of your system RAM. 2. Each subsequent crash will overwrite the prior memory dump (if it exists). So, if as I suggest above, you are going to compare memory dumps, ensure you copy the previous one to a new location for safekeeping before the next crash if at all possible. 3. The manual initiation of a memory dump shouldn't apply to Driver Verifier. The whole point is for Driver Verifier to catch any illegal operation being performed in kernel mode if one is occuring, so, if a BSoD does not occur during reproduction while DV is enabled, it's unlikely in my view that a manually initiated memory dump will yield much more useful data than one without DV. However, it still won't do any harm taking a look regardless if a manual memory dump with DV is required.

Hello, A devoted Arch user who's a friend of mine pointed me to your post on the Arch forum (). I'm the VMware/Windows loving friend who gave you that apparently not so useful advice Coincidentally, I woke up this morning and remembered your problem and did a quick search, and find this moderately sized thread on the VMware forums by you, and I happen to have an account on these forums, so it's only decent that I try to offer some (better) advice! It's pretty rare to be in a situation where getting a BSoD is a better outcome than the results you're actually getting, and you seem to be in the latter category; at least with a BSoD you'd have some crash data to sift through that has a reasonable chance of leading you to the culprit. I've read the thread, and you seem to have tried all the basics and some of the more advanced stuff through the help of the VMware community. The way the system does a hard lock-up makes me think there is something going on in kernel mode that is definitely not good (even if whatever it is is being prompted by some mundane user-mode code). Further, you can't really even say that VMware code is the cause, but possibly merely the catalyst. Kernels are complex beasts, and misbehaving code from one completely unrelated module can have ramifications on other code that at first seems to have no links at all. Seeing as the machine is not blue-screening, I'd suggest trying to MAKE it bluescreen. Follow these instructions to prepare your system: Once completed, do a test to see if it works. If successful, I'd reproduce your VMware crash and see if you can force a memory dump using the above procedure. This, if it works, could provide valuable insight into exactly what is going on inside the kernel at the time of the freeze. It may be ambiguous at first, in which case, making several memory dumps and analyzing each, to see which similarities they have, particularly the last instructions on the stack, will help to determine if the code running before the crash is consistently similar or even identical. The driver responsible for calling the memory dump runs at a very high priority, so while the system may have frozen, elements of the system may still be responsive, even if they can't typically be interacted with directly by the user, which is why I'd hold some hope that this may work. If it doesn't, the next step may well be to run Driver Verifier: http://support.microsoft.com/kb/244617 I'd simply create standard settings when setting it up, reboot, and once again, try and reproduce the crash. This will enable a significant number of additional checks on kernel code. The result will be a significant performance penalty (which is why you shouldn't run Driver Verifier on production machines, but purely for debugging bad code), however, it may well catch the fault as a result. In fact, it may well catch the fault well before the system usually crashes. Note, that when if it catches a fault, it'll BSoD the system, however, you'll have a memory dump to analyze. This dump may well be more useful than prior dumps, as DV is likely to have caught what was going wrong at the precise time it happened, and not a memory dump of what was going on well after the damage had been done. In any cases, you'll need Debugging Tools for Windows (). You should setup WinDbg to use the Microsoft Symbol Server to pull down debugging information on-demand (). You can then open the crash dumps (typically saved in %SystemRoot%\MEMORY.DMP) in WinDbg and, once it's loaded them, run an !analyze -v to perform a thorough automated analysis, which will often reveal the culprit without any further forensics, which you don't want, as that takes a lot of time and skill. There are various guides out there that illustrate the basics of using WinDbg to analyze kernel memory dumps. While this may all sound very initimidating, a basic analysis of a kernel crash dump is not at all difficult to do, and is in fact mostly automated, requiring very little programming expertise, if any. Further, I think the data gleaned from it in your case may well be invaluable. Let us know how it goes, and attach any WinDbg analyses you make !http://communities.vmware.com/images/emoticons/happy.gif!

The guest operating system is set to "Other"; perhaps I should try with it set to "Windows NT"? You mention timing loops, and I was just going through a boot.ini options reference for a different and very interesting problem with another legacy OS (which I'll probably make a seperate post for soon!). I notice this option: /TIMERES= Sets the resolution of the system timer on the standard x86 multiprocessor HAL (Halmps.dll). The argument is a number interpreted in hundreds of nanoseconds, but the rate is set to the closest resolution the HAL supports that isn't larger than the one requested. The HAL supports the following resolutions: Hundreds of nanoseconds Milliseconds (ms) 9766 0.98 19532 2.00 39063 3.90 78125 7.80 The default resolution is 7.8 ms. The system timer resolution affects the resolution of waitable timers. Example: /TIMERES=21000 would set the timer to a resolution of 2.0 ms. Source: http://technet.microsoft.com/en-us/sysinternals/bb963892.aspx Would this be useful? I have no idea how to use it though, so if you have any suggestions about applicable values if it is relevant, I'd be interested. (Not to sidetrack away from my original request, which possibly has other useful applications outside of my problem)

Yes, I upgraded the virtual hardware revision purely as a matter of consistency, however, before I did so, I backed up all the virtual machines in case something went wrong. I have since tested the VM's concerned with the original VMW 6.0 revision and the problem persists. I apologise for not mentioning this earlier. Soon I shall see if making a brand new MS-DOS VM with only audio drivers makes a difference, as this may provide some useful leads.

I've made an interesting discovery: While playing with the Creative SB16 diagnose program, a program bundled with the drivers that you can use to set resources (IRQ/DMA/etc...), I've determined that 16-bit digitised sound seems to play fine, and only 8-bit digitised sound is distorted. Further, while setting the low DMA channel, I get some strange feedback through the speakers that I don't get when setting any other setting, including the high DMA channel. I get this feedback regardless of which channel I choose to use, of which there are only three: 0/1/2. The hardware and configuration in the VM has not changed since the sound did work apart from the upgrade to Workstation 6.5 and the virtual hardware being upgraded to 6.5 level. Any ideas?

Hello again, Problem still exists sadly, so nothing to report! After re-reading all the posts in this thread, it seems people are getting different "symptoms" from what appears to stem from the same problem, some issue with the VMware Authorisation Service. Just to clarify, the effect it has on my machine is VM's take a while longer to load (and by load, I mean open their tab, not running the virtual machine; starting the virtual machine will take a few seconds longer than usual, but once the BIOS comes up, the VM works as normal). So my specific problem is that opening VM tabs takes a while longer AND the Application Event Log is filled with access denied messages from the VM Auth Service as a result of opening and starting each VM. So yes, we seem to be having a variety of different problems, but it all seems to relate back to the VM Auth Service. So, uh, any more suggestions for us VMware people? -SDL

Peter_vm: Tried your suggestion, had no effect. The VMware Authorisation Service seems to start fine on this machine anyway. Regardless, I manually stopped it, waited a minute, then started it again; re-opened VMware Workstation and opened a VM, got the usual error in the Application Event Log. crote: I checked my Network Connects, and the VMware Bridge is enabled on all relevant network cards. The only NIC it's not enabled on (apart from the VMware Virtual NICs) is the 1394 Connection (which isn't used anyway). Further, I just uninstalled VMware Workstation 6.0.2 completely, then installed 6.0.3. The same exact problem still persists, despite the upgrade.

Thread is very much dead. Problem was "partially solved" by only installing a couple of Windows Updates out of the available pool at a time, rebooting, then installing another small batch. Repeat.