Windows 2008-40 GBのアクセスできないスペース、システムで使用されます。どこ？

Question

VMWare Virual Machine（v7）でシステムのコピーを作成しました。サイズは7.11圧縮され、70圧縮されていません（システムはフランス語です！）ログイン：管理者とパスワード：T3st- https://mega.co.nz/#!l981ACQK!LnLFiUD5-MqPI9PnoOEpb_BiERkPe6W3PFa_x8dc_cE

ハードドライブに40GBが不足していて、それを追跡するために多くのことを試みましたが、成功しませんでした（chkdsk /r /f、デフラグ、WinDirStat、スペーススニファー、Windows Defenderオフラインでの起動、GMER 2.1.1ルートキットの削除、ストリーム、vssadmin、dismなど）。ちなみにプログラムは管理者＆システムとして実行されています

ここでディスク容量の詳細を確認できます。

私が見つけることができる唯一の詳細は、chksdskからのものです。これは、40GBがシステムによって使用されていることを示しています。

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は、それが1つのパーティションのみであることを示しています。

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は次のエラーのトーンを返します：レコードのビット値の取得エラー{オフセット値}

グーグルでは2kの結果しかありません、それらの結果のいくつかはntfsckソースを指しています、他の継ぎ目は気になりません...

Q：システムで使用されているこのスペースを削除するにはどうすればよいですか？

いくつかのより多くの情報：

システムはVMwareコンバーターからのものであり、元のシステム（物理）にも同じスペースの問題があります
ディスクはEASEUSPartition Masterで縮小されましたが、以前は問題が発生していました
仮想マシンを圧縮すると、結果として14Goサイズのtar.gzアーカイブが得られました。たとえば、40Goが空の場合のようになります。

[〜＃〜]編集[〜＃〜]：

使用済みスペースはMFTにありますが、実際にそれを取り除くツールはありません。

Morrow · Answer

VMをダウンロードして、サーバーにロードしました。最初に気付いたのは、Cドライブが圧縮されていることです。物理サーバーがこのような場合は、ドライブを解凍します。実行しても得られるものはほとんどありません。それ。

解凍した後、私はあなたが見ているものを見ていることを確認しました。 150GBに合わせてディスク容量も追加しました。次に、Defraggler Portableをインストールし、ディスクを分析しました。私はセクターを調べて、そこにあるファイルを確認し始め、$ MFTが大量のスペースを占有していることに気づきました。少し検索した後、CCleanerのドライブワイパーユーティリティがこれを修正する可能性があることを発見しました。

空き領域のワイプを開始しました（1パス）。ソフトウェアは「ワイプMFT空き領域」を表示していますが、タスクは約24時間実行されます。実行して報告します。

検索すると、$ MFTとCCleanerに関する多くの情報が見つかります。そもそもこれがどのように起こったかの根源にたどり着く「エウレカ」の瞬間を見つけるかもしれません。私はこの時点でしか推測できません。

更新1：プロセスに予想よりも時間がかかり、VMのパフォーマンスを向上させようとしましたが、進行状況バーが停止し、残り時間が増加しました。より多くのリソースを使用してVMを再構築しましたが、違いがないようです。使用可能なオプションの1つ：Cドライブのバックアップを取り、バックアップが18〜19 GBの範囲にある場合は、Cパーティションをフォーマットまたはワイプして、バックアップを復元します。 $ MFTファイルがこの状態になっているのは、サードパーティのディスクツールが原因であると思われます。

更新2：

私ができることは、スペースを消費しているものを示すことだけです。私はそれを解放することができませんでした。役立つ有料ツールがある可能性があります。 EASEUSの前にシステムにどのパーティショニングソフトウェアがあったかを知っているなら、それもあなたの原因に役立つかもしれません。上のスクリーンショットでは、「ドライブの64％」は68GBの仮想マシンに基づいており、150GBのパーティション全体ではありません。

MrMajestyk · Answer

HopelessN00bのような管理者が質問へのコメントで示唆しているように、spacesnifferを実行してみましたか？通常、大きな未知数が明らかになり、おそらくC:\Windows\WinSxSが原因であることがわかります。これは、Windowsが.DLLファイルの異なるバージョンを保持して、昔のDLL地獄）を回避しようとする場所です。これをコマンドプロンプトから管理者に送信することで、ある程度クリーンアップできます。特権：

Dism.exe /online /Cleanup-Image /StartComponentCleanup-これにより、WinSxSフォルダー内のすべてのファイルのプリーンが開始されます。実際にインストールしたものに応じて、これによりスペースを少しまたはかなり節約できる場合があります。

この件についてMSからこのビットをチェックしてください。また、コマンドがエラーコードで失敗することがよくあることにも注意してください。これは通常、完了する必要のある保留中の操作（Windows Updateなど）がフォルダーにあることを意味します。特に、C:\Windows\WinSxS\pending.xmlというファイルがある場合は、おそらく機能しません。すべてのアップデートをインストールし、再起動してから再試行してください。それが役に立てば幸い！

Soso · Answer

スペースはかなり確実に回復ポイントで占められています。システム制御-システム-詳細設定-タブコンピュータ保護-ボタン設定-ボタン削除でこのドライブのリカバリポイントを削除してみてください。アクセスできないスペースが消えます。

Ian Weydert · Answer

これは興味深い問題です。ここでの私の疑いは、これは仮想化された物理システムからのアーティファクトですが、物理的な原因が存在しなくなったために検出できないということです。

2つの例は次のとおりです。

vMware Converterが認識して回避できた物理ドライブ上の不良ブロックですが、現在は.vmdkファイルの一部ですが、実際の不良ブロックではありません。ビットレベルのコピーが失敗したため、VMwareConverterがファイルレベルのコピーに頼った可能性があります
アプリケーションによって孤立した可能性がある、またはVSSライターの問題が原因で物理システムで認識できなかった、ある種のシャドウコピー

これが私が試みることです：

物理システムがまだある場合は、そこでも完全な分析を実行します。ただし、仮想化をすでに実行して、問題が修正されるかどうかを確認しようとした可能性があります。
VM内でイメージのバックアップを作成している場合は、VMを完全にテストVMに復元して、分析を再実行してみてください。
まだバックアップに使用していない場合は、ShadowProtectを使用して物理システムとVM）システムの両方の別のイメージバックアップを作成してみてください。費用はかかりますが、完全に機能する30日間の試用版をインストールできます。試用期間が終了すると、非アクティブになります。

ShadowProtectでシステムボリュームをバックアップする前に、システムを再起動する必要があります。バックアップを取得したら、ハードウェアに依存しない復元を試してシステムを復元することもできます（ShadowProtect IT Editionを購入する必要があります。私の会社はそれを使用しており、価値がありますが、HIRがそうしないように無料のソリューションを探しているかもしれませんそれに合う）。

ShadowProtectを試す2つの理由：

ファイルシステムにアクセスするためにインストールする完全に独立したVSSライターがあります。ネイティブのWindowsVSSライターが破損しているため、考えられる他のすべてのバックアップソフトウェアが機能しないシステムでShadowProtectを使用しました
ShadowProtectには、無関係なデータを取り除く非常に強力な圧縮機能があります。仮想サーバーをバックアップするとき、通常50％から60％の圧縮率が見られます。この40GBのがらくたを取り除くこともできるかもしれません。

これなら底に達するかどうか知りたいです。