Downloads unter Windows 11 verschwinden oder sind beschädigt: Woran es liegt und wie man die Ursache findet

Symptome präzise einordnen: Was „verschwunden“ und was „beschädigt“ in Windows 11 praktisch bedeutet

Die Begriffe „Download verschwunden“ und „Datei beschädigt“ beschreiben in Windows 11 unterschiedliche Fehlerbilder, die sich oft ähnlich anfühlen, technisch aber aus völlig verschiedenen Schichten stammen können: Browser-Downloadlogik, Sicherheitsprüfung, Dateisystem, Synchronisations- oder Bereinigungsmechanismen. Für eine belastbare Analyse zählt deshalb nicht der erste Eindruck, sondern der konkrete Zustand der Datei, der Speicherort und die beobachtbare Folge von Ereignissen: wurde überhaupt geschrieben, wurde nachträglich entfernt, oder ist eine Datei vorhanden, aber nicht nutzbar?

„Verschwunden“: Vier typische Bedeutungen hinter einem Symptom

Im Alltag meint „verschwunden“ meist: Die Datei taucht im Ordner „Downloads“ nicht auf. Das kann heißen, dass der Download nie erfolgreich abgeschlossen wurde. Es kann aber ebenso bedeuten, dass die Datei in einem anderen Zielordner gelandet ist, dass sie als unsicher eingestuft und entfernt wurde oder dass sie zwar existiert, aber durch Filter (Sortierung, Suche, Ansicht) oder durch eine Synchronisationslogik (z. B. Cloud-Ordnerumleitung) aus dem erwarteten Kontext „herausfällt“.

Windows 11 verstärkt diese Mehrdeutigkeit, weil mehrere Komponenten eingreifen können: der Browser schreibt zunächst in temporäre Teil-Dateien, markiert Inhalte ggf. mit Zone-Informationen (Mark-of-the-Web), und Windows-Sicherheitskomponenten können im Nachgang blockieren oder entfernen. Der sichtbare Effekt ist identisch – die Datei ist nicht mehr da – der technische Pfad dorthin jedoch nicht.

• Falscher Zielort durch Download-Einstellungen: Der Browser speichert nicht in %USERPROFILE%\Downloads, sondern in einem abweichenden Pfad wie D:\Downloads oder einem Netzwerkpfad; bei aktivierter Abfrage kann die Auswahl je Download variieren.
• Temporärdatei ohne Abschluss: Bei Abbruch bleibt eine Teil-Datei zurück (z. B. .crdownload in Chrome/Edge oder .part in Firefox) und wird später durch den Browser oder eine Bereinigung entfernt; der Dateiname entspricht dann nicht dem erwarteten Endnamen.
• Nachträgliche Entfernung durch Sicherheitsprüfung: Microsoft Defender oder ein Drittanbieter-Virenscanner verschiebt in Quarantäne oder löscht; der ursprüngliche Speicherort wirkt „leer“, obwohl ein Ereignis im Schutzverlauf existiert.
• Ordnerumleitung/Synchronisation: „Downloads“ kann über OneDrive Known Folder Move, Bibliotheken oder eine Unternehmensrichtlinie auf einen anderen Ort zeigen; sichtbar ist dann ein anderer physischer Pfad als erwartet (z. B. %USERPROFILE%\OneDrive\Downloads).

„Beschädigt“: Wenn die Datei vorhanden ist, aber nicht verwendbar

„Beschädigt“ bedeutet praktisch: Eine Datei liegt vor, lässt sich aber nicht öffnen, entpacken oder ausführen, oder eine Anwendung meldet inkonsistente Inhalte. Häufig ist nicht das Dateisystem defekt, sondern der Inhalt unvollständig oder nicht das erwartete Format. Typische Ursachen sind abgebrochene Übertragungen, fehlerhafte Zwischenspeicherung, eine nachträgliche Blockade/Entfernung durch Sicherheitssoftware (wodurch nur noch eine Teil-Datei übrig bleibt) oder ein Download, der zwar eine passende Endung trägt, aber tatsächlich eine HTML-Fehlerseite oder ein Login/Captcha enthält.

Windows 11 selbst liefert dabei manchmal irreführende Oberflächenhinweise: Eine EXE kann „nicht kompatibel“ wirken, obwohl lediglich der Download unvollständig ist; ein ZIP kann „ungültig“ sein, obwohl nur die letzten Megabytes fehlen. Für die Einordnung zählt deshalb die Trennung zwischen „Datei existiert“ und „Inhalt ist gültig“.

Indikatoren, die „Verschwinden“ von „Blockieren“ und „Abbruch“ trennen

Für eine präzise Diagnose hilft eine kurze, beobachtungsbasierte Einordnung: Tritt das Problem sofort auf oder zeitverzögert? Bleibt eine Teil-Datei zurück? Ändert sich der Dateiname? Wird ein anderer Speicherort angezeigt? Viele Browser schreiben zunächst in eine temporäre Datei und benennen erst nach erfolgreichem Abschluss um. Dadurch entsteht ein klarer Indikator: Wenn eine temporäre Endung dauerhaft bleibt, ist der Transfer nicht sauber abgeschlossen oder wurde im letzten Schritt blockiert.

Ein weiteres Trennmerkmal ist die Reaktion von Windows beim Zugriff: Wird beim Doppelklick eine Sicherheitswarnung oder SmartScreen-Meldung angezeigt, ist die Datei in der Regel vorhanden und wurde klassifiziert. Wenn dagegen bereits im Explorer die Datei „verschwindet“, liegt der Verdacht näher an Quarantäne/Löschung oder an einer Speicherung in einem anderen physischen Pfad (Ordnerumleitung, Synchronisation, Browserprofilwechsel).

• Teil-Download erkennbar: Im Zielordner existiert eine Datei mit temporärer Endung wie .crdownload oder .part; die Größe wächst nicht weiter oder bleibt auf einem festen Wert stehen.
• „Fertig“ laut Browser, aber kein Fund im Ordner: In der Downloadliste lässt sich „Im Ordner anzeigen“ aufrufen; führt das zu einem anderen Pfad, liegt ein Speicherort-Thema vor (häufig %USERPROFILE%\Downloads vs. umgeleitete Pfade).
• Blockade statt Beschädigung: Windows zeigt beim Öffnen eine SmartScreen- oder Defender-Interaktion; technisch ist dann häufig die Vertrauenseinstufung entscheidend, nicht die Dateiintegrität.
• Inhalt passt nicht zur Endung: Bei „beschädigten“ Dateien findet sich oft eine Server-Fehlerseite oder ein Login/Captcha im Download; in solchen Fällen weichen Header/Dateityp vom erwarteten Format ab, obwohl die Endung z. B. .zip lautet.

Warum die genaue Begriffsklärung die weiteren Schritte bestimmt

Die Fehlerklasse entscheidet über das passende Prüfmittel. Ein „Verschwinden“ verlangt zuerst Klarheit über Speicherort, Umleitung und mögliche Entfernung durch Schutzmechanismen; hier sind Pfad- und Ereignisspuren entscheidend. Ein „Beschädigt“-Symptom lenkt dagegen auf Übertragungsabbrüche, inkonsistente Dateiinhalte oder Formatverwechslungen; hier liefern Dateigröße, Hash-Prüfungen und die Existenz von Teil-Dateien die relevanteren Hinweise. Ohne diese Trennung werden schnell Maßnahmen vermischt: Ein erneuter Download löst keine Quarantäne-Richtlinie, und eine Freigabe in SmartScreen repariert keine truncierte ZIP-Datei.

In Windows 11 wirkt zusätzlich die Zone-Markierung aus dem Internet (Mark of the Web) als Signal an SmartScreen und manche Anwendungen. Eine Datei kann dadurch „blockiert“ erscheinen, obwohl sie unverändert und vollständig ist. Umgekehrt kann eine unvollständige Datei völlig unauffällig gespeichert werden und erst beim Öffnen scheitern. Erst die präzise Symptomzuordnung verhindert, dass ein reines Integritätsproblem als Sicherheitsproblem behandelt wird – oder umgekehrt.

Browser-Kontext prüfen: Download-Verlauf, temporäre Dateien, Safe Browsing und Blockaden durch Dateityp oder Richtlinien

Wenn Downloads unter Windows 11 „verschwinden“ oder als beschädigt erscheinen, liegt die Ursache häufig bereits im Browser-Kontext: Der Transfer wurde abgebrochen, in einen temporären Bereich geschrieben und anschließend bereinigt, oder ein Schutzmechanismus hat die Datei vor dem finalen Speichern blockiert. Eine belastbare Analyse beginnt daher im Download-Verlauf, in den Einstellungen des Browsers sowie in den Schutz- und Richtlinienebenen, die zwischen URL, Dateityp und Zielordner vermitteln.

Download-Verlauf und tatsächlichen Speicherort gegeneinander prüfen

Der Download-Verlauf zeigt meist nicht nur den Namen der Datei, sondern auch Statusinformationen wie „fehlgeschlagen“, „unterbrochen“, „blockiert“ oder „entfernt“. Entscheidend ist die Trennung zwischen (a) dem Eintrag im Verlauf und (b) dem realen Dateipfad auf Datenträger. Ein „abgeschlossen“-Status kann irreführend sein, wenn der Browser zwar den Transfer beendet, die Datei aber im Anschluss durch Safe-Browsing, Download-Scanning oder Richtlinien entfernt bzw. in Quarantäne verschoben wurde.

In der Praxis sollte der Verlauf immer mit dem zuletzt verwendeten Zielordner und dem Standard-Downloadpfad abgeglichen werden. Bei aktivierter Option „Vor dem Herunterladen nach Speicherort fragen“ werden Dateien je nach Entscheidung pro Download in wechselnde Verzeichnisse geschrieben. Zusätzlich können Browser bei bestimmten Workflows (z. B. „Öffnen“ statt „Speichern“) die Datei in einem temporären Bereich ablegen und nach dem Schließen der Anwendung oder nach einer Bereinigung entfernen.

Temporäre Download-Dateien und Artefakte: Hinweise auf Abbrüche

Viele Browser schreiben während des Transfers nicht sofort in die Zieldatei, sondern verwenden temporäre Container oder Teildateien. Typische Indikatoren sind unvollständige Dateien mit browser-spezifischen Endungen oder im gleichen Verzeichnis liegende Begleitdateien, die bei erfolgreichem Abschluss umbenannt bzw. entfernt werden. Bleiben solche Artefakte liegen, deutet das auf einen Abbruch nach Beginn des Schreibvorgangs hin. Umgekehrt kann das Fehlen solcher Spuren bedeuten, dass der Download vor dem Schreiben blockiert wurde (Reputation/Policy) oder gar nicht erst gestartet ist (Navigation statt Download, Redirect/Auth-Flow, serverseitige Header).

Zusätzlich spielt das Bereinigungsverhalten eine Rolle: Browser können beim Beenden oder durch integrierte „Daten löschen“-Funktionen temporäre Bereiche leeren. Auch Systemreiniger oder Storage Sense können temporäre Inhalte entfernen, ohne dass der Download-Verlauf sofort konsistent bereinigt wird. Für die Analyse ist daher relevant, ob direkt nach dem Abbruch noch Teildateien existieren und ob die Dateigröße plausibel zur erwarteten Größe passt.

• Chrome/Chromium-Indiz für Teil-Download: Dateien mit der Endung .crdownload im Zielordner weisen auf einen nicht finalisierten Schreibvorgang hin.
• Firefox-Indiz für aktiven/abgebrochenen Transfer: Eine Begleitdatei .part im Download-Verzeichnis deutet auf eine nicht abgeschlossene Übertragung.
• Abgleich mit Standardpfaden: In Windows-Umgebungen ist der Zielordner häufig %USERPROFILE%\Downloads; bei umgeleiteten Ordnern (z. B. OneDrive Known Folder Move) können Pfade wie %USERPROFILE%\OneDrive\Downloads auftreten.
• Zwischenspeicher/Temporärordner als Spur: Bei „Öffnen“-Workflows kann die Datei in temporären Bereichen unter %LOCALAPPDATA% abgelegt und später entfernt werden; das erschwert die Reproduzierbarkeit ohne sofortige Beobachtung nach dem Downloadstart.

Safe Browsing, Download-Scanning und Reputation: warum Dateien nachträglich verschwinden

Moderne Browser koppeln Downloads an Reputations- und Malware-Schutz. Bei Chromium-basierten Browsern ist Google Safe Browsing zentral: Es bewertet URLs und Download-Metadaten und kann je nach Ergebnis einen Download blockieren oder mit Warnungen versehen. In verwalteten Umgebungen kann zusätzlich ein Enterprise-Connector (je nach Browser/Policy) Downloads an einen Cloud- oder On-Premises-Scanner übergeben, der bei Erkennung den Zugriff sperrt oder die Datei entfernen lässt.

Wichtig ist die Abgrenzung: Ein Browser kann den Download blockieren, obwohl der Netzwerktransfer technisch möglich wäre. Umgekehrt kann der Browser speichern, aber das Betriebssystem oder ein Security-Agent entfernt die Datei unmittelbar danach. Im Verlauf erscheinen dann Formulierungen wie „entfernt“ oder „konnte nicht sicher heruntergeladen werden“. Solche Fälle lassen sich meist nur sauber einordnen, wenn Zeitpunkt und Statuswechsel im Verlauf mit dem Auftreten einer Datei im Zielordner korreliert werden.

Blockaden durch Dateityp, Inhalterkennung und Unternehmensrichtlinien

Neben Reputation spielen Dateitypregeln eine große Rolle. Administratoren können über Browser-Policies bestimmte Endungen oder MIME-Typen verbieten, Downloads auf „sichere“ Quellen beschränken oder das automatische Öffnen von Dateien unterbinden. Zusätzlich greifen Schutzmechanismen beim „Dangerous File Type“-Modell: Archive, ausführbare Dateien oder Skripte werden strenger behandelt als Dokumente, insbesondere wenn sie aus dem Internet stammen und später über Mark-of-the-Web (MOTW) bzw. Attachment-Mechanismen als „aus dem Web“ gekennzeichnet werden.

Auch ohne explizite Blockliste können Content-Disposition-Header, falsche MIME-Typen oder Content-Sniffing zu unerwartetem Verhalten führen: Eine HTML-Fehlerseite wird als Datei gespeichert, die Endung suggeriert jedoch ein Archiv oder Installer. Das Ergebnis wirkt „beschädigt“, ist aber inhaltlich eine Webseite. Ein schneller Plausibilitätscheck besteht darin, die Dateigröße zu prüfen und stichprobenartig mit einem Hex-Viewer oder über die Dateieigenschaften festzustellen, ob der Inhalt zur erwarteten Dateiart passt. Solche Checks gehören in den Browser-Kontext, bevor System- oder Datenträgerfehler angenommen werden.

• Erkennung von HTML statt Binärdatei: Unplausibel kleine Datei und beim Öffnen Text wie <!doctype html> deutet auf eine gespeicherte Fehler-/Login-Seite statt des erwarteten Pakets.
• Typische Policy-Ansatzpunkte in Chromium-Umgebungen: Download-Regeln werden häufig über Richtlinien wie DownloadRestrictions, URLBlocklist oder SafeBrowsingProtectionLevel gesteuert (je nach Browser-Distribution und Verwaltungsmodell).
• Firewall/Proxy-Transformation als Fehlerquelle: SSL-Inspection oder DLP kann Downloads umschreiben, komprimieren oder abbrechen; Hinweise liefern abweichende Content-Length-Werte und häufig wiederholbare Abbrüche bei identischen Dateitypen.
• Schreibrechte und Pfadprobleme: Bei Downloads auf Netzlaufwerke oder synchronisierte Ordner treten Abbrüche auf, wenn Sperren, Latenzen oder fehlende Rechte das atomare Umbenennen der temporären Datei verhindern; der Browser meldet dann oft „fehlgeschlagen – Schreibfehler“.

Reproduzierbarkeit schaffen: saubere Testläufe im Browser

Für eine belastbare Einordnung sollten Testdownloads unter kontrollierten Bedingungen erfolgen: gleiche URL, identischer Browser, ein definierter Zielordner und deaktivierte automatische Bereinigungen. Ein zweiter Lauf im privaten Modus kann Cache- und Erweiterungseinflüsse reduzieren, ersetzt jedoch keine Policy-Prüfung, da Richtlinien in verwalteten Installationen weiterhin greifen. Ebenfalls relevant ist der Erweiterungsstapel: Download-Manager, Security-Extensions und Werbeblocker können Requests umleiten, Header verändern oder Dateinamen normalisieren, was wiederum die Zuordnung zwischen Verlauf und Datei erschwert.

In dieser Phase zählt weniger die „Reparatur“ als die genaue Beobachtung: Zeitpunkt des Startens, Statuswechsel im Verlauf, Auftauchen einer Teildatei, finaler Dateiname, Größe und eventuelle sofortige Löschung. Erst wenn der Browserpfad sauber nachvollzogen ist, lohnt der Wechsel in die Systemebene (SmartScreen, Defender/AV, Ereignisanzeige), weil sich dann Browser-Blockade und nachgelagerte Entfernung klar trennen lassen.

System-Kontext prüfen: SmartScreen, Microsoft Defender, Drittanbieter-AV, Quarantäne und Ereignisprotokolle zur Ursachenfindung

Wenn Downloads unter Windows 11 „verschwinden“, nur als Teil-Datei auftauchen oder sich nach dem Abschluss nicht öffnen lassen, liegt die Ursache häufig nicht im Browser selbst, sondern im Systemkontext: Reputationsprüfung, Echtzeitschutz, Quarantäne-Mechanismen, kontrollierter Ordnerzugriff oder Filtertreiber können Dateien unmittelbar nach dem Schreiben blockieren, verschieben oder löschen. Für eine belastbare Diagnose zählt daher die zeitliche Korrelation: Zeitpunkt des Downloadstarts, Zeitpunkt der Blockierung und die dazugehörigen Einträge in Sicherheits- und Systemprotokollen.

SmartScreen und Reputationsschutz: Blockieren, Warnen, Entfernen

Microsoft Defender SmartScreen bewertet heruntergeladene Inhalte anhand von Reputation, Signaturstatus und weiteren Signalen. Je nach Konfiguration resultiert das typischerweise in einer Warnung im Browser oder in einer Blockierung beim Start (App-Reputationsprüfung). Eine tatsächliche Entfernung/Quarantäne erfolgt in der Regel durch Microsoft Defender Antivirus oder eine andere Endpoint-Lösung, nicht durch SmartScreen allein. Typisch sind Fälle, in denen der Download zunächst vollständig erscheint und kurz darauf „verschwindet“, weil die Datei nach dem Schreiben im Zielordner durch nachgelagerte Prüfungen als riskant eingestuft und entfernt/quarantänisiert wird.

Zur Abgrenzung ist wichtig, ob SmartScreen nur die Ausführung verhindert (Warn-Dialog beim Öffnen) oder ob der Virenschutz die Datei tatsächlich in Quarantäne verschiebt. SmartScreen-Ereignisse können – je nach Build, aktivierten Kanälen und Richtlinien – in SmartScreen/Explorer-bezogenen Protokollen auftauchen; in der Praxis ist jedoch die Defender-Historie meist der schnellere Indikator, weil Reputation und Malware-Befunde dort zusammenlaufen.

Microsoft Defender: Schutzverlauf, Quarantäne, kontrollierter Ordnerzugriff

Der Windows-Sicherheitsverlauf dokumentiert, ob eine Datei beim Download, beim Zugriff oder beim Ausführen blockiert wurde. Besonders relevant sind drei Mechanismen: Echtzeitschutz (scannt Schreibvorgänge), cloudbasierter Schutz (liefert schnelle Reputationsergebnisse) und „Überwachter Ordnerzugriff“ (Controlled Folder Access) als Teil von Ransomware-Schutz. Letzterer blockiert primär nicht autorisierte Schreibzugriffe auf geschützte Ordner; je nach Zielpfad und beteiligter Anwendung kann das dazu führen, dass Folgeoperationen (Verschieben/Entpacken/Installer-Schreibvorgänge) scheitern, obwohl der Download selbst im Browser als „abgeschlossen“ erscheint.

Für die Ursachenfindung sind Name und Pfad der betroffenen Datei, die erkannte Bedrohung (oder PUA:Win32-Klassifizierung), die Aktion (Quarantäne/Entfernen/Blockieren) sowie der Zeitpunkt entscheidend. Bei wiederkehrenden Falschpositiven ist außerdem relevant, ob das Zielverzeichnis in OneDrive-geschützten Ordnern liegt oder ob der Download in eine synchronisierte Bibliothek geschrieben wurde, da zusätzliche Hooks und Sync-Scanner die zeitliche Reihenfolge der Dateizugriffe verändern können.

• Defender-Schutzverlauf öffnen: windowsdefender://threat/
• Quarantäne/Erkennungen prüfen (PowerShell): Get-MpThreatDetection
Get-MpThreat
• Aktuellen Status und Richtlinienindikatoren anzeigen: Get-MpComputerStatus
• Letzte Erkennungen aus der Ereignisanzeige abfragen: Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 50
• Kontrollierten Ordnerzugriff identifizieren: Get-MpPreference | Select-Object EnableControlledFolderAccess, ControlledFolderAccessProtectedFolders

Drittanbieter-Antivirus und Filtertreiber: Parallelwelten im Dateizugriff

Zusätzliche Endpoint-Suiten binden sich über Minifilter in den Dateisystem-Stack ein und prüfen Datenströme häufig bereits während des Downloads. Dadurch können Zeitfenster entstehen, in denen der Browser eine Datei als „fertig“ meldet, das AV-Produkt aber den letzten Schreibvorgang verzögert, die Datei sperrt oder unmittelbar entfernt. Im Explorer wirkt das wie ein „Verschwinden“, technisch handelt es sich jedoch oft um ein Timing-Problem zwischen Browser, AV-Scanner und nachgelagerten Komponenten (z. B. Indexierung oder Sync-Client).

Für belastbare Ergebnisse sollten Logs des Drittanbieterprodukts herangezogen werden (Quarantäne, Webschutz, Download-Scanning). Zusätzlich lohnt ein Blick auf die installierten Filtertreiber, um zu verstehen, welche Komponenten im I/O-Pfad sitzen. Auffällige Kandidaten sind Produkte, die TLS-Inspection, Webschutz oder DLP-Module implementieren, weil sie nicht nur Dateioperationen, sondern auch Netzwerkströme umleiten.

• Registrierte Dateisystem-Filter anzeigen: fltmc filters
• Defender-Status bei Drittanbieter-AV prüfen: Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusEnabled, RealTimeProtectionEnabled
• Windows-Sicherheitscenter (WMI) für AV-Registrierung abfragen: Get-CimInstance -Namespace "root/SecurityCenter2" -ClassName AntiVirusProduct | Select-Object displayName, productState

Ereignisprotokolle gezielt auswerten: Defender, Application Control, Dateisystem

Die Ereignisanzeige liefert die sauberste Zeitachse, wenn Browser-Anzeigen und tatsächlicher Zustand im Dateisystem auseinanderlaufen. Zentral ist das Defender-Operational-Log, weil es Erkennungen, Aktionen und teilweise auch Pfade dokumentiert. Ergänzend können Richtlinien wie Windows Defender Application Control (WDAC) oder AppLocker Ausführungen verhindern, ohne dass eine Datei entfernt wird; in solchen Fällen bleibt der Download bestehen, scheitert aber beim Start oder beim Laden durch ein anderes Programm.

Bei Verdacht auf systemweite Integritäts- oder Datenträgerprobleme sollten zusätzlich System- und NTFS-bezogene Einträge geprüft werden. Ein „beschädigter“ Download ist manchmal kein Sicherheitsereignis, sondern Folge von I/O-Fehlern, abrupten Neustarts oder Speichermedienproblemen. Solche Ursachen zeigen sich typischerweise in Systemlogs (Disk, Ntfs, StorPort) und passen zeitlich zu Abbrüchen oder zu Dateien mit unerwarteter Größe.

• Defender-Operational nach Aktionen filtern: Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Windows Defender/Operational"; StartTime=(Get-Date).AddDays(-2)} | Select-Object TimeCreated, Id, Message
• WDAC/CodeIntegrity prüfen (falls aktiv): Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" -MaxEvents 100
• AppLocker prüfen (wenn konfiguriert): Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" -MaxEvents 100
• Datenträger-/NTFS-Fehler im Systemlog korrelieren: Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName=@("Disk","Ntfs","storahci","stornvme","Microsoft-Windows-StorPort"); StartTime=(Get-Date).AddDays(-2)} | Select-Object TimeCreated, ProviderName, Id, Message