I am running Windows 8.1 Pro (Version 6.3.9600) on an HP-Z800 workstation. Yesterday, I noticed that my C:\Windows\System32 folder contains more than 64,000 0-byte temp files. A pair of these files gets created every five minutes. Here is the tail end of a directory listing (dir vmg*.tmp /o-d):
<snip>
10/31/2013 11:04 AM 0 vmgC7EC.tmp
10/31/2013 11:04 AM 0 vmgC7ED.tmp
10/31/2013 10:59 AM 0 vmg33EB.tmp
10/31/2013 10:59 AM 0 vmg33EA.tmp
10/31/2013 10:54 AM 0 vmg9FE8.tmp
10/31/2013 10:54 AM 0 vmg9FD8.tmp
64404 File(s) 0 bytes
0 Dir(s) 148,178,698,240 bytes free
Notice from the listing that the first of these files was created last Halloween, 10/31/2013, at 10:54 AM.
I had applied three Windows updates at 10:30 AM that day. I can imagine that it took 20 minutes to install the updates and reboot, so the appearance of the first file *may* correspond to the application of one of the updates. Here are the updates I installed:
Update for Windows 8.1 for x64-based Systems (KB2901549)
nVidia - Graphics Adapter WDDM1.1 ... Quadro 2000
nVidia - Graphics Adapter WDDM1.1 ... GeForce 210
Definition Update for Windows Defender KB2267602 (Definition 1.161.1146.0)
Initially I suspected that KB2901549 was responsible (http://support.microsoft.com/kb/2901549), but I didn't see anything in the details that obviously explains this behavior.
Next I fired up Process Monitor, and started watching that folder. The culprit emerged as vmms.exe, Microsoft's Virtual Machine Management Service.
During the period of time I captured events, I saw that vmms.exe did the following:
Creates the first temp file, vmg986C.tmp (Desired Access: Generic Read, Dis, ... OpenResult: Created)
Calls WriteFile in a loop (maybe around 62 times?) and writes content into vmg986C.tmp
Calls CloseFile on vmg986C.tmp
Opens (calls CreateFile) on C:\Windows\System32\vmguest.iso, and then closes it (Desired Access: Read Attributes, Dis, OpenResult: Opened)
Creates the second temp file (vmg989B.tmp) and then closes it (Desired Access: Generic Read, Dis, ... OpenResult: Created)
Calls CreateFile again on vmguest.iso, and the result is SHARING VIOLATION (Desired Access: Read Attributes, Delete, Synchronize, Dis)
Calls CreateFile on vmg986C.tmp, and then closes it (Desired Access: Read Attributes, Delete, ... OpenResult: Opened)
Calls CreateFile again on vmguest.iso, and the result is SUCCESS. Then vmguest.iso is closed (Desired Access: Read Attributes, ... OpenResult: Opened)
Calls CreateFile on a third file, vmg98AC.tmp, and then closes it (Desired Access: Generic Read, Dis, ... OpenResult: Created)
It again tries to open vmguest.iso, and the result is SHARING VIOLATION (Desired Access: Read Attributes, Delete, Synchronize, Dis, ...)
Next, Windows Defender notices the new files and does the following:
Calls CreateFile on the first file, the one with content, and the result is NAME NOT FOUND (Desired Access: Read Attributes, Dis)
Calls CreateFile on the second file, vmg989B.tmp, and then closes it (Desired Access: Read Attributes, Dis, ... OpenResult: Opened)
Calls CreateFile on the third file, vmg98AC.tmp, and then closes it (Desired Access: Read Attributes, Dis, ... OpenResult: Opened)
The result of all this is two new temp files, vmg989B.tmp and vmg98AC.tmp. I'm not sure when the first file was deleted. In five minutes there will be two more.
I use Hyper-V, with a Server 2012R2 guest VM that I use for development and testing. So it appears that vmms.exe being the culprit fits the facts.
This feels like a bug in vmms, rather than any kind of intentional or desired behavior. vmms.exe lives in C:\Windows\System32, so that could explain why the files are being written in that location.
Deleting the temp files is easy, and certainly I could write a script to clobber them every day, but I'd sure like to get to the root cause and prevent them from being created in the first place.
Has anybody encountered this before? Any suggestions for what to look at next?
Thanks in advance.
-Bruce Bauder
- Moved by Marvin_Guo Monday, May 12, 2014 2:13 AM Virtualization issue
Other recent topics
