Windows 2008 – 系统使用的40 GB无法访问的空间。 哪里?

我在VMWare虚拟机(v7)中创build了一个系统副本,大小为7.11,压缩成功,70进行解压缩(对不起,系统在法语!)login:pipe理员和密码:T3st https://mega.co.nz /#!l981ACQK!LnLFiUD5,MqPI9PnoOEpb_BiERkPe6W3PFa_x8dc_cE

在我的硬盘上有40 GB的缺失,我已经尝试了很多事情来追踪它没有成功( chkdsk /r /f ,碎片整理,WinDirStat,空间嗅探器,启动Windows Defender离线,GMER 2.1.1 rootkit删除,stream,vssadmin,dism等)。 顺便说一下,程序已经作为pipe理员和系统执行

您可以在这里看到磁盘空间的详细信息:

在这里输入图像说明

我能find的唯一细节是来自chksdsk ,它说系统使用了40 GB:

 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是指系统使用的46 GB)

它似乎不在系统卷信息文件夹中:

在这里输入图像说明

Diskpart显示它只是一个分区:

DISKPART

我也试图在Linux上启动debian live cd来检查硬盘文件和NTFS的完整性:

“du -xks ./* | sort -n”的结果(一切正常)

  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说一切正常

但ntfsck返回以下错误的音调: 获取logging的位值的错误{偏移值}

在谷歌只有2K的结果,一些thoose结果指向ntfsck源,其他接缝不相关…

问:我如何find消除系统使用的空间?

更多信息:

  1. 系统来自VMware转换器,原系统(physic)有相同的空间问题
  2. EASEUS Partition Master的磁盘已经缩小了,但之前就出现了麻烦
  3. 当我压缩虚拟机,我得到了一个14Go大小tar.gz档案,就像如果40​​oGo哪里是空的

编辑

已经使用的空间已经在MFT中,但是没有任何工具可以摆脱它。

我下载了虚拟机,并将其加载到服务器上。 我注意到的第一件事是C驱动器被压缩。 如果您的物理服务器是这样的,解压缩驱动器。 这样做没有什么好处。

解压后,我证实我看到你所看到的。 我还添加了磁盘空间来匹配你的150 GB。 然后,我安装了Defraggler Portable并分析了磁盘。 我开始查看这些部门,看看那里有哪些文件,并注意到$ MFT占用了大量的空间。 经过一番search,我发现CCleaner的Drive Wiper工具可能会解决这个问题。

我开始了一个可用空间的擦除(1遍)。 该软件显示“擦拭MFT的可用空间”,但任务将运行约24小时。 我会让它运行并报告回来。

如果您search,有很多信息可能涉及$ MFT和CCleaner。 你可能会发现一个'尤里卡'的时刻,你会得到这首先发生的根源。 我只能在这一点上推测。

更新1:这个过程花费比预期更长的时间,我试图提高虚拟机的性能,但进度条停止,剩下的时间增加。 我用更多的资源重build了虚拟机,但似乎没有什么区别。 有一个可用选项:备份C盘,如果备份在18-19 GB范围内,则格式化或擦除C分区并恢复备份。 我怀疑第三方磁盘工具负责处于这种情况下的$ MFT文件。

更新2:

在这里输入图像说明

我所能做的就是展示什么是消费空间。 我一直无法释放它。 有可能有有用的工具来帮助。 如果您知道EASEUS之前在系统上有什么分区软件,那也可以帮助您解决问题。 在上面的屏幕截图中,“64%的驱动器”是基于68GB的虚拟机,而不是完整的150GB的分区。

你有没有尝试像pipe理员那样运行spacesniffer像HopelessN00bbuild议在你的问题的意见? 通常,大的未知数可能会清除,你会发现C:\Windows\WinSxS是罪魁祸首。 这是Windows保留不同版本的.DLL文件,以避免以前的DLL地狱。 您可以通过具有pipe理员权限的命令提示符执行此操作来进行清理:

  • Dism.exe /online /Cleanup-Image /StartComponentCleanup – 这会启动WinSxS文件夹中的所有文件。 根据您实际安装的情况,这可能会节省一点点或相当多的空间。

从MS上查看这个主题。 另外请注意,通常情况下,该命令会失败,并显示一些错误代码。 这通常意味着有需要完成的文件夹(如Windows更新)的挂起操作。 特别是,如果有一个名为C:\Windows\WinSxS\pending.xml ,则可能不起作用。 让所有的更新安装,也许做一个重新启动,然后再试一次。 希望能帮助到你!

这是一个有趣的问题。 我的怀疑是,这是虚拟化的物理系统中的一些神器,但无法检测到,因为不pipe物理原因不再存在。

两个例子可以是:

  • VMware Converter能够识别和解决物理驱动器上的坏块,但是现在坏块是.vmdk文件的一部分,但是它们并不是真正的坏块,因为VMware Converter可能采用了文件级副本一个比特级的副本失败了
  • 某些影子副本可能已经被应用程序孤立或者在物理系统上无法识别,因为VSS作者应该在那里发布问题

这是我会尝试的:

  1. 如果你仍然有物理系统,那么也要在那里进行全面的分析。 除此之外,也许你已经尝试了虚拟化,看看这样做是否会纠正这个问题。

  2. 如果您要在虚拟机内进行映像备份,请尝试将虚拟机完全还原到testing虚拟机,然后再次进行分析。

  3. 如果您尚未将其用于备份,请尝试使用ShadowProtect对物理和虚拟机系统进行另一个映像备份。 它的成本,但你可以安装一个全function的30天的试用,将在试用期结束后不活动。

在ShadowProtect允许您备份系统卷之前,您需要重新启动系统。 获得备份后,您还可以尝试硬件独立恢复来恢复系统(您需要购买ShadowProtect IT Edition;我的公司使用它,这是值得的,但是您可能正在寻找免费的解决scheme,以免HIR适合的)。

使用ShadowProtect的两个原因:

  • 它已经完全分离VSS编写器,它安装到文件系统。 我已经在系统上使用了ShadowProtect,因为原生的Windows VSS编写器已经损坏,我认为其他所有备份软件都无法运行
  • ShadowProtect具有非常强大的压缩function,可以清除无关的数据。 备份虚拟服务器时,通常会看到50%到60%的压缩比。 它也许能够清除这个40GB的垃圾。

我很想知道你是否能够做到这一点。