Hello.
I created a WIndows 2003 R2 image using VMware Workstation 6.5.5 build 328052. The host is Windows 7.
It was working fine, but now I am seeing Exception 0xc0000005 a while after I start the image.
I am attaching the dmp and log that VMware Workstation produced hoping someone can tell what might have gone wrong.
Thanks for any help.
Message was edited by: melahn: added vmx file also
I have did followings task for solved this problem:
1. uninstall vmware tools from control panel;
2. stop all vmware services, exit VMWare tools;
3. delete install directory, eg. c:\Program Files\Vmware;
4. open c:\windows\system32, delete all files of vmware, eg: vm*.dll, can identify by description of file; some files maybe can't be delete; go to 5
5. reboot system;
6. do 4 again;
7. install new vmware tools. or copy all files from vmware tools' install cd to c:\windows\temp, click setup.exe(setup64 for x64) to install. I select the last method.
8. reboot. the problem has been solved.
Regards,
Milton
@ Orthonin
did you look at the vmware.log ? - obviously not ...
Uninstalling vmware-tools is a rather strange tip here and in no way justified.
@ OP
somehowe the location where you stored your VM is no longer writeable to VMware Workstation.
Do you have an explanation for that ?
"C:\impact2012\Candidate_F\Impact2012.Lab2812_CandidateF.7z\Impact2012.Lab2812.vmdk" : Access is denied.
Tx for looking at the problem.
I see the access issue but I can't account for why the location is not accessible. I shutdown the virus scanner on the host thinking maybe it is contending for the file but no change. The error is very predictable now. If I start the VM, about ten minutes or so, it always reports this error.
Any ideas what I can look for?
@Orthohin
Tx for the suggestion. Before I take this step, do have an idea why VMware tools could be the source of the access issue? Have you seen it cause this kind of problem before because of VMware?
do you have configured exceptions for your Antivirus tools ?
when did you last run a checkdisk against the C: drive ?
does the same problem occur if you run the VM as administrator ?
Tx Ulli for your time,
I had my virus scanner turned off but I now have added an exception for the directory where the vmdk gives. Good idea to do that anyway.
I admit I have not run chkdsk on C: at all. It is a fairly new machine and I thought I was safe (famous last words). Perhaps there is a bad spot on the disk so I will run chkdsk.
One simple test that I did just try was to copy the vmdk on which I am seeing this error to a external USB and run it from there. It is running ok from the USB. That is consistent with a problem on the host disk, though other explanations are possible.
I will try to run as admin as my next test.
I will post what I find.
tx Greg
Ulli,
An update on what I have tried so far.
I added the location of the vmdk to the exception list for virus scanning.
I ran VMware as Administrator.
I ran CHKDSK /F on both the host and guest.
But I still see the same issue.
Open to any ideas. tx!
> Insufficient permissions to access the file (115).
please right click the file and check its properties - maybe the folder it is stored in uses some strange permissions ?
I just checked the file and parent folder permissions and did not see anything diffent from other files and folders. While I was there I also tried to disable indexing but still see the same error. Puzzling.
The thing that is very strange about this problem is that I can xcopy the vmdk and other files for the image into another location on the host disk or to a attached USB disk, and start the image from there and it works fine. Even though the result of the xcopy is a working image for me, I would really like to know what the underlying problem is with the original image. It smells like an issue with the spot on the host disk that the first vmdk landed on, but, after six hours of running, CHKDSK says the whole disk is OK. Any other ideas of things to look at are appreciated. Tx!
I have an interesting observation to make. Given the problem was related to a specific instance of the vmdk on disk, and chkdsk showed no errors, I thought I would look at the fragmentation state of the host disk. Indeed the host disk was fragmented. So, first I again validated the problem existed with one particular instance of the vmdk on disk. With that instance the exception occured 100% of the time on many attempts (> 50). The vmdk itself is 22 GB in size. The failure occurrs at different specific times around ten minutes into the startup sequence of nine Windows services in the guest. Then I defragged the host disk overnight. Then I started the VM with that same vmdk and the problem does not occur at all any more (so far more than >10 attempts but now I am getting tired of running it).
Is it possible there is a problem in VMware 6.5 related to a large vmdk stored on a fragmented disk?
Other explanations are possible (like a timing related bug in one of the Windows services I am starting that happens to be affected by the defrag).
But I would be interested in hearing if anyone else has encountered issues related to fragmentation.
Thanks for posting that.
Does not Windows 7 has a autodefrag-tool that can run in the background ? Maybe that is responsible.
WS 6.5 itself does not care wether a VMDK is very fragmented - the perforance of that VM will go down but it will run on.
Yes, I was also starting to think that maybe the defrag tool was running when the error first appeared, but I looked at the scheduler and it says that defrag happens on Wednesdays at 01:00 AM, and this error first appeared on Sunday morning, and then never went away.
Having altered the timing (because of improved disk performance) maybe I had exposed a bug in one of the Windows services in the Windows guest. The app logs I looked at showed failures at different points though.
I know that VMware Workstation 6.5 shouldn't be sensitive to the fragmentation state of the vmdk, but I suppose it may also be possible it exposed a bug in VMware?
@orthonin, you're a life-saver!
I followed the exact same steps as you indicated, with two minor changes, to resolve Exception 0xc0000005 (access violation) in a Windows 10 VM guest running on a VMware Fusion 11.5.1 host on a MacOS Catalina machine in January of 2020:
Steps I followed:
1. uninstall vmware tools from control panel;
2. reboot
3. delete install directory, eg. c:\Program Files\Vmware;
4. open c:\windows\system32, delete all files of vmware, (every vm* that showed "VMware" as the publisher on mouse-over). All file deletion attempts succeeded in my case, making your step #6 unnecessary for me.
5. reboot system;
6. copy all files from vmware tools' install cd to c:\temp, click setup.exe(setup64 for x64) to install.
7. reboot. the problem has been solved.
Upon final reboot, I found my friendly VM icon in the system tray and knew I'd overcome the "access violation."
Thank you so much, Milton, for taking the time to share what worked for you! I'd spent hours across several days, chasing VMware.log files I couldn't find, running vm-support.vbs scripts that seemingly ran forever and never reported the directory where they dropped their output and trying to decipher tips in other threads that lead to blind alleys.
@IlDavo and @orthohin, thanks very much for this.
I was having similar problems with a Windows 10 VM guest on VMware Fusion 12.0.0 on MacOS Catalina 10.15.7. It seems that it was a video driver DLL hanging around from previous VMware Tools installations. Following @IlDavo's procedure sorted it out and now everything is working properly.
VMware Workstation 16 - Cannot launch Server 2016 VM - Spiceworks
Same here. Could it be it thinks the ISO is in use??