Windows 2008 - 40 GB inaccessible space, used by system. Where?

Question

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:

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:

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

EDIT :

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

Answer 1

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!

Answer 2

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:

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.

Answer 3

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).

• http://www.shadowprotect.com/shadowprotect-backup-software-downloads
• http://www.storagecraft.com/support/book/storagecraft-recovery-environment-user-guide/restoring-system-volume

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.

Answer 4

the space is occupied pretty sure be the recovery points. Try deleting the recovery points for this drive at system control - system - advanced settings - Tab computer protection - button configure - button delete and you will see the unaccessible space disappearing.