[English]Microsoft schrieb zwar, dass es keine Belege dafür gebe, dass das kumulative Sicherheitsupdate KB5063878 vom 12. August 2025 für Windows 11 24H2 zu schwerwiegenden SSD-Problemen führt. Es deutet sich aber an, dass das Preview-Update KB5064081 vom 29. August 2025 einen "stillen" Fix für einen SSD-Bug beinhaltet, der in japanischen Systemen für Ärger und kaputte SSDs sorgt.
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
KB5063878 und die Berichte über SSD-Probleme
Zum 12. August 2025 wurde das kumulative Update KB5063878 für Windows 11 24H2 veröffentlicht (siehe Patchday: Windows 10/11 Updates (12. August 2025). Im Nachgang wurden Berichte aus Japan bekannt, dass dieses kumulative Sicherheitsupdate KB5063878 zu schwerwiegenden SSD-Problemen führen kann. Beim Transfer großer Datenmengen soll es reproduzierbar zu Fehlern beim Speichern auf bestimmten SSDs mit bestimmten Controllern und damit zu Datenverlusten kommen.
Angeblich nur NAND-Controller von Phison betroffen
Es hieß, dass die NAND-Controller von Phison häufiger zu diesen Fehlfunktionen neigen. Seit ich diese Berichte im Blog-Beitrag Windows 11 24H2: Führt Aug. 2025-Update KB5063878 zu SSD-Fehlern? angesprochen hatte, herrschte Rätselraten, was an der Sache dran ist. Microsoft prüfte dann diese Berichte und bat um Rückmeldung von Betroffenen (Windows 11 24H2: Microsoft prüft Berichte über SSD-Probleme durch KB5063878).
Microsoft und Phison gaben Entwarnung
Im Blog-Beitrag Windows 11 24H2: Doch keine SSD-Probleme durch KB5063878 hatte ich dann berichtet, dass sowohl Microsoft als auch Controller-Hersteller Phison umfangreiche Tests mit SSDs durchgeführt haben. In diesem Tests konnten weder Microsoft noch der Controller-Hersteller Phison die in Berichten gemeldeten Fehler durch das Update KB5063878 reproduzieren.
Ist trotzdem was am SSD-Problem dran?
Ich hatte bei meinen Blog-Beiträgen angemerkt, dass ich die Bedeutung des möglichen Fehlers nicht wirklich einschätzen könne. Mit US-Bloggern stand ich im Kontakt und es kristallisierte sich heraus, dass sich alle Berichte auf japanische Windows-Versionen bezogen.
Hier im Blog gab es allerdings heftige Diskussionen vereinzelter Leser, die von aufgebauschten Meldungen ausgingen und alles am liebsten negiert hätten. Auf der anderen Seite meldeten sich Leser wie Chris, die von erhöhten Ausfallraten bei SSDs unter Windows 11 24H2 berichteten. Blog-Leser Benjamin weist in diesem Kommentar auf ein YouTube-Video von JayzTwoCents hin, der das Problem reproduziert haben will.
Interessant ist dieser Kommentar von Lars, der seine Beobachtung schildert. Er gibt an, "letzten Samstag" (30. August 2025) sechs identische Rechner beim Kunden eingebunden zu haben. Am Montag, den 1. September 2025 hatte vier dieser System das Problem, dass ein Reboot ins BIOS führte, weil die NVMe mit dem Betriebssystem vom BIOS nicht mehr erkannt wurde. Lars schrieb, dass – entgegen vieler Behauptungen – auch Samsung betroffen sei, da alle sechs Rechner Samsung 990Pro 1TB SSDs verwendeten.
Weiterhin gibt es Kommentare eines Blog-Lesers, der angibt, das SSD-Problem durch Installation des japanischen Sprachpakets nachgewiesen zu haben. Kann man alles als "Zufall" abtun, oder als "könnte noch was sein" zur Kenntnis nehmen.
Korrektur für japanisches Windows 11 24H2
Getreu dem Motto "wir brauchen einen nicht vorhandenen, aber korrigierten, Fehler nicht zu erwähnen" scheint jemand bei Microsoft mehr gewusst zu haben, als öffentlich bekannt ist.
Ein kryptischer Hinweis auf einen Fix
Es gibt hier im Blog den Kommentar der MTechlerin (danke dafür, der gewählte Alias-Name ist schon aufschlussreich), die kryptisch schrieb "Es ist Windows 11 24H2 .4946 betroffen. Nach Update auf 24H2 .5074 sind die meisten Probleme mit HDD und SSD behoben." Habe ich beim ersten lesen nach Eingang des Kommentars nicht wirklich verstanden, aber jetzt mal aufgedröselt. Windows 11 24H2 Build 26100.4946, die vom Problem betroffen ist, wird durch das Sicherheitsupdate KB5063878 ausgerollt. Windows 11 24H2 Build 26100.5074, die die SSD- und Disk-Probleme nicht mehr haben soll, wird durch das Preview Update KB5064081 vom 29. August 2025 erreicht.
Und jetzt wird es sehr interessant, denn über die patchmanagement.org-Liste wurde ich auf die obigen Tweets aufmerksam. Mein Japanisch ist zwar faktisch nicht vorhanden, aber die Aussage lautet, dass das durch das August 2025 Update KB5063878 ausgelöste SSD-Problem durch die Installation des "aktuellen neuesten Windows-Updates" behoben wird. Das ist aber das Windows 11 24H2 Preview Update KB5064081 vom 29. August 2025.
Weiter im Text heißt es, dass die Ursache "gestern" (war der 1. September 2025) weitgehend identifiziert wurde. Die offensichtliche Ursache sei, dass um die Veröffentlichung von KB5063878 herum versehentlich ein Dateisystem für Single-Byte-Umgebungen (englische Versionen) verteilt wurde. Das ist in japanischen Windows 11-Versionen natürlich fatal.
Im eingebetteten Tweet von @rei_claude heißt es: "Wenn während der Installation dieser beiden Updates kontinuierlich große Datenmengen (mehrere Dutzend GB) geschrieben werden, können bestimmte SSDs irreparabel beschädigt werden, wodurch der Rechner unbrauchbar wird. Dies sei keine Hypothese, sondern führt tatsächlich zu einer Zerstörung der SSD.
Es folgt der Ratschlag, umgehend den Update-Verlauf zu überprüfen. Sind die Updates
KB5062660 und KB5063878 für Windows 11 Version 24H2 bereits installiert, sollen Nutzer diese deinstallieren und den Rechner neu starten.
Im Anschluss kann man das Preview-Update KB5064081 vom 29. August 2025 unter Windows 11 24H2 installieren. Dieses enthält ja die Sicherheits-Patches früherer Sicherheits-Updates, sowie neue Fixes. In diesem Preview-Update werde "stillschweigend" wieder das für ein japanisches Windows benötigt Dateisystem für Double-Byte-Umgebungen (japanische Versionen usw.) verteilt. Damit dürften die SSD-Probleme behoben sein. Die Erklärung klingt für mich logisch – und deckt sich mit den oben zitierten Aussagen von MTechlerin. Offen bleiben für mich aber die obigen skizzierten Beobachtungen zu SSD-Problemen.
Ähnliche Artikel:
Microsoft Security Update Summary (12. August 2025)
Patchday: Windows 10/11 Updates (12. August 2025)
Patchday: Windows Server-Updates (12. August 2025)
Patchday: Microsoft Office Updates (12. August 2025)
Windows 10/11: Preview Updates 22. Juli 2025
Windows 10/11: Preview Updates 26./29. August 2025
Windows 11 24H2: Update KB5063878 wirft Installationsfehler 0x80240069
Windows 11 24H2: Update KB5063878 als Re-Release für WSUS (14. Aug. 2025)
Windows 11 24H2: Führt Aug. 2025-Update KB5063878 zu SSD-Fehlern?
Windows 11 24H2: Microsoft prüft Berichte über SSD-Probleme durch KB5063878
Windows 11 24H2: Doch keine SSD-Probleme durch KB5063878
Windows 11 24H2: Weitere Erklärung für SSD-Probleme?
MVP: 2013 – 2016
Das Samsung Pro 990 betroffen sind kann ich bestätigen Zumindest hier bei mir und zwar die 4TB Version.
Unter einem Youtube Beitrag zu dem Thema hat sich ein User bei mir gemeldet und hatte mit der gleichen SSD das gleiche Problem.
Kann man den vermeintlichen Fix auch auf deutschen Systemen installieren? Oder habe ich da etwas falsch verstanden?
Ich denke, es sind zwei unterschiedliche Sachen. In Japan hat das Double-Byte-Dateisystem-Problem wohl für die Aufregung gesorgt. Ausfälle von SSDs bei deutschen Nutzern dürften damit nichts zu tun haben. Wenn die Aussage im Kommentar der MTechlerin aber stimmt, sollte man das Preview-Update vom 29. August 2025 installieren – oder gleich auf Linux gehen.
Ich ziehe mal den gesamten Kommentar von Steffix, den er mir auf FB bereitgestellt hat, zur Info hierhin.
Das mit dem USB Controller kann ich bestätigen. Betrifft aber hier einen anderen: USB\VID_0BDA&PID_0420. Gehört in diesem Fall zu einer Docking Station im Monitor. Dahinter steht Realtek und wäre der Netzwerkanschluss.
Hier ich hab auch genau dieses problem, auch mit 4TB Samsung 990 passiert meist nach viel schreiben und die SSD lebt erst nach nem power cycle wieder.
Das Update wird auch für deutsche Systeme angeboten, behebt aber zumindest bei mir das Problem nicht (vollständig).
**Edit:** Ich habe im Feedback-Hub nichts groß dazu gefunden. Wer auch betroffen ist, ggf. hier zusätzlich melden/kommentieren oder Minidumps ergänzen: https://aka.ms/AAxtkzg Vielleicht hilft das ja doch irgendwie.
Seit Juli bekomme ich beim Versuch, Backups mit True Image zu erstellen, einen BSOD und muss das System komplett ausschalten, damit das Systemlaufwerk wieder auftaucht.
Allerdings waren das bisher immer UNEXPECTED_STORE_EXCEPTION. Jetzt mit 5074 bekam ich hingegen KERNEL_DATA_INPAGE_ERROR, wobei ein Minidump erfolgreich geschrieben wurde (bereits an MS abgeschickt). Ich musste allerdings trotzdem das System komplett abschalten, damit das Laufwerk wieder auftaucht.
Es scheint also zumindest eine Besserung zu geben und evtl. helfen die Dumps, das genauer einzugrenzen.
Ich verstehe ja, dass Mist im Filesystem zu BSOD und Bootfailure führen kann. Datenmüll kann man halt nicht booten.
Was mir aber nicht klar ist, wieso das die SSD permanent schrotten kann, falsche Daten sind ja auch nur Daten. Oder werden dann z.B. so viele TRIMs ausgelöst. dass die SSD nach kurzer Zeit den Geist aufgibt? Wenn dem so sein sollte, dass SSDs so fragil sind, sehe ich schon Malwareautoren frohlocken…
So ganz spontan: Wenn ein Bug dazu führt, dass einige Zellen der SSD, wo Partitionsdaten oder Fehlerwerte gespeichert werden, für große Dateikopieroperationen Millionen Mal beschrieben werden, könnte ich mir den Effekt vorstellen.
ich hatte bisher nur eine SSD die wegen Luftmangel geschrottet war.
No Operation System found.
ich konnte sie aber ausnullen und neu anmelden, initialisieren und formatieren. Sie lief wieder tadellos. Die Daten waren natürlich weg.
das das der falsche Zeichensatz Code ein Dateisystem unbrauchbar machen könnte kann ich mir gerade so noch vorstellen.
Aber das die Platte irreversibel zerstört werden kann nicht.
auch seltsam dass das Problem mit dem Zeichen Code erst nach mehreren großen Schreibaktionen auftreten soll passt nicht so recht finde ich.
Es kann natürlich Ärger geben. wenn die Namen doppelt solang sind wie erwartet.
dann ist das Dateisystem im Eimer. Aber die SSD?
die Platten haben ein wear Management und Mappen rechtzeitig zu oft beschriebene Blöcke um. Auch merken sie, wenn nur Nullen geschrieben werden und run lenghth kodieren das.
Auch das Millionen fache beschreiben dauert seine Zeit.
Zumal der Kontroller die neuen Daten erstmal cacht.
Wie gesagt, ich habe das mal bei einer Notebook Platte beobachtet, den ein Depp auf sein Bett gestellt hatte und so jeder Luft beraubt hat
Das war aber in der Frühzeit der SSD. Heute würde ich erwarten, das eine überhitzte Platte langsamer wird und sich dann komplett ausschaltet.
Aber vielleicht erwarte ich zu viel?
Es gibt auch eine Diskrepanz bei der Datei ntfs.sys, je nachdem, ob man im Ordner System32 oder im Ordner WinSXS schaut.
Normalerweise sollten beide Versionsnummern und Dateigrößen identisch sein, sind sie aber nicht.
Im System32-Ordner lag noch die Dateiversion 26100.,4652 (also aus dem KB5062553 von Juli 2025), obwohl bereits das Update vom August installiert worden war.
Im WinSXS-Ordner lag die neue Dateiversion 26100.4946
Screenshots siehe x
User zmoroha
Beitrag vom 31.8. um 15:11
Das ist ein Problem von Microsoft, nicht der SSD-Controller.
Es gibt ein Problem mit den Dateiversionen.
2.
Die Dateiversion der ntfs.sys wurde im System32-Ordner als 6.2.26100.xxxx japanisch angezeigt und im WinSXS-Ordner als 10.0.26100.xxxx englisch.
"6.2.x" war die Versions-Präfix für Windows 8.
Das ist allerdings nur ein Anzeigeproblem.
Der Unterschied zwischen "japanisch" und "englisch" könnte allerdings auf das 1-Byte vs 2-Byte Problem des Zeichensatzes (Character-Matrix) hindeuten.
Screenshots siehe x
User TjPqXb5>O700Qs7
Beitrag vom 1.9. um 1:17
(und die vielen anderen Beiträge dieses Users zu dem Problem)
oder auch
reddit. com/r/pcmasterrace/comments/1n5ar9o/a_hypothesis_potential_cause_for_recent_windows/#lightbox
Das ist ein Problem von Microsoft, nicht der SSD-Controller.
Es gibt also ein weiteres Problem mit der Sprach-Lokalisierung der Dateien.
3.
Die Lokalisierung erledigt Microsoft normalerweise nicht direkt in den Treiberdateien wie ntfs.sys, sondern mittels der mui-Dateien, wo die Sprachanpassungen drin stecken.
4.
neben ntfs.sys ist auch storport.sys betroffen.
Es wird Storport Reset (Event ID 129) ins Log eingetragen.
NTFS Corruption 55.
Das führt dann zu RAW-Dateisystem.
reddit. com/r/Windows11/comments/1n7lv6h/new_information_regarding_kb5063878/
Das ist ein Problem von Microsoft.
Ob hier auch ein Problem der SSD-Controller vorliegt weiß man noch nicht.
Microsoft scheint auch gelogen zu haben, als sie behaupteten, es gäbe keine Telemetriedaten über SSD-Probleme.
Event ID 129 Storport-Reset sollte aber mit Telemetrie gemeldet werden.
5.
Die Deinstallation von KB5063878 scheitert manchmal.
Dann muss man vorher das Sandbox-Feature deaktivieren.
Also ist mal wieder Windows 11 und nicht irgendein Hardwarehersteller schuld.
Aber erstmal Microsoft typisch "Wir sind es nicht, keine Ahnung was ihr meint."
Wer alle Sinne beisammen hatte, ahnte, dass es auf diese Entwicklung hinauslaufen würde.
Jetzt könnten mal einige Lautsprecher unter den Foristen, die alles als Verschwörungstheorie abtun und den Fall mit dem Microsoftschen Abschlussstatement als erledigt erklären wollten, um Entschuldigung bitten.
Wenigstens hat User Bolko genauer auf die Metadaten der Kompilate geschaut.
Nichtsdestotrotz war die Diskussion des Falles in ihrer technischen Oberflächlichkeit und Ignoranz des Faktums , dass sich ohne Quellcode Mutmassungen eigentlich verbieten, über weite Stecken unterirdisch. Da lob' ich mir das Diskussionsniveau in BSD- und teils auch in Linux-Foren.
Die niederländischen Tweakers haben mehrere SSD getestet.
Sie konnten das Problem bei 2 SSD reproduzieren, indem sie eine 59 GB große Datei mehrfach auf die SSD schrieben.
Dabei handelt es sich um:
– Corsair MP600 Core 2TB (Controller: Phison E16)
– Adata XPG SX8200 Pro 2TB (Controller: Silicon Motion SM2262ENG).
Das Problem trat bei der "Adata XPG SX8200 Pro 2TB" zum ersten Mal nach 11 Minuten und bei 76 Grad Celsius auf.
Gemessen wurde sowohl mit dem eingebauten Temperatursensor der SSD, als auch mit einer FLIR-Kamera.
Bei den weiteren Versuchen trat das Problem identisch auf nach ca 10 Minuten und bei hoher Temperatur.
Fehlermeldungen beim Schreiben, SSD reagierte nicht mehr, in der Datenträgerverwaltung stand "nicht initialisiert".
Nach Neustarts war die SSD aber wieder normal einsatzbereit.
Nach weiteren Wiederholungen gab es BlueScreen und die SSD erschien auch nicht mehr im BIOS.
Ein Neustart half nicht mehr und die SSD gilt seitdem als defekt.
Die 512 MB-Version dieser SSD hatte keine der Probleme.
Dort wird ein etwas anderer Controller Silicon Motion SM2262G eingesetzt, der niedriger getaktet ist und nicht so heiß wird.
Es liegt nicht an KB5063878, denn der Fehler trat auch dann auf, wenn dieses Update nicht installiert war.
Die "Corsair MP600 Core 2TB" stürzte sogar einmal unter Linux Mint 22.1 mit dem selben Fehlerbild ab. Das war aber nicht reproduzierbar
Zitat (übersetzt mit Google-Chrome-Übersetzer)
"Beide Laufwerke wurden bei den großen Schreibvorgängen sengend heiß. Vor allem die Adata SSD zeigte zahlreiche Hitzewarnungen an, bevor sie den Geist aufgab. Auch das Corsair-Laufwerk überhitzte deutlich."
Tweakers kontaktierte Phison wegen des Temperaturproblems und Phison hat das Problem bestätigt, es aber als "Einzelfälle" bezeichnet.
Phison meint, "Erfahrungsgemäß tritt das Problem vor allem auf Prüfständen auf.
Prüfstände verfügen nicht über separate Lüfter, die kühle Luft über die SSD blasen."
Phison erklärte, die betreffende SSD sei „mit der Erwartung eines gewissen Luftstroms" konzipiert worden und funktioniere in einem Desktop-PC mit normalem Luftstrom oder mit einem auf die SSD gerichteten Lüfter ausreichend. Der Hersteller betont daher, dass er bereits in seiner früheren Stellungnahme auf eine ausreichende Kühlung hingewiesen habe.
tweakers. net/reviews/13746/zorgt-een-windows-update-voor-crashende-ssds-onze-resultaten-met-negen-drives.html#r_21383804
Phison hat also vorher gelogen, als sie schrieben, sie könnten das Problem gar nicht reproduzieren.
Das Hitzeproblem war dem Hersteller nämlich sehr wohl bekannt.
Wenn das Problem bereits nach 10 bis 11 Minuten reproduzierbar auftritt, dann haben Microsoft und Phison gelogen, als sie behaupteten, sie hätten mehrere tausend Testdurchläufe und Stunden getestet ohne das Problem reproduzieren zu können.
Microsoft hat noch zusätzlich gelogen, denn die Dateiversionen und Lokalisierungen stimmten nicht.
Anstatt also dass sowohl Microsoft asl auch die Controller-Hersteller nach Selbstauskunft (!) unschuldig sind, sind vielmehr beide schuldig.
Microsoft wegen Schlampigkeit beim Update und die Hardware-Hersteller wegen schlampiger mangelhafter Kühlung der Controller.
Es kann sich um zwei separate sich überlagernde Probleme handeln.
1. Überhitzung der SSD-Controller
2. fehlerhafte Lokalisierung der Character-Matrix.
Nur 1-Byte-Character (Zeichen) statt der für japanisch benötigten mindestens 2-Byte-pro-Character-Matrix, weil es in der japanischen Sprasche mehr als 256 Zeichen gibt, die man mit 1 Byte darstellen könnte. Eigentlich braucht man für UTF-8-japanisch sogar 3 Byte pro Character.
Ich vermute, es gibt noch ein 3.Problem, denn auf Reddit gibt es zahlreiche Meldungen mit SSD-Problemen seit ca Juli, die weder mit Phison-Controller, noch mit japanischem Zeichensatz, noch mit hohem Datendurchsatz (also vermutlich auch keine Überhitzung) etwas zu tun haben.
Dieses Problem herauszufiltern wird aber recht schwierig werden.
Okay, japanische Schriftzeichen als Auslöser, weil "nicht genug Platz" in 1-Bit.
Verstehe.
Dennoch sind sehr, sher viele tech-youtuber erstmal auf den Zug aufgesprungen und haben Panik verbreitet. Ohne irgendwelche Belege! Das ist heftig!
Und nun hat M$ es also doch verkackt?
Was mich dabei wundert: Waren nicht Computerbase oder Golem mit einem Artikel Online gegangen, wo man dies hier (teilweise) nachstellen konnte? Ich vermute dann eher deutsches Windows 11 oder nutzt man gar nur englisches?
Wie auch immer, wenn MS und Phison nur mit englischen getestet haben, dann könnte man vielleicht davon ausgehen – daher nix gefunden. Aus Business-Sicht im ersten Moment nachvollziehbar, aber auch nur kurz angedacht. Vollumfänglich ist das nicht…
…auch wenn viele im Business-Bereich selbst im DACH-Bereich rein englische Systeme nutzen. Man vergisst halt Endnutzer – oder will man das sogar? – könnte man immer wieder vermuten.
Egal, es bleibt verwirrend. Vor allem weil es mittlerweile Berichte nicht nur mit Windows, sondern auch mit Linux gibt. Namentlich ist mir Linux Mint aufgefallen. Nehme da aber eher an, viele Umsteiger nutzen dies, da es doch stark an Windows erinnert. Vermutlich daher mehr Zuwachs an neuen Nutzer? Könnte dann auch bei anderen Distributionen passieren. Frage ist halt, ob Windows 10/11 zuvor schon die SSD beleidigt hat – scheinbar können das Dateisysteme nun aus mir noch nicht nachvollziehbaren Gründen.
Wer es sich ansehen möchte:
Auf YouTube berichten u. A. sowohl Britec09 als auch BrenTech davon, dass Nutzer eines chinesischen DIY-Forums den Fehler bei Phison-SSD auf eine fehlerhafte Pre-Release- bzw. Engineering-Sample-Firmware eingrenzen konnten und das von Phison bereits verifiziert wurde. -> Firmware-Update mittels SSD-Hersteller-Tools.
Wie es aussieht, gibt's dann also mehr als eine Ursache (falsche Firmware und ein Windows-Update, welches japanische Dateisysteme zerschießt) und daher dieses teils undeutliche Fehlerbild der ausgefallenen SSD.
MfG
Zitat:
"japanisches Windows benötigt Dateisystem für Double-Byte-Umgebungen"
—
Das NTFS Dateisystem benutzt immer UTF-16LE für die Zeichencodierung, also double-Byte.
Es gibt da keinen Unterschied zwischen englisch oder japanisch.
2.
Die Zeichencodierung auf dem Desktop ist aber unterschiedlich zwischen englisch und japanisch.
Englisch und deutsch benutzen als Zeichencodierung "Windows-1252" (Code Page 437 für englisch und Code Page 850 für deutsch). Das sind 8-Bit pro Zeichen.
Japanisch benutzt Zeichencodierung "Windows-31J" (Code Page 932, Erweiterung von "Shift JIS"). Das sind teilweise 8-Bit und teilweise 16-Bit pro Kanji-Zeichen innerhalb der selben Code Page.
In der Registry stehen Zeichencodierung ("ACP") und Codepage ("OEMCP") dort (Beispiel deutsch):
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage]
"ACP"="1252"
"OEMCP"="850"
Die Transformationstabelle von CodePage 932 (japanisch) nach Unicode UTF-16LE ist dort:
unicode. org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
Den Backslash gibt es in Codepage 932 japanisch zweimal:
0x5C 0x005C #REVERSE SOLIDUS
0x815F 0xFF3C #FULLWIDTH REVERSE SOLIDUS
Im japanischen Industriestandard-Zeichensatz ISO-646-JP und "JIS X 0201" liegt auf 0x5c aber nicht der Backslash, sondern das YEN-Währungs-Symbol:
en.wikipedia.org/wiki/JIS_X_0201
Japaner sehen also im Pfad statt des Backslashes das YEN-Symbol:
archives. miloush. net/michkap/archive/2005/09/17/469941.html
handwiki. org/wiki/Code_page_932_(Microsoft_Windows)#Single-byte_character_differences
Interpretiert wird das Zeichen aber dennoch als Backslash, auch wenn es als YEN angezeigt wird.
Es sollte da also keine Probleme geben im Dateisystem (aber wer weiß, was Microsoft da gebastelt hat).
Zur Umgehung des Problems (Backslash vs YEN) im Internet wurde in der HTML-Zeichencodierung ISO/IEC 8859-1 (= Latin-1) das YEN-Symbol auf 0xa5 gemappt statt auf 0x5c.
3.
Falls es bei der Transformation von der Codepage 932 japanisch nach UTF-16LE (NTFS) ein Problem geben sollte, warum tritt das Problem dann oftmals beim ersten Kopiervorgang gar nicht auf, sondern erst dann, wenn man dieselbe Datei mehrfach kopiert? Das ergibt keinen Sinn, denn alle Zeichen werden deterministisch immer identisch transformiert.
Das ist ein Rätsel oder es handelte sich um eine falsche Annahme bei dem 1-Byte / 2-Byte-Problem.
4.
In Windows 10 steht in den Sprach-Regionaleinstellungen unten in der Dialogbox:
[_] beta Unicode UTF-8 für weltweite Sprachen
In "Windows 10 IoT Enterprise LTSC 2021" ist das nicht angehakt.
Im August gab es in Windows 11 24H2 eine Änderung dieser UTF-8-Option bezüglich Text und Position. Eventuell wurde auch intern da etwas bei der Zeichentransformation verbastelt, was man aber nur sehr schwierig feststellen kann, da ja keiner Lust hat, Windows 11 zu debuggen.