Microsofts neues 12‑Zoll Surface Pro (Copilot+ PC) steht in einem unerwarteten Spannungsfeld: Nutzerberichte zeigen, dass Windows 11 (25H2) bei einigen ARM‑Geräten mit UFS‑Flash den internen Speicher fälschlich als „Festplatte“ meldet und die systemeigene Laufwerksoptimierung damit Defragmentierungs‑Durchläufe anstoßen will — ein Verhalten, das bei SSD‑ bzw. UFS‑Speichern unnötige Schreiblast erzeugen kann und damit theoretisch die Lebensdauer beeinträchtigt.
Das betroffene Gerät ist das 12‑Zoll Surface Pro (Copilot+ PC) mit Qualcomm Snapdragon X Plus (8‑Core), LPDDR5x‑RAM und UFS‑Speicher. Microsofts technischen Spezifikationen listen 16 GB bzw. 24 GB RAM‑Optionen und 256 / 512 / 1 TB (UFS) als Speicherkonfigurationen; das Display ist ein 12‑Zoll PixelSense LCD mit 2.196 × 1.464 (220 PPI). Kurz zusammengefasst: Windows’ Tool „Optimieren und defragmentieren“ entscheidet normalerweise je nach Gerätetyp, ob es eine echte Defragmentierung (HDD) oder einen TRIM‑/Retrim‑Vorgang (SSD/UFS) ausführt. Wenn Windows den Datenträger aber als „Fixed Drive / Festplatte“ klassifiziert, kann es stattdessen eine traditionelle Defragmentierung anstoßen — das ist beim Einsatz von UFS/SSD‑Speichern problematisch.
Nachfolgende Schritte sind priorisiert und reproduzierbar:
Kurzfristig hilft ein vorsichtiges, temporäres Deaktivieren der geplanten Optimierung, begleitet von gezielten Diagnosen (winsat, Optimize‑Volume, fsutil) und dem Einsenden detaillierter Logs an Microsoft. Langfristig ist ein Treiber‑/Firmware‑Patch oder ein Microsoft‑Update die einzige saubere Lösung. Anwender und Admins sollten wachsam bleiben, die beschriebenen Prüfungen durchführen und im Zweifel Support‑Tickets mit vollständiger Diagnostik an Microsoft/Surface richten.
Wichtig: Dieses Ereignis zeigt beispielhaft, wie eng System‑Software, Hardware‑Controller und Wartungslogik zusammenwirken müssen — gerade bei neuen Plattformen (ARM + UFS) treten Integrationsfehler schneller zutage. Sorgfältige Diagnosen, konservative Workarounds und zeitnahe Reportings an Hersteller sind in solchen Situationen die effektivste Prävention gegen längerfristige Schäden und Ausfälle.
Source: BornCity Surface Pro Copilot+PC (ARM) 12 Zoll: Windows 11 25H2 will SSD fragmentieren | Borns IT- und Windows-Blog
Hintergrund / Übersicht
Das betroffene Gerät ist das 12‑Zoll Surface Pro (Copilot+ PC) mit Qualcomm Snapdragon X Plus (8‑Core), LPDDR5x‑RAM und UFS‑Speicher. Microsofts technischen Spezifikationen listen 16 GB bzw. 24 GB RAM‑Optionen und 256 / 512 / 1 TB (UFS) als Speicherkonfigurationen; das Display ist ein 12‑Zoll PixelSense LCD mit 2.196 × 1.464 (220 PPI). Kurz zusammengefasst: Windows’ Tool „Optimieren und defragmentieren“ entscheidet normalerweise je nach Gerätetyp, ob es eine echte Defragmentierung (HDD) oder einen TRIM‑/Retrim‑Vorgang (SSD/UFS) ausführt. Wenn Windows den Datenträger aber als „Fixed Drive / Festplatte“ klassifiziert, kann es stattdessen eine traditionelle Defragmentierung anstoßen — das ist beim Einsatz von UFS/SSD‑Speichern problematisch. Was genau berichten Nutzer? Chronologie und Befunde
- Erste öffentliche Diskussionen zu diesem Verhalten fanden sich im Microsoft‑Q&A‑Forum bereits im Dezember 2025: mehrere Anwender meldeten, dass das Optimizer‑Tool den internen UFS‑Speicher als „Hard disk“ anzeigt und beim Manual‑Optimize ein Defrag‑Durchlauf gestartet würde. Microsoft‑Moderatoren schlugen Tests wie
winsat formalundOptimize-Volume -DriveLetter C -ReTrim -Verbosevor; mehrere Betroffene berichten, dass das Retrim‑Kommando als „operation not supported“ zurücklief — also ein Indiz, dass die Storage‑Controller‑/Treiber‑Erkennung nicht korrekt mit TRIM/UNMAP interagiert. - Deutsche Tech‑Blogs und Community‑Foren nahmen das Thema auf: Dr. Windows fasst den Fall zusammen und weist auf einen Leserfall mit einem angeblichen UFS4‑Chip hin; BornCity berichtete die Beschwerden und fasst Diskussion und Workaround‑Vorschläge zusammen (u. a. das temporäre Abschalten der geplanten Optimierung). Dabei bleibt offen, ob die Erwähnung „UFS4“ offizielle Hardware‑Angabe ist oder eine Nutzer‑/Redaktionsannahme.
- Konkrete Nachweise aus Nutzerdiagnosen: Task‑Manager meldet in einigen Fällen korrekt „SSD (UFS)“ (also die Präsenz von Flash), während das GUI‑Tool „Optimieren“ im selben System „Festplatte“ anzeigt. Ein Betroffener nannte in einem Thread sogar die konkrete Laufwerkskennung (KIOXIA THGJFMT1E45BATV8), was die Vermutung stützt, dass es sich um UFS‑Flash handelt.
Optimize‑Volume -ReTrim liefert Fehler — ist belastend, weil sie deutlich auf eine fehlerhafte Treiber‑/Controller‑Anzeige oder ein Mapping‑Problem zwischen Windows‑Speicherstack und UFS‑Controller hindeutet. Technischer Hintergrund: UFS vs. NVMe, TRIM und Windows‑Optimierung
UFS und wie Windows Speicher erkennt
UFS (Universal Flash Storage) ist in der mobilen/ARM‑Welt weit verbreitet und unterscheidet sich technisch von NVMe‑SSDs, die typischerweise in x86‑Laptops stecken. Windows’ Optimizer entscheidet die Wartungsart (Defrag vs. TRIM) basierend auf erkannten Eigenschaften des Laufwerks und dessen Controller‑Antworten. Wenn die Storage‑Controller‑Schicht oder deren Treiber die richtigen Feature‑Flags (z. B. Unterstützung für TRIM/Discard/UNMAP) nicht korrekt an Windows kommunizieren, kann Windows auf die falsche Optimierungsstrategie zurückfallen.Was macht Optimize‑Volume / Optimize Drives?
Das PowerShell‑CmdletOptimize‑Volume führt bei SSD‑/Flash‑Geräten Retrim/Trim aus (-ReTrim) und bei HDDs die Defragmentierung. Die grafische Oberfläche „Optimieren und defragmentieren“ (dfrgui.exe) verhält sich analog: erkennt das System ein SSD‑fähiges Gerät, führt sie TRIM‑artige Schritte aus; andernfalls wird eine traditionelle Defragmentierung gestartet. Wenn Windows das Gerät falsch kennzeichnet, läuft also das falsche Verfahren — mit zusätzlichen Schreibvorgängen. Warum ist Defragmentieren von Flash problematisch?
Eine Hardware‑Defragmentierung auf Flash führt zu unnötig hohen Schreiblasten. SSDs und UFS‑Speicher arbeiten mit Wear‑Leveling; jede zusätzliche Schreiboperation reduziert die Restlebensdauer und bringt in der Regel keine merkliche Leistungssteigerung. Stattdessen ist TRIM/UNMAP die passende Wartung — sie informiert das Flash‑Controller‑Firmware, welche logischen Blöcke gelöscht wurden, so dass intern sauber aufgeräumt werden kann, ohne unnötige Datenbewegungen. Das ist die etablierte Best Practice.Analyse: Mögliche Ursachen — Treiber, Controller, oder Anzeigefehler?
Die Mehrheit der Belege deutet auf zwei wahrscheinliche Ursachen (nicht ausschließend, sondern komplementär):- Treiber / Storage‑Controller‑Layer: Die Microsoft‑Moderatoren in den Foren empfehlen, die Storage‑Controller‑Angaben zu prüfen — wenn
Optimize‑Volume -ReTrimfehlschlägt, ist das ein starkes Indiz dafür, dass Windows den Controller‑Antworten nicht entnehmen kann, dass Retrim möglich ist. Die Controller‑Schicht (z. B. Qualcomm/Surface‑spezifische Treiber oder generische Schnittstellen) ist hier ein Hauptverdächtiger. - Anzeige/Cosmetic vs. funktionaler Fehler: Manche Antworten in Foren sehen das als kosmetisches Problem (nur falsche Bezeichnung in Teilen der UI). Andere Nutzer berichteten aber, dass die Optimizer‑Ausführung tatsächlich eine Defragmentierung (Relocate‑Pass) startete. Wenn das so ist, handelt es sich nicht nur um eine falsche Beschriftung, sondern um ein funktionales Problem mit unmittelbaren Schreibbelastungen. Die Microsoft‑Q&A‑Thread‑Beiträge dokumentieren beides: Fehlinformation in UI und in einigen Fällen tatsächliche Ausführung falscher Wartungsschritte.
Was können betroffene Nutzer und Admins jetzt praktisch tun? (Prüfen, Diagnostizieren, Sofort‑Maßnahmen)
Wichtiger Hinweis vorweg: einige vorgeschlagene Workarounds schränken geplante TRIM‑Wartung ein. TRIM ist wichtig für langfristige SSD‑/UFS‑Performance. Maßnahmen sollten also gezielt und temporär sein, nicht pauschal TRIM dauerhaft abschalten.Nachfolgende Schritte sind priorisiert und reproduzierbar:
- Basis‑Checks (schnell)
- Öffnen Sie den Task‑Manager → Reiter „Leistung“ → wählen Sie das Laufwerk: erscheint dort „SSD (UFS)“? Das ist ein Indiz, dass das System zumindest den Flash‑Typ erkennt.
- Prüfen Sie in der grafischen App „Defragmentieren und Optimieren“, was in der Spalte „Medientyp“ steht (SSD oder Festplatte). Wenn dort „Festplatte“ steht, ist das auffällig.
- Technische Diagnosen (PowerShell / CMD)
winsat formal— erzwingt eine Hardware‑Neubewertung durch WinSAT. Ergebnisse in der Winsat‑Datastore‑XML können Hinweise liefern.Optimize-Volume -DriveLetter C -ReTrim -Verbose(PowerShell, Admin) — testet, ob Retrim/Trim auf Volumenebene funktioniert oder einen Fehler zurückgibt. Wenn hier „operation not supported“ steht, ist das ein starkes Indiz für ein Treiberproblem.fsutil behavior query DisableDeleteNotify(CMD, Admin) — überprüft, ob TRIM global aktiviert ist (0= TRIM aktiv). Niemals ohne Absicht dauerhaft deaktivieren; nur prüfen.- Device Manager → „Storage controllers“ und „Disk drives“ prüfen: Welche Einträge zeigt der Geräte‑Manager? (z. B. spezifischer Qualcomm‑Controller oder generische Treiber). Notieren Sie die exakte Bezeichnung, sie ist wichtig für Support‑Tickets.
- Sofort‑Workaround (temporär, Risiken beachten)
- Option A (empfohlen als temporäre Maßnahme für Heimanwender): Deaktivieren Sie die geplante Laufwerksoptimierung nur solange, bis Treiber/Firmware‑Fix vorliegt.
- GUI: Defragmentieren und Optimieren → „Einstellungen ändern“ → „Run on a schedule“ deaktivieren. Achtung: damit entfällt auch die geplante Retrim‑Ausführung; daher regelmäßig manuell prüfen und ggf. manuell
Optimize-Volume -ReTrimausführen, wenn sichergestellt ist, dass Retrim unterstützt wird. - Task Scheduler: Task
\Microsoft\Windows\Defrag\ScheduledDefragdeaktivieren — bewirkt dasselbe, ist aber systemweiter Eingriff. - Option B (für Firmen / Admins): Über Intune/Policy ein skriptbasiertes Deaktivieren der ScheduledDefrag‑Task nur für betroffene Maschinen ausrollen, gleichzeitig Monitoring für TRIM‑Status aktivieren. (Konkrete Skripte:
schtasks /Change /DISABLE /TN "\Microsoft\Windows\Defrag\ScheduledDefrag"). - Langfristig / zwingend
- Einsenden eines Logs/Feedback an Microsoft über Feedback Hub (Windows‑Taste + F) und paralleles Kontaktieren des Surface‑Supports (Surface App → Help & support bzw. Surface Support Kanäle). Microsoft‑Moderatoren in den Threads fordern genau diese Schritte, damit die Entwicklungsteam Logs bekommt.
- Firmware‑/Treiber‑Updates prüfen: Surface App, Windows Update und ggf. Microsoft‑Surface‑Firmware‑Downloads überprüfen und aufspielbare Updates installieren; Microsoft empfahl in den Foren die Prüfung auf Surface‑Firmware‑Updates als Zwischenschritt.
Risiken und Nebenwirkungen der Workarounds
- Deaktivieren der geplanten Optimierung stoppt auch die regelmäßige Retrim‑Ausführung — das bedeutet, die SSD/UFS könnten langfristig ohne geplante TRIM‑Wartung etwas Leistung einbüßen, wenn die Firmware nicht selbstständig effizient Garbage Collection macht. Daher darf dieser Workaround nur temporär erfolgen, bis eine Treiber/Firmware‑Korrektur vorhanden ist.
- Ein einfaches „Defrag deaktivieren“ ohne Diagnose kann das eigentliche Problem (fehlende TRIM‑Unterstützung) verdecken und die Ursache nicht beheben. In Unternehmen kann ein unspezifisches Deaktivieren zu unerwünschten Nebeneffekten in großen Flotten führen; hier sind gezielte Richtlinien und Logging nötig.
- Wenn die Optimizer‑Routine wirklich eine (vollständige) Defragmentierung auf Flash startet, können während des Vorgangs größtmögliche Schreib‑ und I/O‑Spitzen auftreten, was bei geringem freien Platz zeitweilige Leistungsengpässe oder sogar Abbrüche von Hintergrundvorgängen verursachen kann. Mehrere Forenbeiträge berichten von Rückgabe bzw. Rücksendung der Geräte in Einzelfällen.
Bewertung: Wie schwerwiegend ist das Problem?
- Kurzfristig für den Einzelanwender: moderates Risiko. Sichtbare Folgen sind oft nur erhöhte Idle‑Schreiblasten oder Warnhinweise. Nutzer konnten in mehreren Fällen temporär die Funktion abschalten und das Gerät normal weiterbenutzen.
- Mittelfristig für die Hardware‑Integrität: potentiell relevant. Wenn der Optimizer fälschlich Defragmentierungsdurchläufe auf UFS/SSD ausführt und das wiederholt, führt das zu erhöhten Schreibzyklen — das schränkt die lifespan theoretisch ein, auch wenn moderne Flash reichlich Schreibreserven hat. IT‑Administratoren sollten dies in Flotten nicht ignorieren.
- Für Unternehmen (Rollouts / Managed Devices): signifikantes Risiko. Wenn eine Device‑Seriencharge betroffen ist, kann es zu erhöhten Support‑Aufwänden, Rückgaben und Image‑Problemen kommen. Microsoft‑Moderatoren raten klar zum Einsenden von Logs, damit ein globaler Fix priorisiert wird.
Empfehlungen für Endnutzer und IT‑Profis (konkret)
- Prüfen Sie zuerst: Task‑Manager, „Defragmentieren und Optimieren“,
fsutil behavior query DisableDeleteNotify,Optimize‑Volume -ReTrim— dokumentieren Sie Fehlermeldungen und Screenshots. - Wenn das System tatsächlich Retrim nicht unterstützt (Fehler bei
Optimize‑Volume -ReTrim), deaktivieren Sie temporär die geplante Optimierung NUR bis Treiber/Firmware/OS‑Patch vorliegt; lassen Sie TRIM global nicht dauerhaft abschalten. Erstellen Sie regelmäßig Backups und beobachten Sie SMART/Health‑Metriken der SSD (sofern zugänglich). - Für Admins: Verteilen Sie ein Diagnose‑Script (winsat, Optimize‑Volume, fsutil, Device Manager‑Export), sammeln Sie Telemetrie, und eröffnen Sie ein Support‑Ticket bei Microsoft mit den Logs; ausrollen Sie temporär eine Richtlinie, die die ScheduledDefrag‑Task nur auf betroffenen Modellen deaktiviert. Testen Sie Firmware‑Rollouts vor breitem Deployment.
- Reporting: Senden Sie das Verhalten über den Feedback Hub und kontaktieren Sie Surface Support direkt. Microsoft‑Moderatoren in den Foren haben ausdrücklich darum gebeten, damit das Entwicklungsteam die Daten erhält.
Offene Fragen und Punkte, die noch verifiziert werden müssen
- UFS‑Version: In einigen Beiträgen wird konkret „UFS4“ genannt; Microsofts offiziellen Tech‑Specs sprechen allgemein von „UFS“. Die konkrete Version der verbauten UFS‑Chips (UFS3.x vs. UFS4) kann je nach Konfiguration variieren und ist in der Produktspezifikation nicht explizit als UFS‑Version ausgewiesen. Bis Microsoft oder der Hersteller (KIOXIA/Qualcomm) dies bestätigt, ist die Nennung von „UFS4“ als Hardware‑Faktum mit Vorsicht zu behandeln.
- Umfang des Problems: Aktuell sind Berichte aus Foren und einzelne Community‑Posts verfügbar; eine flächendeckende Analyse (z. B. wie viele der ausgelieferten Surface Pro 12‑Einheiten betroffen sind) liegt nicht vor. Microsoft‑Logs aus Feedback Hub und interne Telemetrie werden hier die letzte Gewissheit bringen.
Fazit
Die gemeldete Fehldetektion von UFS‑Flash als „Festplatte“ in Windows 11 25H2 auf Surface Pro 12‑Geräten ist kein reines UI‑Problem: die vorliegenden Nutzerberichte und die Reaktionen von Microsoft‑Moderatoren legen nahe, dass Storage‑Controller‑/Treiber‑Informationen nicht korrekt an die Optimizer‑Logik kommuniziert werden. Das kann dazu führen, dass die falsche Wartungsmaßnahme (Defragmentierung statt Retrim) ausgeführt wird — ein Verhalten, das SSD/UFS‑Laufwerken potenziell schadet.Kurzfristig hilft ein vorsichtiges, temporäres Deaktivieren der geplanten Optimierung, begleitet von gezielten Diagnosen (winsat, Optimize‑Volume, fsutil) und dem Einsenden detaillierter Logs an Microsoft. Langfristig ist ein Treiber‑/Firmware‑Patch oder ein Microsoft‑Update die einzige saubere Lösung. Anwender und Admins sollten wachsam bleiben, die beschriebenen Prüfungen durchführen und im Zweifel Support‑Tickets mit vollständiger Diagnostik an Microsoft/Surface richten.
Wichtig: Dieses Ereignis zeigt beispielhaft, wie eng System‑Software, Hardware‑Controller und Wartungslogik zusammenwirken müssen — gerade bei neuen Plattformen (ARM + UFS) treten Integrationsfehler schneller zutage. Sorgfältige Diagnosen, konservative Workarounds und zeitnahe Reportings an Hersteller sind in solchen Situationen die effektivste Prävention gegen längerfristige Schäden und Ausfälle.
Source: BornCity Surface Pro Copilot+PC (ARM) 12 Zoll: Windows 11 25H2 will SSD fragmentieren | Borns IT- und Windows-Blog
