Windows 11: Warum Downloads verschwinden oder beschädigt ankommen – und wie ich die Ursache finde

Typische Symptome und Abgrenzung: „weg“, blockiert, quarantänisiert oder unvollständig gespeichert

Wenn Downloads unter Windows 11 „verschwinden“ oder beschädigt wirken, liegen oft unterschiedliche Zustände vor, die im Alltag ähnlich aussehen: Die Datei wurde nie vollständig gespeichert, sie wurde nachträglich blockiert oder entfernt, sie liegt in einem anderen Ordner als erwartet oder sie ist vorhanden, aber nicht nutzbar. Eine saubere Abgrenzung spart Zeit, weil sich Browser-Protokolle, SmartScreen-/Defender-Ereignisse und Dateisystemspuren nur dann stimmig interpretieren lassen, wenn klar ist, welches Symptom tatsächlich vorliegt.

„Weg“: Datei existiert nicht am erwarteten Speicherort

Das Symptom „weg“ bedeutet zunächst nur: Im Zielordner (typisch %USERPROFILE%\Downloads) ist nichts zu finden. Häufig handelt es sich um eine reine Pfad- oder UI-Abweichung: Der Browser speichert in einen abweichenden Download-Ordner, ein Download wurde „Öffnen“ statt „Speichern“ ausgeführt, oder ein anderes Programm hat die Datei unmittelbar nach dem Download verschoben. Ebenfalls relevant sind temporäre Download-Orte, die je nach Browser und Einstellung genutzt werden und bei Abbruch automatisch bereinigt werden können.

Technisch wichtig: Moderne Browser schreiben Daten häufig zunächst in eine temporäre Datei und benennen erst nach erfolgreichem Abschluss in den endgültigen Dateinamen um. Fehlt die Enddatei, kann dennoch ein Download-Artefakt existieren (z. B. .crdownload bei Chromium-basierten Browsern). Umgekehrt kann die Enddatei fehlen, weil sie durch Sicherheitskomponenten gelöscht wurde, bevor der Explorer die Aktualisierung sichtbar macht.

„Blockiert“: Datei vorhanden, aber Ausführung oder Zugriff wird verhindert

Bei „blockiert“ liegt die Datei im Dateisystem, lässt sich aber nicht wie erwartet öffnen oder ausführen. Typische Anzeichen sind Warnhinweise des Browsers beim Abschluss („Download blockiert“), SmartScreen-Dialoge oder das Verhalten, dass ein Doppelklick scheinbar nichts bewirkt. Unter Windows spielt dabei die Markierung „aus dem Internet“ (Mark-of-the-Web, MOTW) eine zentrale Rolle: Sie wird über einen alternativen Datenstrom gespeichert und beeinflusst SmartScreen sowie Anwendungsrichtlinien.

Abzugrenzen ist auch der Fall „Zugriff verweigert“ durch Dateisystemberechtigungen oder kontrollierten Ordnerzugriff (Controlled Folder Access). Dann ist nicht die Datei selbst „verschwunden“, sondern der Schreibvorgang in einen geschützten Ordner wurde blockiert; der Browser meldet häufig einen generischen Fehler, obwohl die Ursache in Windows-Schutzmechanismen liegt.

„Quarantänisiert“: Datei wurde nach dem Download entfernt oder isoliert

„Quarantänisiert“ ist ein präziserer Sonderfall von „weg“: Die Datei war kurzzeitig vorhanden oder wurde vollständig geschrieben, aber kurz darauf durch Microsoft Defender oder einen Drittanbieter-Virenscanner entfernt bzw. in Quarantäne verschoben. In solchen Situationen existiert im Download-Verlauf des Browsers häufig noch ein Eintrag, während der Datei-Explorer nichts mehr anzeigt. Manchmal bleibt ein Null-Byte-Stub oder eine unvollständige temporäre Datei zurück, weil die Entfernung während des Umbenennens oder Finalisierens erfolgt.

Für die Abgrenzung ist die zeitliche Reihenfolge entscheidend: Blockiert der Browser vor dem Speichern, entsteht keine (oder nur eine sehr kurze) Dateisystemspur. Greift der Virenscanner nach Abschluss, existiert zunächst eine vollständige Datei, die später verschwindet. Bei aggressiven Echtzeit-Scans kann die Datei bereits während des Schreibens isoliert werden; dann resultieren beschädigte oder teilweise gespeicherte Inhalte.

„Unvollständig gespeichert“: Datei existiert, ist aber defekt oder nur teilweise vorhanden

Unvollständige Downloads zeigen sich oft durch abweichende Dateigrößen, CRC-/Hash-Fehler beim Entpacken, Abbrüche bei Medienwiedergabe oder Installer, die „Datei beschädigt“ melden. Hier ist nicht primär ein Sicherheitsblock zu vermuten, sondern ein abgebrochener Transfer, ein serverseitig falsch geliefertes Objekt, ein Proxy/AV-Filter im Datenstrom oder ein Speichervorgang, der durch fehlenden freien Speicherplatz bzw. Dateisystemprobleme nicht sauber beendet wurde.

Browser-spezifische Zwischenformate sind ein klares Indiz: Dateien mit Endungen wie .crdownload oder .part signalisieren, dass der Browser den Download nicht finalisiert hat. Eine scheinbar „normale“ Enddatei kann trotzdem unvollständig sein, wenn der Server eine falsche Content-Length geliefert hat oder wenn während des Transfers ein Neustart/Standby den Stream unterbrach und der Browser das Ergebnis dennoch als abgeschlossen markierte (selten, aber in bestimmten Fehlerkonstellationen möglich).

Schnelle Prüfmarker, ohne Ursachen vorwegzunehmen

Zur Trennung der vier Fälle genügen oft wenige, konkrete Marker. Sie ersetzen noch keine Ursachenanalyse, verhindern aber Fehlinterpretationen (z. B. SmartScreen als Ursache, obwohl tatsächlich ein Abbruch im Netzwerk vorlag). Entscheidend sind Dateiname, Endung, Zeitstempel, Dateigröße sowie ein Abgleich zwischen Browser-Downloadliste und tatsächlichem Dateisystemzustand.

• Download-Ordner verifizieren: Pfadprüfung auf %USERPROFILE%\Downloads und auf abweichende Browser-Einstellungen; bei OneDrive-Umleitungen zusätzlich %USERPROFILE%\OneDrive\Downloads berücksichtigen, falls konfiguriert.
• Temporäre Artefakte erkennen: Indikatoren für nicht finalisierte Transfers sind Endungen wie .crdownload, .part oder temporäre Dateinamen im Download-Verzeichnis bzw. in Browser-Temp-Pfaden wie %LOCALAPPDATA%\Temp.
• MOTW/Block-Status prüfen: In PowerShell lässt sich die Internet-Markierung über Get-Item -LiteralPath "C:\Pfad\Datei.exe" -Stream Zone.Identifier -ErrorAction SilentlyContinue erkennen; bei Treffer liegt ein Stream Zone.Identifier vor.
• Defender-Ereignisse abgleichen: Verdacht auf Quarantäne lässt sich über die Windows-Sicherheitsoberfläche oder per Eventlog-Filter erhärten, z. B. in PowerShell mit Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 200.
• Plausibilitätscheck der Dateigröße: Vergleich von Explorer-Größe mit erwarteter Größe aus der Quelle; unplausible Größen oder 0 Byte sprechen für Abbruch oder blockiertes Finalisieren.

Erst wenn klar ist, ob tatsächlich eine Entfernung (Quarantäne), eine Präventionsmaßnahme (Blockierung) oder ein Transfer-/Speicherproblem (Unvollständigkeit) vorliegt, lassen sich Browser-Sicherheitsmeldungen, SmartScreen-Entscheidungen und AV-Protokolle belastbar korrelieren. Ohne diese Trennschärfe führen identische Fehlermeldungen („Download fehlgeschlagen“) leicht zu widersprüchlichen Maßnahmen.

Browserkontext prüfen: Download-Verlauf, temporäre Ordner, Safe Browsing, Erweiterungen und Netzwerkpfad

Wenn Downloads unter Windows 11 „verschwinden“, unvollständig ankommen oder als beschädigt gelten, liegt die Ursache häufig nicht im Zielordner, sondern im Browserprozess selbst: Der Download wird verworfen, in Quarantäne verschoben, in einem temporären Verzeichnis abgebrochen oder auf dem Weg über einen instabilen Netzwerkpfad beschädigt. Eine saubere Analyse beginnt deshalb im Browserkontext, bevor systemweite Maßnahmen sinnvoll bewertet werden können.

Download-Verlauf und Browser-UI: Status, Quelle und Blockierungsgrund

Der Download-Verlauf zeigt meist mehr als nur Dateinamen. Relevante Informationen sind die endgültige Quell-URL (nach Redirects), der Zeitpunkt des Abbruchs, die erkannte Dateityp-Klassifizierung sowie Hinweise auf Blockierungen durch Safe-Browsing-Mechanismen oder unternehmensseitige Richtlinien. In Chromium-basierten Browsern werden abgebrochene Downloads häufig mit Status wie „Fehlgeschlagen“, „Unterbrochen“ oder „Blockiert“ ausgewiesen; in Firefox werden ähnliche Zustände je nach Einstellung in der Download-Ansicht protokolliert.

Für die Eingrenzung ist entscheidend, ob der Download gar nicht gestartet wurde (Block vor dem Transfer), ob der Transfer unterbrochen wurde (Netzwerk/Server/Proxy), oder ob die Datei nach dem Transfer entfernt wurde (Safe Browsing, AV-Integration, „Mark of the Web“/Reputationsprüfung). Ein wiederholbarer Abbruch bei identischer Quelle spricht eher für Filterregeln, Content-Inspection oder Server-Range-Probleme; sporadische Abbrüche deuten eher auf Timeout, WLAN-Roaming oder Paketverlust.

Temporäre Download-Ordner und Zwischenformate: Was wirklich auf die Platte geschrieben wird

Viele Browser schreiben während des Transfers nicht sofort die finale Datei, sondern eine Zwischenversion. Chromium-basierte Browser verwenden typischerweise .crdownload, Firefox .part. Diese Fragmente liegen meist im Zielordner, können aber je nach Konfiguration und Sicherheitssoftware in temporären Pfaden auftauchen. Zusätzlich existieren Cache- und Profilpfade, in denen Metadaten zum Download sowie Hash- oder Reputationsinformationen abgelegt werden.

Bei „verschwindenden“ Downloads ist der Blick auf Standardpfade hilfreich, weil der sichtbare Zielordner nicht zwingend der Ort ist, an dem zuerst geschrieben wurde. Typische Kandidaten sind temporäre Systemordner und Browser-Profilverzeichnisse. Auch eine nachträgliche Verschiebung ist möglich, etwa wenn ein „Sauberer Ordner“-Mechanismus, ein Unternehmensagent oder eine DLP-Komponente die Datei aus dem Download-Ordner in einen Quarantäne- oder Prüfbereich verlagert.

• Windows-Temp pro Benutzer: %TEMP% bzw. C:\Users\<Name>\AppData\Local\Temp\
• Browser-Profil (Chrome/Edge): %LOCALAPPDATA%\Google\Chrome\User Data\Default\ bzw. %LOCALAPPDATA%\Microsoft\Edge\User Data\Default\
• Firefox-Profil: %APPDATA%\Mozilla\Firefox\Profiles\
• Unvollständige Dateien im Zielordner: *.crdownload (Chromium) oder *.part (Firefox)
• Standard-Zielordner prüfen: %USERPROFILE%\Downloads sowie im Browser eingestellte Alternative (z. B. Netzwerkpfad)

Falls eine Zwischen-Datei vorhanden ist, lässt sich der Abbruchzeitpunkt oft anhand von Dateigröße und Änderungsdatum eingrenzen. Wichtig ist, Zwischen-Dateien nicht vorschnell umzubenennen und als „fertig“ zu verwenden. Ohne korrektes Ende (EOF) oder fehlende Signaturen kann eine Datei zwar öffnbar wirken, aber beim Entpacken, Installieren oder Signieren scheitern.

Safe Browsing, Download Protection und Reputation: Blockade vor oder nach dem Transfer

Moderne Browser prüfen Downloads mehrstufig. Je nach Schutzmodus werden URL, Datei-Hash, Zertifikat/Signatur, MIME-Typ sowie Kontext (z. B. von einer neu registrierten Domain, aus einem Archiv, mit ausführbarem Payload) bewertet. Die Blockade kann vor dem eigentlichen Download erfolgen, während des Transfers (Abbruch durch Komponente) oder nach dem Speichern (Entfernung/Quarantäne). Das erklärt Fälle, in denen die Datei kurz im Download-Ordner auftaucht und dann verschwindet, während der Download-Verlauf einen Sicherheitsgrund ausweist.

Auf verwalteten Geräten übersteuern Richtlinien häufig lokale Einstellungen. Dann kann ein Download unabhängig von Nutzerentscheidungen blockiert werden, oder er wird automatisch in einen sicheren Workflow umgeleitet. Für die Analyse zählt die Trennlinie: Browser meldet eine Blockierung (Hinweis im Download-UI), oder die Datei wird gespeichert und später extern entfernt. Letzteres ist eher an plötzlichem Verschwinden ohne eindeutigen Browserhinweis erkennbar.

Erweiterungen, Content-Filter und Download-Manager: Eingriffe in Requests und Dateiströme

Erweiterungen können Downloads beeinflussen, ohne dass dies offensichtlich ist. Typisch sind URL-Umschreibungen (Tracking-Removal, Redirect-Blocker), Header-Manipulation (z. B. Entfernen von Range oder Referer), Script-Blocker, die Token-URLs unbrauchbar machen, sowie Download-Manager, die Streams abfangen und in eigene temporäre Speicherorte umleiten. Auch Sicherheits-Extensions im Unternehmenskontext (DLP, CASB) können Dateiinhalte scannen und Transfers abbrechen.

• Isolationsprüfung ohne Add-ons: Start im privaten Modus/InPrivate (oft ohne Erweiterungen) oder temporär deaktivierte Erweiterungen; Vergleich desselben Downloads mit und ohne Add-on-Einfluss.
• Mehrfach-Downloadpfade erkennen: Wenn ein Manager verwendet wird, entstehen zusätzliche Zwischenpfade; typische Indikatoren sind parallele Dateien wie *.tmp im Manager-Verzeichnis und ein abweichender finaler Speicherort.
• Header-/Token-Probleme bei Portalen: Bei signierten URLs (zeitlich begrenzte Tokens) führt eine Verzögerung durch Scans oder Blocker zu 403/401 oder zu HTML-Fehlerseiten, die als „Datei“ gespeichert werden.

Ein häufiger Integritätsfehler entsteht, wenn statt der erwarteten Binärdatei eine Login-Seite oder Fehlermeldung heruntergeladen wird. Das fällt nicht immer sofort auf, insbesondere wenn Portale die Antwort mit generischen Dateinamen ausliefern. Hier hilft der Abgleich von Dateigröße, Dateityp (Eigenschaften/„Typ“) und bei Archiven ein schneller Test, ob der Header plausibel ist (z. B. ZIP-Signatur).

Netzwerkpfad, Proxy, VPN und SMB-Ziele: Ursachen für Abbrüche und stille Korruption

Downloads scheitern nicht nur an der Internetstrecke, sondern auch am Speicherziel. Wird direkt auf ein Netzlaufwerk oder einen UNC-Pfad gespeichert, können SMB-Unterbrechungen, Offline-Dateien, Berechtigungswechsel oder Dateisperren den finalen Rename-Schritt verhindern. Browser schreiben häufig zunächst eine temporäre Datei und benennen sie am Ende um; wenn das Ziel kurzzeitig nicht verfügbar ist, bleibt ein Fragment zurück oder der Browser meldet „Fehlgeschlagen“.

Proxies und VPNs können zusätzlich in TLS- oder HTTP-Streams eingreifen. Content-Inspection kann Downloads abbrechen, wenn Dateitypen gesperrt sind oder wenn ein Scan-Timeout greift. Bei instabilen Verbindungen treten außerdem Probleme bei der Wiederaufnahme (HTTP Range) auf: Manche Server oder Zwischengeräte liefern bei Resume eine andere Antwort (anderer ETag, komprimierte statt unkomprimierter Stream), wodurch zusammengesetzte Dateien beschädigt werden.

• Test mit lokalem Ziel: Download zunächst nach %USERPROFILE%\Downloads speichern und erst danach manuell auf SMB/Share kopieren; Unterschiede deuten auf Ziel-/SMB-Probleme statt auf die Quelle.
• Proxy-/VPN-Isolation: Vergleich mit deaktiviertem VPN oder alternativem Netzwerk; bei Unternehmensumgebungen Proxy-Einsatz über Browser/Windows-Konfiguration prüfen (z. B. netsh winhttp show proxy).
• Wiederaufnahme vermeiden bei Verdacht: Statt „Fortsetzen“ einen frischen Download starten, um inkonsistente Range-Transfers auszuschließen; alte Fragmente (.crdownload/.part) entfernen oder in einen Analyseordner verschieben.

Windows- und Sicherheitskontext prüfen: SmartScreen, Defender/AV, Controlled Folder Access, Ereignisprotokolle und Integritätsprüfung vor dem erneuten Download

Wenn Downloads unter Windows 11 scheinbar „verschwinden“, nur als leere Datei enden oder nach dem Abschluss nicht mehr geöffnet werden können, liegt die Ursache häufig außerhalb des Browsers. Windows-Sicherheitsfunktionen und Endpoint-Schutzprodukte greifen an mehreren Stellen ein: beim Speichern in den Download-Ordner, beim Markieren der Datei als aus dem Internet stammend (Mark-of-the-Web), beim Entpacken oder beim ersten Start. Eine belastbare Fehleranalyse trennt deshalb konsequent zwischen Blockierung, Quarantäne, Zugriffsverweigerung und echter Dateibeschädigung.

SmartScreen und reputationsbasierte Blockierung

Microsoft Defender SmartScreen bewertet heruntergeladene Dateien anhand von Reputation (u. a. bekannte Signaturen, Verbreitungsgrad, Telemetrie und Publisher-Reputation). Typisch sind zwei Effekte: Der Download wird zwar gespeichert, aber beim Öffnen wird der Start verhindert („Windows hat den PC geschützt“), oder die Datei wird unmittelbar nach dem Speichern wieder entfernt, weil nachgelagerte Prüfungen anschlagen. In letzterem Fall bleibt im Download-Verlauf des Browsers oft ein „Abgeschlossen“, während die Datei im Zielordner fehlt.

Für die Einordnung ist entscheidend, ob die Datei tatsächlich nie final geschrieben wurde (Abbruch/Fehler beim Speichern) oder ob ein nachgelagerter Schutz sie entfernt hat. SmartScreen ist dabei nicht mit der Antiviren-Engine identisch: Eine reputationsbasierte Sperre kann ohne Malwarefund auftreten, was im Support häufig als „beschädigter Download“ fehlinterpretiert wird.

Defender/AV: Quarantäne, Echtzeitschutz und Ausschlussfallen

Der Microsoft Defender Antivirus (oder ein Drittanbieter-AV) prüft Downloads beim Schreiben und erneut beim Zugriff. Wird eine Datei in Quarantäne verschoben, wirkt das im Alltag wie ein „Verschwinden“. Manche Produkte entfernen auch nur den ausführbaren Anteil aus Archiven oder blockieren einzelne extrahierte Dateien, wodurch nach dem Entpacken „beschädigte“ Archive oder unvollständige Installationsverzeichnisse entstehen.

Für die Diagnose zählen konkrete Artefakte: Ein Defender-Alarm mit Zeitstempel, eine Quarantäne-ID oder ein Block-Event ist belastbarer als ein Browserhinweis. Gleichzeitig ist Vorsicht bei Ausnahmen geboten: Ein kurzfristiger Ausschluss des Download-Ordners kann das Symptom kaschieren, aber die eigentliche Ursache (z. B. kompromittierte Quelle oder manipuliertes Mirror) bleibt bestehen.

• Defender-Schutzverlauf prüfen: Windows-Sicherheit > Viren- & Bedrohungsschutz > Schutzverlauf
• Quarantäne/Detections per PowerShell einsehen: Get-MpThreatDetection
Get-MpThreat
• Relevante Defender-Ereignisse in der Ereignisanzeige: Ereignisanzeige > Anwendungs- und Dienstprotokolle > Microsoft > Windows > Windows Defender > Operational
• Drittanbieter-AV beachten: Programme > installierte Sicherheitssoftware; zusätzliches Log im jeweiligen Produkt nach „Quarantine“, „Blocked“, „Web Shield“ oder „Download Scan“ filtern.

Controlled Folder Access und Ordnerzugriffe: Wenn Speichern scheitert

„Überwachter Ordnerzugriff“ (Controlled Folder Access) aus dem Ransomware-Schutz kann Schreibzugriffe auf geschützte Ordner blockieren. In vielen Umgebungen sind zwar primär Dokumentenordner geschützt, je nach Richtlinie kann aber auch der Download-Pfad betroffen sein oder ein umgeleiteter Profilpfad (Known Folder Move/OneDrive) führt dazu, dass Downloads effektiv in einem überwachten Bereich landen. Symptome sind dann Zugriffsfehler im Browser, abgebrochene Downloads oder Dateien, die als temporäre Fragmente existieren, aber nie final umbenannt werden.

In solchen Fällen ist die zeitliche Korrelation entscheidend: Block-Events treten beim Abschluss des Downloads auf (Umbenennen/Finalisieren) oder beim Entpacken/Schreiben durch Installer. Die Prüfung erfolgt über Windows-Sicherheit und über entsprechende Ereignisprotokolle. Für eine saubere Abgrenzung sollte zusätzlich getestet werden, ob derselbe Download in einen alternativen, nicht überwachten Pfad geschrieben werden kann (z. B. ein frisch angelegter Ordner unter C:\Temp), ohne dabei Sicherheitsmechanismen dauerhaft abzuschalten.

Ereignisprotokolle systematisch korrelieren

Für eine belastbare Ursache-Wirkung-Kette sollten Zeitstempel aus Browser-Downloadliste, Dateisystem (Erstell-/Änderungszeit) und Security-Logs zusammengeführt werden. Neben Defender-Events liefern auch allgemeine Windows-Protokolle Hinweise, etwa wenn ein Filtertreiber Fehler beim Schreiben verursacht oder wenn der Zugriff auf den Zielordner verweigert wurde. Praktisch ist das Filtern nach dem Download-Zeitfenster und nach Schlüsselwörtern wie „blocked“, „quarantine“, „access denied“ sowie nach dem konkreten Dateinamen.

• Ereignisanzeige öffnen und eingrenzen: eventvwr.msc; dann Zeitraum filtern und unter Windows-Protokolle > System sowie Windows-Protokolle > Anwendung nach passenden Ereignissen suchen.
• Defender-Operational-Protokoll gezielt prüfen: Ereignisanzeige > Anwendungs- und Dienstprotokolle > Microsoft > Windows > Windows Defender > Operational
• Ransomware-Schutz-Logs lokalisieren: Windows-Sicherheit > Viren- & Bedrohungsschutz > Ransomware-Schutz verwalten; dort Blockierungen und zugelassene Apps nachvollziehen.

Integritätsprüfung vor dem erneuten Download: Hashes, Signaturen, Zone.Identifier

Bevor eine Datei erneut bezogen wird, sollte zunächst geklärt werden, ob der bereits vorhandene Stand tatsächlich unvollständig ist oder nur am Start gehindert wird. Bei ausführbaren Dateien und Archiven liefert eine Hashprüfung eine eindeutige Aussage über Integrität, sofern der Anbieter einen Referenzhash veröffentlicht. Zusätzlich ist eine digitale Signatur (Authenticode) ein wichtiger Hinweis auf Unverändertheit, ersetzt aber keinen Hashabgleich, wenn ein konkreter Hash vorliegt. Für Browser-Downloads ist außerdem relevant, ob die Datei ein Mark-of-the-Web trägt; dieses Flag beeinflusst SmartScreen, Office-Makro-Schutz und manche Ausführungswarnungen.

• Dateihash berechnen (Vergleich mit Anbieterangabe): Get-FileHash -Algorithm SHA256 "C:\Users\...\Downloads\datei.iso"
CertUtil -hashfile "C:\Users\...\Downloads\datei.zip" SHA256
• Authenticode-Signatur prüfen (EXE/MSI/Skripte): Get-AuthenticodeSignature "C:\Users\...\Downloads\setup.exe"
• Mark-of-the-Web/Zone.Identifier prüfen: Get-Item -Stream Zone.Identifier "C:\Users\...\Downloads\datei.exe" -ErrorAction SilentlyContinue
Get-Content -Stream Zone.Identifier "C:\Users\...\Downloads\datei.exe" -ErrorAction SilentlyContinue

Ergibt der Hashvergleich eine Abweichung oder fehlt die Datei vollständig, sollte der erneute Bezug in einem konsistenten Sicherheitskontext erfolgen: identische Quelle, möglichst direkte Hersteller-URL, keine inoffiziellen Mirrors, und bei wiederholter Blockierung eine Klärung über Logs statt über Deaktivierung von Schutzfunktionen. Wenn Signatur und Hash stimmig sind, aber der Start weiterhin blockiert, liegt der Schwerpunkt der Analyse eher bei SmartScreen, Richtlinien (z. B. App Control) oder Ordnerschutzmechanismen als bei einem „kaputten“ Download.