i created a copy of the system in a VMWare Virual Machine (v7), size is 7.11 Go compressed, 70 Go uncompressed (sorry system is in french !) log in: adminstrateur & password: T3st https://mega.co.nz/#!l981ACQK!LnLFiUD5-MqPI9PnoOEpb_BiERkPe6W3PFa_x8dc_cE

There is 40 GB missing on my hard drive, and I've tried lots of things to track it down without success (chkdsk /r /f, Defrag, WinDirStat, Space sniffer, Boot on Windows defender offline, GMER 2.1.1 rootkit removal, streams, vssadmin, dism etc.). By the way the programs have been executed as admin & system

You can see the disk space detail here:

enter image description here

The only detail I can find is from chksdsk, which says that the 40 GB is used by the system:

Le nom de volume est System.

Avertissement ! Le paramètre F n'a pas été spécifié.
Exécution de CHKDSK en mode lecture seule.

CHKDSK est en train de vérifier les fichiers (étape 1 sur 3)...
  46402816 enregistrements de fichier traités.
La vérification des fichiers est terminée.
  793 enregistrements de grand fichier traités.
  0 enregistrements de fichier incorrect traités.
  0 enregistrements EA traités.
  84 enregistrements d'analyse traités.
CHKDSK est en train de vérifier les index (étape 2 sur 3)...
  46451532 entrées d'index traitées.
La vérification des index est terminée.
  0 fichiers non indexés analysés.
  0 fichiers non indéxés récupérés.
CHKDSK est en train de vérifier les descripteurs de sécurité (étape 3 sur 3)
  46402816 SD/SID de fichiers traités.
La vérification des descripteurs de sécurité est terminée.
  24359 fichiers de données traités.
CHKDSK vérifie le journal USN...
  100 % effectués. (1212416 octets USN sur 1216272 traités)
  1216272 octets USN traités.
Vérification du journal USN terminée.
Windows a vérifié le système de fichiers sans trouver de problème.

   157701119 Ko d'espace disque au total.
    26568260 Ko dans 260039 fichiers.
      130984 Ko dans 24360 index.
           0 Ko dans des secteurs défectueux.
    46482335 Ko utilisés par le système.
       65536 Ko occupés par le fichier journal.
    84519540 Ko disponibles sur le disque.

      4096 octets dans chaque unité d'allocation.
  39425279 unités d'allocation au total sur le disque.
  21129885 unités d'allocation disponibles sur le disque.

(46482335 Ko utilisés par le système means 46 GB used by system)

It doesn't seem to be in the System Volume Information folder, either:

enter image description here

Diskpart show that s it is only one partition :


i also tried to boot on linux debian live cd to check hard drive file & NTFS integrity:

result of "du -xks ./* | sort -n" (all is ok)

 0          ./Documents and Settings
 1          ./autorun.inf
 1          ./boot.ini.1.cache
 1          ./boot.ini.cache
 1          ./boot.ini..cache
 8          ./BOOTSECT.BAK
 16         ./cleanmem_log.txt
 22         ./SRVPRB
 53         ./SRVLOG
 234        ./$Recycle.Bin
 376        ./bootmgr
 504        ./Config.Msi
 916        ./_icon
 971        ./SRVSCRIPT
 2443       ./SRVTOOL
 3376       ./System Volume Information
 3792       ./inetpub
 15436      ./Boot
 19636      ./SRVWEB
 169092     ./Recovery
 281139     ./ProgramData
 513829     ./SRVINFO
 1421744    ./Program Files (x86)
 1543517    ./Users
 2877066    ./Program Files
 4197856    ./SRVFPT
 14981405   ./Windows

ntfsfix & ntfsfix -d say all is ok

but ntfsck return tones of the following error: error getting bit value for record {offset value}

on google there is only 2k results, some of thoose results are pointing on ntfsck source, the others seams not revelant...

Q : How do I find eliminate this space that's used by the system?

some more infos :

  1. the system come from VMware converter, the original system (physic) has the same space trouble
  2. the disk has been shrinked with EASEUS Partition Master, but the trouble was present before
  3. When i compress the Virtual Machine i got as result a 14Go size tar.gz archive, like if thoose 40Go where empty


Used space has been located in MFT but no tool actually get rid of it.

  • You need to find out what's using the space - try running your spacesniffer program as administrator or SYSTEM, as this "missing pace" often means the program doesn't have the permissions needed to view what's taking up the space. – HopelessN00b Feb 26 '15 at 11:18
  • click on the image you will see that space unaccessible has been found (40Go) and are not in any folder, it has been run as administrator, it is not a trouble of permission access. By the way you should read more information please, case most of the infos are in the chkdsk result. System size taken is not in any folder – Froggiz Feb 26 '15 at 11:19
  • thanks for the edit, my account is new so i can't post image. – Froggiz Feb 26 '15 at 11:52
  • No problem. Like I said, though, it's almost always in a hidden, system folder somewhere. If only the SYSTEM account has read access, that's why you can't find it, even when running as administrator. So try running your disk space tools as SYSTEM and see if that lets you see where this space is. Using PSexec is the easiest way to do this, FYI. – HopelessN00b Feb 26 '15 at 11:56
  • here is the pics: dl.free.fr/rg3Eokgpb i really think it is something more complex, i have set the rights to all c: files to administrator to be able to explore all, when i compress the disk (outside the OS) i get a tar.gz with 14go size, it wouldn t be possible if thoose 40go would really be filled with data – Froggiz Feb 26 '15 at 12:07

Did you try running spacesniffer as administrator like HopelessN00b suggests in the comments to your question? Usually, the big unknowns clear up and probably, you will find that the C:\Windows\WinSxS is the culprit. This is where Windows keeps different versions of .DLL files in an attempt to avoid the DLL hell of olden times. You can clean it up somewhat by doing this from a command prompt with administrator privileges:

  • Dism.exe /online /Cleanup-Image /StartComponentCleanup - this starts a preen of all the files in the WinSxS folder. Depending on what you actually have installed, this may save just a little or quite a lot of space.

Check out this bit from MS on the subject. Also note that quite often, the command will fail with some error code. This usually means that there are pending operations on the folder (like Windows updates) that need to complete. Particularly, if there is a file called C:\Windows\WinSxS\pending.xml, it probably won't work. Let all updates install, maybe do a reboot and then try again. Hope it helps!

  • thanks for the suggestion, yup i did as administrator and as system. i already cleaned the server, so as you can see on the pic my Winxs is only 10go size – Froggiz Feb 26 '15 at 12:10
  • dism /Online /Cleanup-Image /spsuperseded say all is ok and nothing to clean :'( – Froggiz Feb 26 '15 at 12:20
  • 1
    Oh. Well then I missed on my answer - sorry it didn't help. Could it be Shadow Copies perhaps? Have you tried using vssadmin to probe that area? I am not sure spacesniffer would show those. You might also try Treesize - it works with alternate streams and such. Might give a clearer picture. – MrMajestyk Feb 26 '15 at 12:31
  • "vssadmin delete shadows /for=c: /oldest" sent nothing to remove, no shadow copy found – Froggiz Feb 26 '15 at 12:35
  • That really is an annoying problem then - how about this then: Have you tried the SysInternals streams tool (available here)? It shows alternate streams (an NTFS feature). Maybe something shows up if you do `streams -s c:`. – MrMajestyk Feb 26 '15 at 13:13

I downloaded the VM and loaded it on a server. First thing I noticed was the C drive was compressed. If your physical server is like this, decompress the drive. There is little to gain by doing that.

After decompressing, I verified I'm seeing what you're seeing. I also added disk space to match your 150 GB. I, then, installed Defraggler Portable and analyzed the disk. I started looking at the sectors to see what files where there and noticed $MFT occupying a large amount of space. After a little searching, I discovered CCleaner's Drive Wiper utility might fix this.

I started a wipe of the free space (1-pass). The software is showing "Wipe MFT Free Space" but the task will run for about 24 hours. I'll let it run and report back.

There's a lot of information to be found involving $MFT and CCleaner if you search. You may find a 'eureka' moment that will you get to the root of how this happened in the first place. I can only speculate at this point.

Update 1: The process was taking longer than expected and I attempted to boost performance of the vm but the progress bar stopped and the time remaining increased. I rebuilt the vm with more resources but it doesn't seem to make a difference. One option that is available: take a backup of the C drive and if the backup is in the 18-19 GB range, format or wipe the C partition and restore the backup. I'm suspecting a 3rd party disk tool is responsible for the $MFT files being in this condition.

Update 2:

enter image description here

All I've been able to do is show what is consuming the space. I haven't been able to free it. There are likely paid tools to help. If you know what partitioning software was on the system before EASEUS, that might help your cause, too. On the above screenshot, the "64% of drive" is based on the 68GB vm, not the full 150GB partition you have.

  • Sorry for the late answer. Thanks for the information, i tested CCleaner without success, i found infomrations about the content of MFT and which part cause the trouble. I will post informations as answer once i am done (if all goes well). Then i will reward you the points even if answer is not complet. Can you tell me the command you did to get the information of your screenshot? thanks. – Froggiz Nov 30 '15 at 18:43
  • I used NTFSInfo from sysinternals. – Morrow Nov 30 '15 at 18:46
  • I wasn't exactly clear...run the sysinternals utility from command line and designated a drive letter. – Morrow Nov 30 '15 at 21:16
  • A fragmented MFT with lots of unused space can be cleaned up with some defrag utilities - one that while not free does have a functional trial version is Auslogics Disk Defrag Pro – Brian Dec 2 '15 at 6:52

This is an interesting problem. My suspicion here is that this is some artifact from the physical system that got virtualized, but is undetectable because whatever physical cause is no longer present.

Two examples could be:

  • bad blocks on the physical drive that VMware Converter was able to recognize and get around but now the bad blocks are part of the .vmdk file, however they aren't real bad blocks because VMware Converter may have resorted to a file-level copy since a bit-level copy was failing
  • some kind of shadow copies that may have gotten orphaned by their application or were unrecognizable on the physical system to due VSS writer issues there

Here's what I would try:

  1. If you have the physical system still, run your full analysis there also. Except, maybe you already have and tried virtualization to see if doing so would correct the issue.

  2. If you're taking image backups within the VM, try restoring the VM fully to a test VM and doing your analysis again.

  3. If you're not using it already for backups, try taking another image backup of both the physical and VM systems using ShadowProtect. It costs but you can install a fully-functional 30-day trial that will just go inactive after the trial period ends.

You'll need to reboot the system before ShadowProtect will let you backup the system volume. After you get a backup, you can also try Hardware Independent Restore to restore the system (you would need to purchase the ShadowProtect IT Edition; my company uses it and it's worth it, but you may be looking for free solutions so HIR wouldn't fit that).

Two reasons for trying ShadowProtect:

  • it has completely separate VSS writers that it installs to get at the filesystem. I've used ShadowProtect on systems where every other backup software I can think of will not work because the native Windows VSS writers are corrupted
  • ShadowProtect has extremely powerful compression that weeds out extraneous data. I usually see between 50% and 60% compression ratio when backing up virtual servers. It might be able to weed out this 40GB of junk too.

I'm curious to know if you get to the bottom if this.

  • I've also used ShadowProtect backup for P2V conversion if VMware Converter or Disk2VHD are giving me grief. – Ian Weydert Feb 28 '15 at 19:50
  • thanks for the suggestion, i am a bit busy right now, i lost lot of time in tries, but i will make ShadowProtect test as soon i can work back on this trouble. – Froggiz Mar 2 '15 at 12:17
  • I am really curious about this too - I think that it is completely odd that this chunk of space is inaccessible yet OK by NTFS standards. If there is some oddity in the P2V process or something like that, it is certainly worth making a note of. – MrMajestyk Mar 5 '15 at 7:41
  • still no success on tries, i posted a Virtual Machine with the same trouble – Froggiz Apr 14 '15 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.