[English]Ich stelle mal einen Hinweis auf Patchday-Probleme im Zusammenhang mit Windows 11 24H2/25H2 hier im Blog ein. Es gibt Hinweise, dass das Update KB5066835 vom 14. Oktober 2025 dazu führt, dass der localhost nicht mehr ansprechbar ist. Einzig bekannter Workaround ist die Deinstallation des Updates.
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
Windows 11 24H2/25H2 Update KB5066835
Das zum 14. Oktober 2025 für Windows 11 24H2 (und 25H2) veröffentlichte kumulative Update KB5066835 beinhaltet diverse Qualitätsverbesserungen sowie Sicherheitspatches, die im verlinkten Supportbeitrag aufgeführt sind.
Probleme mit localhost nach Update-Installation
Christian Wenz hat mich in einer privaten Nachricht auf Facebook (danke dafür) auf einen Post Localhost applications failing after installing "2025-10 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5066835) (26100.6899)" [closed] auf Stackoverflow aufmerksam gemacht. Der Thread ist aktuell bereits für jegliche Diskussion gesperrt, weil es kein Programmier-Thema ist. Aber das Problem dürfte viele Windows 11-Nutzer der Versionen 24H2 und 25H2 treffen.
Ein Betroffener schreibt, dass er gerade das kumulative Update KB5066835 für Windows 11 auf seinem Laptop installiert habe. Nun erhalte er Fehlermeldungen, wenn ich versuche, Anwendungen auf localhost auszuführen.
Der Thread-Ersteller gibt an, dass er eine ASP.NET 4.6.2-Anwendung habe, er als Website auf seiner lokalen IIS-Installation über die Hosts-Datei ausführt. Konkret wird dort der "App-Name" in 127.0.0.1 aufgelöst. Versucht der Betroffene die Anfrage an localhost per http:// auszuführen, erhält er aufgrund eines ERR_CONNECTION_RESET-Fehlers die Fehlermeldung "Site cannot be reached error" (Website kann nicht erreicht werden).
Der Nutzer verwendet laut eigener Aussage Visual Studio auch zum Erstellen von .NET (.NET 8)-Webanwendungen. Der Versuch, diese Webanwendungen mit IIS Express auszuführen (zu debuggen), schlägt nun ebenfalls mit der Fehlermeldung ERR_HTTP2_PROTOCOL_ERROR fehl.
Installiert wurden vom Betroffenen das Windows 11 Update "2025-10 Cumulative Update for Version 24H2 for x64-based Systems (KB5066835) (26100.6899)" sowie das Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 24H2 for x64 (KB5066131)".
Als der Nutzer fragte, ob noch jemand dieses Problem habe, wurde dieses durch weitere Betroffene bestätigt. Einer schrieb, dass er das Sicherheitsupdate KB5066835 für Windows 11 24H2 / 25H2 deinstallieren musste, damit der Zugriff auf localhost wieder funktioniert.
Auf administrator.de heißt es, dass jemand das Update unter Windows 11 25H2 nicht mehr deinstallieren kann.
Weitere Treffer im Internet
Geht man im Internet auf die Suche, gibt es eine Reihe Treffer (z.B. auf reddit.com), die bestätigen, dass das Update die Funktion von Localhost unter Windows 11 24H2/25H2 kaputt macht. Jan van Rhine hat zum 15. Oktober 2025 auf Microsoft Q&A den Eintrag Localhost not working anymore after 2025-10 cumulative update Windows 11 veröffentlicht, in dem das gleiche Problem beschrieben wird. Auf einer frischen Windows 11 24H2-Installation trete der Fehler nicht auf.
Dürfte einige Anwendungen betreffen
Das Problem sieht exotisch aus, aber mir sind Meldungen zugegangen, dass Access-Control-Funktionen seit dem Oktober 2025-Patchday nicht mehr funktionieren. Dürfte genau das obige Problem sein, wenn diese localhost verwenden.
Passwortverwaltung Safe betroffen
Frank schrieb mir per Mail (danke): "vielleicht nutzt der eine oder andere der Leser für die Passwortverwaltung Safe (früher SafeInCloud) mit dem zugehörigen Browser-Plugin. Nach dem letzten Windows Update ist diese Funktion gestört." Der Support von 'Safe' schreibt dazu:
Was ist passiert: Das Windows 11-Update KB5066835 hat einen Fehler eingeführt, der verhindert, dass Safe mit Browser-Erweiterungen kommunizieren kann. Microsoft ist informiert und untersucht das Problem.
Kantech EntraPass (access control)
Der bereits verlinkte reddit.com-Post erwähnt Kantech EntraPass (access control), dass von einem Kunden unter Windows 11 Pro genutzt wird. Die nutze ein eigenes Web-basierendes Interface (EntraPassWeb), dass über IIS läuft und nun nicht mehr funktioniert.
DATEV-Anwendungen
In nachfolgendem Kommentar weist Thorben auf Probleme mit DATEV-Anwendungen hin. Bei der DATEV gibt es den Post DFÜ funktioniert nicht nach Windows-Update (#RZK73019), der ähnliches vermutet.
CAS genesisWorld CRM
Ein Blog-Leser informierte mich, dass CAS genesisWorld CRM ab Version x13.1.0.13101 nach dem Patchday kaputt sei und der Hersteller genau vor obigem Update warnt. Das betrifft Windows Server. Nach der Installation des Microsoft Windows Updates "Windows KB5066835 (24H2/25H2)" meldet die Login-Seite von CAS genesisWorld Web einen Verbindungsfehler und dass der Applikationsserver nicht verfügbar sei, heißt es in der Hersteller-Mail, die mir vorliegt.
"Nach derzeitiger Einschätzung stört das Update die Server-interne Kommunikation auf den CAS genesisWorld-Servern." schreibt der Anbieter. In der Logdatei findet sich folgender Eintrag:
C:\ProgramData\CAS-Software\genesisWorld\Logs\JavaServices\smartdesign\smartdesign-client.log wird folgender Eintrag geschrieben: exceptionMessage: Failed to access the WSDL at: http://127.0.0.1:8080/genesis.svc?wsdl. It failed with: Connection reset.
Neben CAS genesisWorld Web sind auch andere CAS genesisWorld Dienste wie OpenSync, die mobilen Apps und voraussichtlich weitere Dienste und Lösungen nicht mehr verfügbar.
Es gibt noch weitere Meldungen, die in mein Posteingangsfach geschwappt sind – muss aber erst einmal sortieren, was, was ist.
Früher (TM) gab es Terror-Vögel – aber die sind ausgestorben. Heute gibt es Microsoft Patchday als moderne Reinkarnation .
Workarounds für das Problem
Inzwischen liegen zwei Informationen vor, die das Problem mit localhost und IIS beseitigen sollen.
Fixt ein Defender-Update das Problem?
Im bereits mehrere Seiten umfassenden Microsoft Q&Q-Thread KB5066835 update causing IIS Service to not work habe ich diese Antwort vom heutigen 16. Oktober 2025 gefunden.
This morning there was a Defender update, I have installed it an now it works!!!
Klingt irre, daher die Frage, ob jemand betroffen war und ob ein Defender Update das Problem wirklich löst? Zumindest eine Person im Antwort-Thread bestätigt, dass bei ihr der IIS wieder funktioniert.
Ein Registrierungseintrag hilft auch
Leser Flo hat sich in nachfolgendem Kommentar gemeldet und verweist auf diesen Learn Microsoft-Post. Dort werden PowerShell-Befehle genannt, mit denen HTTP/2 durch entsprechend gesetzte Registrierungseinträge deaktviert wird, was das Problem beheben soll. Beachtet aber auch den Kommentar von Bolko bezüglich der Impliktionen und setzt auf die oben erwähnten Defender-Updates.
Ähnliche Artikel:
Microsoft Security Update Summary (14. Oktober 2025)
Patchday: Windows 10/11 Updates (14. Oktober 2025)
Patchday: Windows Server-Updates (14. Oktober 2025)
Patchday: Microsoft Office Updates (14. Oktober 2025)
Exchange Server Sicherheitsupdates Oktober 2025
September 2025-Update KB5065426 verursacht Probleme mit großen AD-Umgebungen
MVP: 2013 – 2016
Es reicht folgende Registry Keys zu setzten, das Update kann drauf bleiben:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" -Name "EnableHttp2Tls" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" -Name "EnableHttp2Cleartext" -Value 0 -Type DWord
https://learn.microsoft.com/en-us/answers/questions/5585563/localhost-not-working-anymore-after-2025-10-cumula?page=6#answers
Nur löst das nicht das eigentliche Problem sondern verändert systemweit Dinge in HTTP2…
Datev scheint davon auch betroffen zu sein: https://www.datev-community.de/t5/Technisches-zu-Software/DF%C3%9C-funktioniert-nicht-nach-Windows-Update-RZK73019/td-p/513360#_
Damit hängt wohl auch das Problem zusammen, dass das Browser-Plugin des Passwortmanagers Safe (früher SafeInCloud) nicht mehr funktioniert.
Außerdem vermute ich da auch die Fehlfunktion der Abo-Bestellseite von Heise. Statt einer Bestellbestätigung kommt eine Fehlermeldung, dass keine Verbindug zu localhost aufgebaut werden konnte. So habe ich gerade vier Abonnements bestellt ;-)
Danke für den Kommentar – erinnern meine grauen Zellen, dass Du mir einen Hinweis geliefert hast? Momentan schwappt alles mögliche auf diversen Kanälen bei mir an Problemen rein, und ich kriege es aktuell kaum noch sortiert.
Nach deinem Blog-Eintrag habe ich gerade den Registry-Workaround ausprobiert. Bei mir funktioniert es dann nach Restart.
Danke für die Rückmeldung. Der Beitrag scheint als Honeypot schon wieder gut zu funktionieren.
Rough guess, MS hat was an den Ciphern gedreht und/oder verschlüsselte Kommunikation by Default für seine Win32 API unterbunden. Würde die Registry Settings EnableHttp2Cleartext erklären.
Ich wette, dass ein anderer Webserver oder Rest API auf localhost funktioniert. Wer gerade keinen zur Hand hat, kann ja mein Skeleton nehmen:
https://codeberg.org/tomas-jakobs/rest-api-skeleton
Habe hier gerade kein Windows zur Hand, vielleicht kanns ja jemand nachstellen.
Was jetzt reihenweise ausfällt, dürfte demnach unverschlüsselt und/oder mit schwachen Ciphern mit localhost kommunizieren.
Siemens TIA und WIBU Codemeter laufen als Beispiel, die hab ich heute morgen schon durchgetestet, basieren scheinbar nicht auf irgendwelchen Windows Komponenten.
Noch eine wildere Vermutung: Die wenigsten Anwender dürften ein gültiges Zertifikat für "localhost" oder "127.0.0.1" haben. Vielleicht ist jetzt die Vertrauensprüfung straffer implementiert und betrachtet das nicht mehr als Ausnahmetatbestand.
Duplicati-GUI unter http://localhost:8200/ngax/index.html funktioniert auch mit dem Update ohne was ändern zu müssen.
Ob es mit dem localhost-Problem zu tun hat weiss ich nicht. Aber nachdem ich gestern besagtes Windows Update gemacht habe, hatte ich heute morgen auf einem Windows 10 Enterprise IoT 2021 LTSC ein Problem mit Wireguard. Der Dienst konnte nicht gestartet werden und auch das Tray Icon war defekt (evtl. konnte der Netzwerkadapter nicht korrekt angesprochen / implementiert werden, habe das nicht genauer analysiert, wollte erst einem Reboot die Ehre geben). Mir fiel dann auch ein Windows Defender Update auf, welches ich gleich gemacht habe. Danach ein Reboot (tut immer gut) und Wireguard lief wieder.
Dazu kann ich nur sagen, dass ich bisher seit ich WireGuard nutze noch nie Probleme mit dem nativen Windows Client hatte.
Mit den Registry-Keys wird HTTP/2 ausgeschaltet und HTTP/1.1 bleibt übrig.
Wenn Programme die neue Windows-Authentifizierung nicht verstehen, dann fallen sie auf HTTP/1.1 zurück. Wenn Windows aber stur auf HTTP/2 bleibt, dann kommt keine Kommunikation zustande. Deswegen muss man Windows mit den Registry-Keys zwingen, kein HTTP/2 zu benutzen.
Zitat aus einem Microsoft vom März 2024:
"HTTP/2 on IIS (HTTP/2 auf IIS)"
"Windows-Authentifizierung (NTLM/Kerberos/Negotiate) wird mit HTTP/2 nicht unterstützt. In diesem Fall fällt IIS auf HTTP/1.1 zurück.
Klartext: Wie oben erwähnt, unterstützt IIS HTTP/2 derzeit nur über TLS. Auch hier fällt IIS auf HTTP/1.1 zurück."
learn. microsoft. com/de-de/iis/get-started/whats-new-in-iis-10/http2-on-iis
Bei mir ändert sich nach dem Update und dem Workaround der Cipher (IIS auf 24H2) von
TLS 1.3, X25519, AES_256_GCM
auf
TLS 1.3, X25519, CHACHA20_POLY1305
aber sonst geht es dank dem Workaround wieder wie gehabt.
Unser Dienstleister hat uns gerade informiert, dass wir das Update nicht installieren dürfen, sonst funktioniert auch Sage Software nicht mehr.
Wir haben das Update trotz dieser Info von Sage installiert, Sage HR funktioniert bei uns danach tadellos (on-Prem). Evtl. gibt es hier Zusammenhänge mit Drittsoftware (Schutzsoftware)?
Gibt auch von Omnissa ein Advisory, dass VDI Verbindungen mit dem Horizon Client wohl Probleme machen und deshalb das Update nicht installiert werden darf:
Dear Valued Customer,
This advisory is to formally inform you of a recently identified issue affecting Virtual Desktop launches and connections when using the Omnissa Horizon Windows Client. The issue arises after the installation of the Microsoft Windows Patch update KB5066835 on end-user devices.
Recommended Mitigation Strategy
To ensure service continuity while a permanent resolution is being developed, please take the following actions based on your current environment:
1. If KB5066835 has not yet been installed:
a. Action: We strongly recommend deferring the installation of the Recent Windows update (KB5066835) until an official corrective patch from Omnissa or Microsoft is released and validated.
2. If KB5066835 has already been installed and desktop connection issues are observed:
a. Option A (Client-Based Mitigation): Temporarily uninstall updates KB5066835 and its prerequisite KB5065789 from affected devices.
b. Option B (Interim Access): Use the Horizon HTML Client (browser-based access) as a fully functional workaround to maintain connectivity to your virtual desktop.
Status and Resolution
The Horizon Engineering Team has assigned the highest priority to this issue. We are actively investigating the root cause and collaborating closely with relevant partners to identify, test, and release a validated fix at the earliest possible time.
We will issue a follow-up communication as soon as a corrective update becomes available or if there are any significant developments in the resolution process.
We sincerely appreciate your patience, cooperation, and understanding as we work diligently to restore full functionality and stability.
If you have any questions regarding the prerequisites or this update, please contact Omnissa Support.
Sincerely,
The Horizon Cloud Service Team
Es lag wohl an fehlerhaften Defenderupdates:
1.439.216.0
Damit geht es ohne den Workaround wieder.
Habe das Defender Update eingespielt, aber immer noch das Problem (bei Datev RZ Kommunikation). Braucht es einen Neustart eines Dienstes?
ich habe die ganze Maschine neu gestartet, der IIS-Neustart (bei mir gings um einen IIS auf 24H2 welcher nicht mehr auf die Bindings reagierte).
Hat jemand schon Infos gefunden, ob das auch die Server Editionen betrifft?
Betrifft auch die Windows Server-Versionen – siehe den Hinweis oben im Text zum CRM-System, welches auf Windows Server läuft.
Hier war es ein IIS der nur als Reverseproxy dient (also keine lokale Anwendung). Deinstallieren des Updates hat ablösung gebracht
Mit dem Update auf einem Druckserver tritt auch das Problem auf das hier beim Drucken die Dokumente 2 Mal ausgedruckt werden am Server.
obiger Regestry eintrag schafft abhilfe.
Hallo Günther,
kannst Du auch gerne die Sage 100 ERP (Warenwirtschaft und Rechnungswesen) der Firma Sage aus Frankfurt mit aufnehmen. Diese arbeitet intern auch im Hintergrund mit https aufrufen und kann den Applikation Server nicht mehr erreichen.
KB5066835 und KB5066128 vom 15.10.2025 dürfen nicht auf Windows 11 installiert werden, sonst tritt der Fehler auf.
Grüße Marco
Tja die Nachrichten so durchscrollend haben wir jetzt einen Klassiker:
Microsoft hat möglicherweise mal was richtig gemacht und seine API abgedichtet.
Nun fallen aber die schrottig programmierten Apps um, die sich auf Defaults verlassen haben oder serverseitig Cipher und Protokollmerkmale nicht erzwingen (macht man normalerweise um Downgrades zu verhindern) und nun mit heruntergelassener Hose dastehen.
Schrott, diesmal auf Seiten der App-Hersteller.
Microsoft wäre einzig die mangelhafte Kommunikation anzukeiden.
Hm, Zitat aus obigem Artikel:
Ich mag mich ja täuschen, aber Visual Studio = aus dem Hause Microsoft, und .NET 8 = aus dem Hause Microsoft. Es ist lange (15 Jahre) her, seit ich das letzte Mal ein Visual Studio auf einem Rechner hatte, daher sieh es mir nach. Wenn ich mit der Kombination zwangsweise schrottige Apps erstelle, liegt es an mir oder an Microsoft? Wo bin ich jetzt falsch abgebogen?
sehe ich erstmal kein Widerspruch, die linke Hand bei MS wusste noch nie, was die rechte tut und alle Abteilungen bekämpfen sich bis auf's Blut. Es gibt da ja so ein Org-Chart Vergleich..
https://bonkersworld.net/organizational-charts
Ich habe das beim Wechsel von HTTP 1.0/1.1 auf 1.2 schon bei .NET Anwendungen erlebt. Da haben sich etliche Devs auf die Standardvorgaben verlassen, die MS vor Jahren dann aber auf 1.2 angehoben hat und siehe da, der Müll funktionierte dann auch nicht mehr.
In Zeiten von Copilot und ChatGPT erwarte ich da noch mehr Regression und Ahnungslosigkeit in dem eigenen Laden.
Mit der Feststellung „mangelhafte Kommunikation" triffst du den Nagel auf den Kopf. Jeden Monat läuft das so.
Magst dich vielleicht erinnern, im letzten Jahrhundert mit den Mainframes. Da gab es einmal im Jahr Updates, geliefert in Form einer Bandspule und einer Kiste Papier, beinhaltend komplett neue Manuals oder Seiten zum austauschen. Und – es gab Release-Notes gebunden als Buch oder Büchlein. Da konnte man dann alles lesen was zu beachten ist. Dafür brauchte man einige Stunden oder sogar Tage, aber dann war man vorbereitet.
Heute, in der „Neuzeit", verteilt die grösste Softwarefirma der Welt diese Infos auf „Support" und „Learn"-Seiten, manchmal etwas verlinkt zueinander. Oft muss man sich die Infos dann aber auch zusammensuchen. Meist dann, wenn man den Kopf schon angestossen hat, weil eben keine oder ungenügende Vorabinfos vorhanden waren.
Detaillierte Release-Notes in Form eines PDF oder Webseite kriegen andere ja hin. Da könnte vielleicht Copilot mal eine monatliche Zusammenfassung aller Änderungen und eine ToDo-Liste erstellen, anstatt sich ständig dem Windows- und Office-Anwender aufzudrängen
In den Online-Diskussionen (auch hier) herrscht gelinde gesagt ein totales Durcheinander darüber, welche Workarounds hier zu funktionieren scheinen.
Wir haben das bei uns im Betrieb heute mal versucht, genauer unter die Lupe zu nehmen. Wir hatten mehrere Rechner, die nach dem Update betroffen waren. Konkret heißt das, eine Applikation, die auf localhost stinknormales HTTP angeboten hat, war nicht erreichbar wegen ständigen CONNECTION_RESETs.
Wir wissen von einer Maschine, wo mehrere Update-Pakete deinstalliert werden mussten, bevor es wieder funktioniert hat. Wir wissen von einer Maschine, die gar nicht betroffen war. Und wir wissen von einer Maschine, bei der das Problem initial nach dem Update auftrat, aber sich dann durch alleiniges zweifaches Rebooten plötzlich gelöst hat.
Alle mit gleichem Update-Stand (ja, auch die Windows Defender-Definitionen waren gleich).
Vor dem Hintergrund würde ich Aussagen wie dass das ein Fehler der App-Hersteller sei, sowie irgendwelchen Vorschlägen, man müsse den richtigen Registry-Key installieren, und sich dann bei Mondschein dreimal im Kreis drehen, eher wenig Glauben schenken.
Denn für jeden dieser Workarounds kann es eben sein, dass das eigentlich entscheidende war, dass irgendwelche Kernel-Internen caches oder Firewall-Einstellungen bei dem finalen Reboot endlich verworfen oder neu berechnet wurden, und es eigentlich nichts mit dem Update, dem Registry-Key, oder dem vergossenen Blut des Erstgeborenen zu tun hatte.
Schlägst Du mit deinem "In den Online-Diskussionen (auch hier) herrscht gelinde gesagt ein totales Durcheinander darüber, welche Workarounds hier zu funktionieren scheinen." nicht den falschen Esel?
Das war nicht mal als Vorwurf gegenüber dem Post gemeint. Was ich mir wünschen würde wäre eine klare Ansage von Microsoft: Das sind die Symptome, folgende Versionen sind betroffen, hier sind Workarounds. Aber gerade fischen alle im Dunkeln. Gegeben der vollkommen fehlenden Kommunikation von Seiten Microsoft kann man nicht viel mehr tun als herumstochern und dokumentieren, was für manche Leute wirkt, und sich über die aktuelle Lage austauschen. Soweit sogut, aber ein Durcheinander ist es trotzdem.
Aber wir sollten uns nicht einbilden, aus diesem total diffusen Fehlerbild herauslesen zu können, was das eigentliche Problem ist, so wie ein Kommentator hier meinte, das habe ganz sicher mit abgeschalteten Cipher suites zu tun, während ein anderer wie schon erwähnt meint, das könne nur auf Applikationsseite liegen.
Ich kann mir jetzt genau so sehr aus den Fingern saugen, das läge bestimmt an einer ABI-Inkompatiblen Änderung irgendwelcher structs in den Firewall-Regeln auf binärebene, und noch im BPF-JIT-Cache liegende Paketfilter würden dadurch segfaulten, was sich außerhalb der BPF-Sandbox als Connection-Reset äußern würde, ES SEI DENN man macht irgendwas im System, wie etwa einen von 4 Registry Keys anfassen, oder durch einen Reboot einmal den Netzwerkstack neuinitialisieren, was das System dazu veranlasst, die geJITteten Firewall-Regeln neu zu kompilieren.
Damit kann ich sehr klug klingen, und ganz ehrlich, das klingt sogar plausibel, aber die Evidenzlage, auf derer sowas basiert, ist etwas fadenscheinig. Wir wissen nicht, woran's liegt, auch wenn das unzufriedenstellend ist.
Lösung:
"… Ihnen wird das neueste Microsoft Defender Antivirus Update (KB2267602 (Version 1.439.210.0)) vorgeschlagen. Sollte dies nicht der Fall sein, suchen Sie nach aktuell verfügbaren Updates. Mit dem Einspielen des genannten Microsoft Defender Updates (oder einer höheren Version) ist der Fehler behoben. Auch die ggf. deinstallierten Updates (KB5066835 und KB5065789) sollten in diesem Zuge erneut installiert werden."
xttps://arztsoftware.medatixx.de/kundenservice/xconcept#tab-283-0
Die Problembeschreibung dazu steht hier:
"Wenn die Oktoberupdates für Windows 11 "auf dem Hauptrechner" installiert wurden, startet das Arztprogramm nicht mehr. …"
https://www.borncity.com/blog/2025/10/15/patchday-windows-10-11-updates-14-oktober-2025/#comment-232863
Zitat:
"Auf administrator.de heißt es, dass jemand das Update unter Windows 11 25H2 nicht mehr deinstallieren kann."
—
Wenn die Deinstallation nicht funktioniert, dann liegt das an dem Sandbox-Feature.
Das Sandbox-Feature muss man deaktivieren und anschließend funktioniert die Deinstallation des Updates wieder.
Es bringt noch ein weiteres Problem mit sich. Im Datei Explorer lassen sich damit Dokumente nicht mehr in der Voransicht öffnen. Es erscheint die Meldung:
"Die Datei, die Sie in der Vorschau anzeigen möchten, könnte Ihrem Computer schaden".
Siehe auch: https://www.reddit.com/r/Acrobat/comments/s6iyle/the_file_you_are_attempting_to_preview_could_harm/?tl=de