Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a Windows 2008 R2 X64 server running on Vmware ESXi. Originally it was running on Hyper-V, but I have since converted the VHD to a VMDK and migrated to ESXi. I also installed VMware Tools. This server is our TeamCity continuous integration server, performing nightly builds of software packages that my company develops. Since the move, occasionally certain files that the build process should delete fail to delete due to "The file is in use by another process". We are trying to delete the files using the CMD del command. Sometimes it works, others not. I fired up process monitor with the path of the directory where failures occur as the PATH filter (PATH contains C:\work ). I see a LOT of vmtoolsd.exe Createfile, FileSystemControl, and CloseFile operations occurring in quick succession, repeatedly. Has anyone heard of Vmware tools causing filesystem locks on Windows guests?

I have not been able to capture it with procmon when it actually happens yet, but I plan to try.

Also, due to running out of space, this directory C:\work, was recreated by renaming it to C:\work-old, adding a second virtual disk E:\, and mounting the disk to the directory C:\work , then copying the contents of C:\work-old to the newly mounted C:\work. I see Vmware Tools is constantly performing FSCTL_Get_Reparse_Point on C:\work.

UPDATE: I disabled the VMware tools service last night and it still happened. I believe the C:\work directory, which is a share that is actually the E: drive mounted as a directory to C:\work is being accessed by 2 remote hosts simultaneously and perhaps this is causing a lock on the directory by the first host. This did not used to happen before I mounted the E: to the work directory,, Are there any known issues with file locking and volumes mounted as directories?

share|improve this question
1. Instead of "redirecting" C:\work why not expand the VMDK and extend the C: volume in Windows? 2. Do you have the Shared Folders component of VMware Tools installed? If so, try removing it. 3. Are you running any type of backup during the hours that the locks occur, such as a VM level backup? –  joeqwerty May 21 '13 at 21:05
Shared folders does not exist under ESXi to my knowledge, I think that is only for the Workstation/Desktop version. I had Crashplan installed for backups and removed it completely due to this issue, but it still happens. –  user160910 May 21 '13 at 21:25
If you select a custom install of VMware Tools and expand the VMCI Driver node you'll find the Shared Folders component. It used to be installed by default when selecting a default install of VMware tools. If it is installed then my guess is that may be causing your issue. I've seen it cause a variety of file system issues in Windows VM's. –  joeqwerty May 21 '13 at 21:32

1 Answer 1

up vote 0 down vote accepted

It turns out that the problem was not caused by VMware Tools. It is more likely that the windows Application Experience service caused this issue, but I am not positive. I ultimately resolved the issue by adding a virtual disk and creating a new share, then pointing the build to look to this share. If the build step leaves an open handle for this share, it wont affect the subsequent step which does not refer to that share again (previously everything was done from the same share, so if there was an open handle, file operations would fail).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.