I am trying to optimize a Windows 7 virtual machine disk image. The disk image is a sparsely-allocated image that grows as needed. By zeroing out the bytes in free disk space (in guest) that were left over from deleted files that used to occupy some of that space, I can tell the hypervisor to re-shrink the VM disk image.

To do so, I run the SDelete tool from the Windows SysInternals Suite, in guest:

sdelete -z c:

While running SDelete, when it said it was 99% complete, my virtual machine hung, completely unresponsive. After rebooting the VM, the guest's C: drive reports 98% used, with only 1.5 GiB space free.

I have tried searching in the usual locations (c:\Windows\Temp, %TEMP%, etc.) looking for regular and hidden files, with no luck.

Where does SDelete store the temporary file(s) it uses to gobble up free space and zero it? My hunch is that by deleting that file, I will see my free space plummet to an expected size of about 20 GiB.

If that file doesn't exist, how do I reclaim that space?

Edit: I am using SDelete v2.0.

  • ouch, this looks like a bad situation. I haven't used sdelete, but any data recovery program should use a DIFFERENT hard drive in order to have the best chances of recovery. If you use the same drive, then you risk overwriting the data and making it unrecoverable. With a machine image, the data is so sensitive, you are pretty much SOL (as opposed to a text file). p.s. I was not the downvoter Nov 1, 2016 at 4:10
  • 2
    @User91232 I'm not sure I follow. sdelete -z just gobbles up unallocated space and writes zeroes to it, by just creating a temp file, and increasingly adding to it until it can't anymore. My VM is fine otherwise (it runs). But because Sdelete didn't finish and clean up after itself, it still has a large file "claimed". I just can't seem to find where the file resides so I can delete the entry in the file table.
    – scottbb
    Nov 1, 2016 at 4:13
  • If you don't follow then you do not understand data recovery. Once you save a file over top of deleted data, that data is usually now unrecoverable because it has been overwritten. However as to your other question, I can't help you because I don't know that program. Nov 1, 2016 at 4:14
  • 3
    @User91232 I'm not trying to recover any data. I am trying to reclaim space left after files are deleted. I'm sure you know that when files are "deleted", their contents are not actually removed from disk; just their file entry is removed. The space where their contents existed on disk is marked as available to be used for new files. I am trying to reclaim that space (zero it out) because this is a VM with a sparsely-allocated disk image. By zeroing the formerly-used space, the disk image can be shrunk. That's what sdelete -z allows for.
    – scottbb
    Nov 1, 2016 at 4:22

4 Answers 4


I had the same problem on a Server 2012 VM and could not log into the machine afterwards.

I reduced the RAM from 12GB to 4GB to get my page file size down. I ran windirtstat and found the file in the user that ran the program


PS Make sure your host hard drive can take the full vm hard drive size if it is provisioned thin


(This doesn't answer my question about finding the temporary file left by SDelete, but it does explain how the problem came to be)

SDelete v2.0 seems to take a lot longer time to complete the zeroing of free space. According to this discussion at sysinternals.com, one user experienced a 28x increase in the time it takes to complete. I quit after several hours into zeroing my 60 GiB virtual hard drive, thinking SDelete had hung.

When I went back to SDelete v.1.6.1 (archive.org), it completed in 45 minutes.


Look not sure if you still have the issue though, but i'm sure that sdelete in all variants leaves the temp file on the root of the drive.

Just make sure you enable hidden files and folders as well as show system files.

it should say something along the lines of sdeletetemp.

Then you should be able to delete the temp file.

I had the same issue with a VM causing massive hard drive usage. 1.4TB. the file was in the root of the drive though.


Linux solutions:

http://utils.kde.org/projects/filelight - Should help you find the big file.



In future I'd suggest zeroing out a drive with linux dd, the partition will need to be mounted.

dd if=/dev/zero of=/mounted-windows-partition/deletefile.file && rm /mounted-windows-partition/deletefile.file

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .