Schön, dass ihr den Thread übers Wochenende warm gehalten habt.
Man könnte den unteren Teil in einen eigenen Thread abkoppeln, da er abgedriftet ist. Aus einer einfachen Aussage die noch zum Thema gehörte, ist mittlerweile ein kleines separates Forschungsprojekt geworden.
Man findet schon einiges zum Thema, aber weder eine Erklärung noch eine Lösung.
Immer wieder werden Bereinigungen und Checks empfohlen und darauf hingewiesen, dass die Summe aller Dateigrößen nicht aussagekräftig ist. Aber warum Windows GUIs und der dir Befehl danach immer noch viel weniger freien Platz anzeigen als chkdsk, das wird weder erklärt noch gefixt.
Man könnte den unteren Teil in einen eigenen Thread abkoppeln, da er
abgedriftet ist. Aus einer einfachen Aussage die noch zum Thema gehörte,
ist mittlerweile ein kleines separates Forschungsprojekt geworden.
Nicht schlimm. Mein Teil ist ja seit Freitag erledigt.
Erschwerend kommt hinzu dass die Recherche nach zwei Szenarien unterschieden werden muss.
Der erste Fall, Summe aller Dateien Größe auf dem Datenträger ist größer als der in der Datenträgerverwaltung angezeigte belegte Speicherplatz.
Hierfür gibt es plausible Erklärungen:
Hardlinks werden mehrfach gezählt
Kompression
Sparse Dateien die vorgeben größer zu sein als der tatsächlich genutze Speicherplatz
Der zweite Fall, der in der Datenträgerverwaltung angezeigte belegte Speicherplatz ist größer als die Summe aller Dateien Größe auf dem Datenträger
Mögliche Erklärungen:
MFT
verwaiste/korrupte Dateifragmente belegen Speicherplatz der noch nicht als freigegeben markiert wurde
fehlende Zugriffsberechtigung auf Dateien, Dateigröße kann nicht ermittelt werden
geheime Stealth Dateien in ADS Streams versteckt
Overhead durch Bitlocker-Verschlüsselung
Hab bestimmt einiges vergessen.
Das alles scheint aber in Deinem Fall nur einen Bruchteil auszumachen. Man darf nicht vergessen dass NTFS ein proprietäres Dateisystem ist. Linux kann möglicherweise noch nicht so gut damit umgehen wie wir glauben.
Oder vielleicht ist es wirklich ein Problem mit der VM.
Und tatsächlich: Mit Linux konnte ich weitere sieben 1 GB Dateien anlegen, die achte war zu viel (2025-09-01_09-44.png). Die achte Datei habe ich wieder gelöscht, danach sind etwa 130 MB frei (2025-09-01_09-45.png).
Leider startet Windows jetzt nicht mehr, der Anmeldebildschirm erscheint nicht (grmpf, aber das war zu erwarten). Also habe ich mit Linux schrittweise mehr Platz frei gemacht, bis die Anmeldung wieder funktioniert.
Ich habe jetzt laut Linux 7,5 GB frei. Nach der Anmeldung erscheint die blaue Fehlermeldung (2025-09-01_10-23.png), habe ich noch nie gesehen. Im Startmenü ist die Suchfunktion tot. Der Explorer zeigt 0 Bytes frei an, chkdsk sieht aber 6,7 GB als verfügbar (2025-09-01_10-26.png).
Ich lösche ein weiteres GB (dieses mal mit dem Explorer) und starte Windows neu. Die blaue Fehlermeldung nach der Anmeldung kommt immer noch. Der Explorer zeigt 10 MB frei an (ohne screenshot).
Ich lösche ein weiteres GB mit dem Explorer und starte Windows neu. Die blaue Fehlermeldung nach der Anmeldung kommt immer noch. Der Explorer zeigt unerwartet viele 4,75 GB frei an (2025-09-01_10-34.png). Meine verbleibenden Testdateien sind alle verschwunden!
In der Benachrichtigungsleiste erscheint ein Hinweis, dass ich mit einem temporären Profil angemeldet wurde und keinen Zugriff auf Dateien habe. Die Suchfunktion im Startmenü ist immer noch tot.
Chkdsk findet keine Fehler, meldet 7,7 GB als frei (2025-09-01_10-37.png).
sfc /scannow findet und repariert beschädigte Dateien.
Ich starte Windows neu, nach der Anmeldung erscheint immer noch die blaue Fehlermeldung. Windows ist kaputt.
Ich wechsele zu Linux. Die 1GB Testdateien sind tatsächlich weg. Linux meldet 13 GB freien Platz.
Ich schließe daraus:
Windows speichert Daten, die chkdsk nicht sieht (daher als verfügbar zählt), ebenso Linux. Mit Windows kann man den Platz nicht beschreiben, aber mit Linux. Danach ist Windows kaputt.
Und: chkdsk zeigt den freien Speicherplatz falsch an, der Explorer tut es richtig.
Dass ich Laufwerk C fast komplett voll gemacht habe ging offenbar zu weit. Ich will das Experiment nochmal wiederholen, aber reichlich Platz frei lassen. Bis gespannt, wie Windows darauf reagiert. Los geht's:
Ich fange mit einer frischen Windows 10 Installation ohne Internet Anbindung an. Darin erstelle ich zehn 1 GB Dateien. Der Explorer zeigt nur noch 854 MB als frei an, chkdsk meldet 8,8 GB als frei (2025-09-01_11-18.png).
Reboot tut gut. Klappt auch, ich kann mich ohne Probleme anmelden. Ich fahre Windows ordentlich herunter.
Ich wechsele zu Linux und lege drei weitere 1 GB Dateien an. Laut Linux sind noch 6,3 GB frei (2025-09-01_11-33.png).
Zurück zu Windows: Startet nicht mehr. Ich bekomme einen schwarzen Bildschirm, kann mich wieder nicht anmelden. Nach einem Kaltstart meldet Windows, es sei kaputt (ach!) und muss automatisch repariert werden. Nach zwei Wiederholungen kommt die Meldung
Automatische Reparatur konnte ihren PC nicht reparieren.
Ich habe fertig, Flasche leer.
Offenbar hätte ich die "geheimen" Daten im angeblich freien Bereich nicht überschreiben dürfen.
Ich bin nach wie vor der Meinung da ist ein Problem mit der Virtualisierung. Was nutzt Du überhaupt, Hyper-V, Virtualbox oder VMWare? Mir war auch so als ob diese Images Speicherplatz für das RAM reservieren (nicht die Auslagerungsdatei, RAM für die VM)
Ich bin nach wie vor der Meinung da ist ein Problem mit der
Virtualisierung.
Nein, das kann nicht das Problem sein. Völlig egal, wie die Virtualisierung funktioniert, der virtualisierte PC sieht ein Blockdevice fester Größe, und das beschreibt und liest er.
Daß die Virtualisierung dieses Blockdevice auch in eine dynamisch wachsende Datei abbilden kann (deren Gräöße also je nach Füllgrad in der VM wächst), spielt hier auch keine Rolle - aus Sicht des virtualisierten Betriebssystems ist da ein Blockdevice mit einer fest defierten Anzahl von Sektoren. Und die verwaltet es.
Ich werde es bald mit einem alten Laptop ohne VM versuchen.
Hat eine Weile gedauert, weil mein USB Stick kaputt gegangen ist.
Die SSD hat 120 GB.
Der Explorer meldet 97 GB frei.
Chkdsk ebenfalls).
Der Laptop läuft heiß und super lahm, weil er Treiber braucht (das bin ich bei diesem Modell so gewohnt).
Also habe ich Internet aktiviert und die Updates durch laufen lassen.
Dann noch ein paar Treiber vom Hersteller manuell installiert.
Die SSD hat immer noch 120 GB :-)
Der Explorer meldet 86 GB frei.
Chkdsk ebenfalls.
Also dieser Laptop nicht betroffen.
Der Laptop meiner Frau wurde vor ein paar Wochen von Windows 10 auf 11 aktualisiert.
Die SSD hat 240 GB.
Der Explorer meldet 160 GB frei.
Chkdsk meldet mehr: 166 GB (174087660 kB) frei.
Er ist also betroffen. Auf diesem Rechner darf ich keine Experimente durchführen.
Ich habe auch Oracle VirtualBox versucht, aber das habe ich nicht ans Laufen bekommen. Vielleicht kollidiert es mit QEMU/KVM.
Ich wechsele zu Linux und lege drei weitere 1 GB Dateien an. Laut Linux
sind noch 6,3 GB frei (2025-09-01_11-33.png).
Zurück zu Windows: Startet nicht mehr.
Spannend wäre gewesen, was passiert wäre, wenn du die drei zusätzlichen Dateien einfach auch noch unter Windows geschrieben hättest...
Wetten, dass es dann auch nach dem Reboot noch gestartet wäre oder alternativ bereits beim Schreiben eine Fehlermeldung gekommen wäre?
Merke: Es war noch nie eine gute Idee, ein Filesystem bis an den Rand vollzuschreiben. Das gilt übrigens auch bei den unter Linux üblichen FS, nicht nur bei NTFS.
Es gilt um so mehr, je mehr Spielereien, ooops... Features ein FS anbietet.
Das geht nicht. Habe ich versucht, bricht mit "disk full" ab.
Dacht' ich's doch.
Windows
schützt sich.
Der Filesystemtreiber schützt sein Filesystem. U.a. dadurch, das er immer genug Platz frei hält, so dass er auch die exotischste denkbare Anforderung zur Strukturänderung noch in das Log (AKA: Jounal) schreiben kann.
ntfs-3g sieht das etwas entspannter, weil es einige exotische NTFS-Features einfach mal nicht unterstützt. Deswegen hält es deutlich weniger Platz in Reserve für nötig.
Sprich: wenn du die drei Dateien unter Linux auch gleich wieder gelöscht hättest, wäre überhaupt nix Schlimmes passiert. Oder anders ausgedrückt: es gibt keine versteckten Windows-Daten. Die wären nämlich auch dann weg gewesen.
Das Problem war wirklich nur, dass der Windows-NTFS-Treiber nicht mehr genug Platz gesehen hat, um beliebige Schreibvorgänge zuverlässig durchzuführen und deshalb konsequenterweise überhaupt keine mehr erlaubt, auch keine einfachen mehr, die eigentlich viel weniger Platz benötigen würden. Ohne Schreibzugriff auf die Systemplatte mag Windows aber nicht booten.
Ich könnte mir übrigens gut vorstellen, dass es nach dem fehlgeschlagenen Boot auch genügt hätte, unter Linux diese drei Dateien wieder zu löschen, um alles wieder in's Lot zu bringen. Aber nach der Anwendung der Windows-Reparaturfunktionen geht das vermutlich dann nicht mehr.
Sprich: wenn du die drei Dateien unter Linux auch gleich wieder gelöscht
hättest, wäre überhaupt nix Schlimmes passiert.
Das habe ich durch gespielt. Windows ist danach trotzdem kaputt.
Ich könnte mir übrigens gut vorstellen, dass es nach dem
fehlgeschlagenen Boot auch genügt hätte, unter Linux diese
drei Dateien wieder zu löschen
Auch das habe ich probiert (sogar vorher). Windows bleibt danach trotzdem kaputt. Ich habe noch lange nicht jeden Versuch hier einzeln berichtet. Immerhin bin seit 3 Tagen durchgehen an dem Thema dran.
Man darf in die letzten reservierten GB wirklich nicht hinein schreiben. Wenn du einen Rechner hast, der betroffen ist, kannst du es diesem probieren. Ich habe es mehr als 6 mal wiederholt, Windows war immer kaputt. Egal wann und womit ich die Dateien wieder gelöscht habe.
Das Problem war wirklich nur, dass der Windows-NTFS-Treiber nicht
mehr menug Platz gesehen hat, um beliebige Schreibvorgänge zuverlässig
durchzuführen und deshalb konsequenterweise überhaupt keine mehr
erlaubt
Das passt nicht zu meiner Beobachtung, dass Windows diesen "verborgenen Bereich" nicht anlegt, wenn Laufwerk C nur 16 oder 20 GB klein ist. Trotzdem funktioniert es damit tadellos.
Aber nach der Anwendung der Windows-Reparaturfunktionen geht das
vermutlich dann nicht mehr.
Ich frage mich, ob die Windows-Reparatur jemals funktioniert hat. Bei mir jedenfalls noch nie. Ich habe eher den Eindruck, dass sie es noch schlimmer macht. Jedenfalls habe ich natürlich nach jedem Versuch immer wieder eine neue VM aufgesetzt und frisch installiert.
Ich habe zu dem Thema eine Webseite erstellt. Die kann ich besser mit neuen Erkenntnissen aktualisieren - falls da noch was kommt. Ich bin mit meinem Latein nämlich vorläufig am Ende.
Kann man sich die MFT genauer ansehen? Ich weiß noch aus Windows 2000 Zeiten, als NTFS Support noch hochgradig experimentell war, hatte sich ein Backup als unzureichend erwiesen das ich mit Linux erstellt hatte. Grund war, dass die MFT bei mir größer war als Standard und das Tool die einfach nicht komplett gesichert hatte.
Google sagt NTFSInfo oder MFTECmd.
NTFS reserviert 12,5 Prozent des Volumens für die ausschließliche
Nutzung des MFT
Wozu? Deren Größe wird offensichtlich sowohl vom Explorer als von chkdsk berücksichtigt. Laut Microsofts Doku ist sie in dem Posten "vom System benutzt" enthalten.
Google sagt NTFSInfo oder MFTECmd.
Gibt es beides nicht in Windows. Ich habe auch keine Lust, noch mehr Fremdprogramme auszuprobieren. Jedes zeigt was anderes an, am Ende weiß man gar nicht mehr, welchem man vertrauen soll.
Interessanter finde ich diese beiden Zeilen in der AUsgabe:
Reservierte Cluster insgesamt : 1.719.311 ( 6,6 GB)
Reserviert für Speicherreserve : 1.697.154 ( 6,5 GB)
Die Größe kommt mir verdächtig vor.
Habe dazu dies gefunden:
Die MFT liegt ziemlich am Anfang der Partition, gefolgt von 12,5% reserviertem Bereich, der möglichst lange nicht mit Dateien belegt wird. Erst wenn die ganze Partition voll ist, wird in diesen Bereich geschrieben.
Mich beschleicht das Gefühl, dass dieser Bereich mit meinem "Problem" zu tun haben könnte. Das schaue ich mir morgen genauer an.
Mich beschleicht das Gefühl, dass dieser Bereich mit meinem "Problem" zu
tun haben könnte.
Hat er nicht. Die Größe von "Reserviert für Speicherreserve" entspricht nicht der Differenz zwischen dem verfügbaren Speicher im Explorer versus chkdsk. Ich habe das auf 3 Computern kontrolliert (einer davon eine VM).
Mich beschleicht das Gefühl, dass dieser Bereich mit meinem "Problem" zu
tun haben könnte.
Hat er nicht. Die Größe von "Reserviert für Speicherreserve" entspricht nicht der Differenz zwischen dem verfügbaren Speicher im Explorer versus chkdsk. Ich habe das auf 3 Computern kontrolliert (einer davon eine VM).
Du gehst nicht systematisch genug vor. Ich würde ein kleines Script schreiben dass erstmal alle Hardlinks und Streams rechnet. Und wieviel für die MFT tatsächlich reserviert ist muss man auch irgendwie rauskriegen. Die Sysinternals von Mark Russinovich sind so gut das M$ sie irgendwann übernommen hat. Vielleicht ist da das richtige Werkzeug dabei.
Eine Diskrepanz zwischen du / df gibt es übrigens auch auf jedem ext4 Dateisystem. Dort wird Speicherplatz reserviert für die inodes. Gelöschte Dateien die noch von irgendeinem Programm offen gehalten werden bleiben auch physisch vorhanden, der Speicherplatz wird erst nach einem mount frei.
Die Angabe in Klammern stammt von mir. Dazu habe ich die Zahl zweimal durch 1024 geteilt. Wenn ich sie stattdessen zweimal durch 1000 teile, passen sie!
Zum Vergleich schaue ich mir die Lage auf dem Laptop an. Dort ist der Reservierte Speicher größer, fast 7 GB. Ich deaktiviere ihn und kontrolliere das Ergebnis:
Auch hier stimmen die Zahlen nicht, aber wenn ich zweimal durch 1000 teile, stimmt es!
Offenbar rechnet Windows komisch. Ein Kilobyte sind 1024 Bytes, aber ein Gigabyte sind 1000*1000 Kilobytes. Ich finde das vollkommen unlogisch. Bin ich dumm?
Wie dem auch sei, die Zahlen passen so. Der mysteriöse Verlust von Speicherplatz ist geklärt.
Das ist schon klar. Es ging mir die ganze Zeit aber darum, dass chkdsk und Explorer unterschiedlcih viel verfügbaren Platz anzeigen. Womit der Platz belegt ist und wie viel Overhead für was auch immer da drin ist, war mir egal.
Für mich war es ein Unding, dass der Explorer viel weniger freien Platz anzeigte, als chkdsk und Linux. Das ist ja nun geklärt.
Ich mache gerade noch einen Gegentest mit einer kleinen 16 GB VM. Ich erwarte, dass Windows dort keinen Platz reserviert. Das würde meine vorherigen Beobachtungen bestätigen, dass bei so einer kleinen VM die Angaben von Explorer und chkdsk immer (ungefähr) überein stimmten.
Und danach will ich noch weiter Untersuchen, warum Schreibzugriffe unter Linux ab einer gewissen Schwelle das Windows kaputt gemacht haben.
Gegentest auf einer kleinen VM mit nur 16 GB Laufwerk.
Windows hat keinen Speicherplatz reserviert (der wäre links oben zwischen "Systemdateien" und "Virtueller Speicher" angezeigt worden).
Explorer meldet 4,51 GB frei.
Chkdsk meldet 4706000 kB verfügbar.
Wenn ich den Wert von chkdsk zweimal durch 1024 teile. komme ich auf 4,49 GB. Das wirkt einigermaßen stimmig.
Wenn ich nach meiner neuen Erkenntnis den Wert von chkdsk zweimal durch 1000 teile komme ich auf 4,71 GB. So gerechnet fehlen mir wieder 200 MB.
Ich muss aber dazu sagen, dass mich so geringe Differenzen nicht triggern. Mir fallen einige Gründe ein, die zu kleinen Abweichungen führen können:
Andere Umrechnung der Einheiten
Messungen der Tools nicht exakt zum gleichen Zeitpunkt
Verzögertes Schreiben
Das ist hier aber eine ganz andere Hausnummer, als die zuvor beobachtete Differenz von ca. 7 Gigabytes. Ich lasse es mal dabei beruhen.
Die Differenz ist damit für mich ausreichend geklärt. Sie lag am reservierten Speicherbereich, den Windows nach der Installation (wenn möglich) automatisch anlegt. Betroffene Rechner haben ihn, andere nicht. Man kann ihn manuell deaktivieren.
Was mich jetzt noch interessiert, sind die Schreibzugriffe von Linux, die das Windows kaputt gemacht haben.
Die Angabe in Klammern stammt von mir. Dazu habe ich die Zahl zweimal
durch 1024 geteilt. Wenn ich sie stattdessen zweimal durch 1000 teile,
passen sie!
Historisch gewachsen ist leider die Verwendung von binären Werten mit den falschen, dezimalen Präfixen. Manch einer meint, dies mit einem großgeschiebenen "K" angeben zu können, nur sehe ich in MB kein "k", egal, ob groß oder kleingeschrieben.
Auf einer kleinen VM (Windows 10, 16 GB, ohne reservierten Speicher, ohne Internet):
Windows installiert, dann unter Linux die Partition komplett voll geschrieben und die Datei wieder gelöscht.
Windows funktioniert.
Partition wieder mit Linux voll geschrieben und die Datei dann so weit gekürzt, dass 2,5 GB frei sind.
Windows funktioniert.
Auf einer großen VM (Windows 10, 40 GB mit 7,6 GB reserviertem Speicher, ohne Internet):
Windows installiert, dann unter Linux die Partition komplett voll geschrieben und die Datei wieder gelöscht.
Windows funktioniert noch.
Test 3 wiederholt: Windows funktioniert noch
Partition wieder mit Linux voll geschrieben und die Datei dann so weit gekürzt, dass 2,7 GB frei sind.
Windows ist kaputt.
Test 4 wiederholt: Windows ist wieder kaputt
Windows installiert, Partition mit Linux voll geschrieben und die Datei dann so weit gekürzt, dass 6 GB frei sind.
Windows ist kaputt.
Windows installiert, Partition mit Linux voll geschrieben und die Datei dann so weit gekürzt, dass 7 GB frei sind.
Windows ist kaputt.
Windows installiert, Partition mit Linux voll geschrieben und die Datei dann so weit gekürzt, dass 8 GB frei sind.
Windows funktioniert.
Test 7 wiederholt: Windows funktioniert.
Auf einer großen VM (Windows 11, 40 GB mit 7,03 GB reserviertem Speicher):
Windows installiert, Netzwerk deaktiviert, Bitlocker entfernt.
Partition mit Linux voll geschrieben und die Datei dann so weit gekürzt, dass 8 GB frei sind.
Windows funktioniert.
Noch eine 2 GB Datei hinzugefügt (bin damit im reservierten Bereich).
Windows ist kaputt.
Daraus ziehe ich drei Schlüsse:
Ohne reservierten Bereich sind 2,5 GB freier Platz ausreichend, damit Windows starten kann (vielleicht geht auch weniger).
Man darf den reservierten Bereich außerhalb von Windows ruhig komplett überschreiben.
Vor dem nächsten Start von Windows muss der reservierte Bereich aber wieder frei gemacht werden, sonst geht Windows kaputt.
Also ziemlich unspektakulär. Keine geheimen Daten, kein Aluhut.
Ich könnte mir übrigens gut vorstellen, dass es nach dem
fehlgeschlagenen Boot auch genügt hätte, unter Linux diese drei Dateien
wieder zu löschen, um alles wieder in's Lot zu bringen
Ich hatte dir gestern geantwortet, dass ich genau das ohne Erfolg versucht hatte. Die heutige Testreihe zeigt, dass das nicht sein kann. Ich kann mir das nur so erklären, das ich gestern versehentlich zu wenige der 1GB Dateien gelöscht hatte.
Ich glaube, das Thema ist hiermit abgeschlossen. Wer später nach Erklärungen sucht, wird vielleicht diese Diskussion finden. Deswegen platziere ich zum Abschluss nochmal den Link zu Webseite, wo ich die Ergebnisse zusammen gefasst habe.
In Deiner Zusammenfassung fehlt noch der Nutzer "TrustedInstaller", der von den Berechtigungen über dem Administrator steht. Dateien, die nur er sehen darf, werden auch mit 0 Bytes angezeigt.
(Beispiel: Der über 10 GB große Ordner "C:\Program Files\WindowsApps")
