SDELETE 2.02 stuck on Purging MFT files RRS feed

  • Question

  • Hi, i've tried to clean the free space on a VM disk to retrieve some unused space for the VMDK file.

    The drive is about 250GB in size with 180GB of free space.

    I downloaded SDELETE version 2.02 and tried to launch the command : sdelete64.exe -z d:

    SDelete v2.02 - Secure file delete

    Copyright (C) 1999-2018 Mark Russinovich

    Sysinternals -

    SDelete is set for 1 pass.

    Purging MFT files 7841% complete

    The process is running since about 24 hours...

    Is it normal that the Purging MFT step takes so long and runs above 100% like this ?

    Thanks to get back to me as soon as possible.


    Wednesday, January 30, 2019 5:39 PM

All replies

  • Hmm this strange. I will take a look. 

    This is the stage where sdelete walks through the MFT and deletes any MFT resident files. This can take a long time and we had several people think the delay was a hang so for 2.02 I added the counter you are seeing there. Seems like there is an error in the calculation somewhere so I will take a look and see if I can figure out what's going on. 

    If it's still running would you consider taking a process dump (you can do this directly from task manager by right clicking on the sdelete process)? If so please contact me offline at and I will provide you with an upload location

    MarkC (MSFT)

    Thursday, January 31, 2019 7:43 PM
  • I run sdelete on a virtual machine.

    The purging MFT goes to 100% when the drive was not compressed

    After compress the system drive, the purge of MFT files seems never stop... Actually more than 4000%

    Monday, March 18, 2019 10:21 PM
  • I'm also having this same problem. Do you still need logs? Also, is this miscalculation just for output to the console? (meaning the actual process is still working correctly?) Please let me know, asap.
    Saturday, March 30, 2019 8:03 AM
  • Hello

    I was actually looking at this problem last week after another user provided us with a dump file. From the dump we can see that there was an issue with the calculation for the number of clusters in the MFT. I am working on a fix for this and also looking to address the performance issue so will provide an update shortly.

    Thanks for raising this and for your continued patience.

    MarkC (MSFT)

    Monday, April 1, 2019 8:10 AM
  • I have the same issue.  Using SDelete bloats my VDMK to the full provisioned size and without completing stage 2, the disk does not thin.
    • Edited by ws_itman Tuesday, May 14, 2019 1:07 PM
    Tuesday, May 14, 2019 12:34 PM
  • @MarkC,

    If 2.02 failed to perform stage 2, will the next version purge the MFT files from the previous failed run?  Is there an estimated time frame for the next version?  Thanks.

    Monday, May 20, 2019 7:14 PM
  • I have the same issue. sdelete takes part of a day for phase 1 and then several days to purge mft files. one sdelete is currently sitting at about 1878074315%   which I am guessing is 18%. and that is on an al flash array with about 30 spindles.

    hoping 2.0.3 comes out soon.

    Friday, May 31, 2019 4:27 PM
  • It seems to work fine on my NTFS disks but not ReFS.
    Thursday, June 20, 2019 6:57 PM
  • Hello, I'm seeing the same issue at the moment, trying to free space on a 150 GB disk with 80 GB free space. Here where it is:

    SDelete v2.02 - Secure file delete
    Copyright (C) 1999-2018 Mark Russinov
    Sysinternals -
    SDelete is set for 1 pass.
    Purging MFT files 4115% complete

    It has been running for about 10 hrs. The drive is compressed.

    Could someone help with if it will ever finish? If so when? Is it going to corrupt any data? Is there a new version with the issue fixed?

    Thanks in advance!

    • Edited by Grigor G Monday, August 5, 2019 1:27 PM
    Monday, August 5, 2019 1:25 PM
  • Using SDelete to zero free space to compact virtual storage, like a lot of others here.

    Most of my Windows test machines have pretty small hdds, 30-50GB. After v1.61 SDelete was unusable for the task. This was finally somewhat fixed in 2.02. However, it still does something weird at the MFT stage. It is weird because it takes almost as long to go through MFT as zeroing the whole 50GB virtual disk, and (which is weirder) I can see that MFT part is writing almost the same amount of data as the disk zeroing does (~100MB per second for minutes). That doesn't look like "walks through the MFT and deletes any MFT resident files".

    Saturday, September 14, 2019 8:19 PM
  • @MarkC,  any news about fixing a problem?
    Tuesday, September 17, 2019 1:47 PM
  • @Mark, I am facing this same issue. 

    C:\Temp>sdelete64.exe -z E:

    SDelete v2.02 - Secure file delete
    Copyright (C) 1999-2018 Mark Russinovich
    Sysinternals -

    SDelete is set for 1 pass.
    Purging MFT files 111% complete

    Any idea when this would finish it's been 2 weeks on a 44TB drive.

    Friday, January 17, 2020 12:35 AM
  • Hi, can you please provide an update on timescales for this issue?


    Monday, February 3, 2020 12:41 PM
  • I have this problem, too. Thanks for taking a look into it please,



    Saturday, March 14, 2020 2:13 PM
  • Hello to all

    I had the same problem (Windows7, sdelete 2.02, C: Drive), but I solved it.

    Solution for c: (
    for drives where windows is):
    1 Go to C:\Users\<username>\AppData\Local\
    2 Right-click on "Temp", then: -> Properties -> General -> Advanced -> uncheck "Compress contents to save disk space" -> OK -> OK
    3 Now you can run sdelete again and it will complete successfully
    4 If necessary, you can check this option again when sdelete is completed.

    If you have a different version of windows (xp for example), the path may be different. In this case, I recommend using procmon to watch sdelete and find out where it creates its temporary file.

    Solution for other drives:

    This is a bit more complicated, because a temporary file is created in the root of the disk, and disabling compression for the entire disk is a bit silly
    But this small hack helped me:
    1 run cmd as administrator
    2 cd /D <your_drive_letter>
    3 mkdir tmp
    4 mklink SDELMFT000000 tmp\SDELMFT000000
    5 uncheck compression for "tmp" folder as shown previously
    6 run sdelete
    7 when sdelete
    will complete, delete "tmp" and "SDELMFT000000"

    I hope this helps

    • Edited by GenZmeY Tuesday, April 7, 2020 5:42 AM
    • Proposed as answer by GenZmeY Tuesday, April 7, 2020 8:17 PM
    Tuesday, April 7, 2020 4:31 AM
  • Thanks for your answer GenZmeY. This is the solution, as well as the explanation of the failure mode of sdelete.
    Sunday, April 12, 2020 11:08 PM
  • Unfortunately, the workaround of turning off Compression on C: drive didn't apply to me, it was already unchecked. I stumbled upon another workaround - USE AT YOUR OWN RISK!!!!

    When sdelete64.exe -z c: got stuck at 77% Purging MFT files I used CTRL+X (I was running this inside PowerShell command shell for what it's worth) and lo and behold it progressed to 78%. I pressed CTRL+X again and it progressed to 79%. Elated, I continued to press CTRL+X until it reached 100%! I was then able to successfully SSH into my ESXi shell, and run the vmkfstools -K NameOfDisk.vmdk which is the way to shrink thinly provisioned disks on my host, and it worked (reduced mine by 50%).

    I'm NOT RECOMMENDING this, just sharing how I got out of this bind.

    Friday, June 19, 2020 10:53 PM