Download-Bug bei Microsoft Edge 103.0.1264.44: .crdownload-Dateien bleiben zurück

Edge[English]Kleine Abwandlung an den Funkspruch von Apollo  13: "Microsoft, wir haben ein Problem". Mit dem zum 30. Juni 2022 freigegebenen Update auf Microsoft Edge 103.0.1264.44 stellen Benutzer vermehrt fest, dass sich nach Downloads (z.B. von .exe- und .msi-Dateien, aber auch anderen Dateien) temporäre Download-Reste (.crdownload-Dateien) im Download-Ordner zurück bleiben.


Anzeige

Eins vor, eins zurück: Edge 103.0.1264.44

Microsoft hat zum 30. Juni 2022 den Edge-Browser im Stable Channel auf die Version 103.0.1264.44 aktualisiert. Es ist ein Wartungsupdate, welches die als kritisch eingestufte Elevation of Privilege-Schwachstelle CVE-2022-33680 (Ausbruch aus der Sandbox) beseitigt. Ich hatte im Blog-Beitrag Microsoft Edge 103.0.1264.44 fixt CVE-2022-33680 (30. Juni 2022) berichtet, dass dieses Browser-Update auch den im Artikel Edge Stable 103.0.1264.37 macht Gruppenrichtlinien kaputt (Chrome-Bug) behebt. Es geht also einen Schritt voran. Leider geht es auch einen Schritt zurück, da es nun einen Download-Bug gibt.

Der Download-Bug

Bereits kurz nach Veröffentlichung des Beitrags Microsoft Edge 103.0.1264.44 fixt CVE-2022-33680 (30. Juni 2022) meldeten sich Blog-Leser und berichteten von Download-Problemen. MOM20xx schreibt:

ach ja auch diese Version macht bei Downloads wieder Mist

Seit der letzten Major Release bleiben mir auf allen Rechnern nach einem Download Files mit Namen beginnend "Nicht bestätigt …" und Grösse 0 übrig – zusätzlich zum eigentlichen Download. Ich mein da bei deskmodder auch was schon diesbzgl. gelesen zu haben

Blog-Leser Carsten bestätigt diese Probleme:

Moin,

das kann ich so zumindest auf Win11 Insider und Win11 Business (beides ohne Edge Policies) für den Download von .exe und .msi Dateien bestätigen. Auf Server 2016 mit "Block malicious downloads and dangerous file types" als Download Restriction in der GPO kommt das nicht vor.
Gibt es irgendwo Infos darüber, was MS im Edge Release funktional geändert hat, außer die Infos zu den CVEs?

Blog-Leser Bernie hat mir dankenswerterweise einige Screenshots bereitgestellt. In nachfolgendem Screenshot ist der Download der Microsoft Edge MSI-Version zu sehen. Der Edge meldet, dass der Download vorhanden sei und bietet die Schaltfläche an, um auf den Download-Ordner zuzugreifen.

Edge MSI-Download

Beim Blick in den geöffneten Download-Ordner erlebt der Benutzer aber eine Überraschung, wie in nachfolgendem Screenshot zu sehen ist. Der benötigte Download ist zwar vorhanden (hier die MicrosoftEdgeEnterpriseX64.msi).

Edge MSI-Download-Schrott im Zielordner

Aber es gibt eine leere Datei Nicht bestätigt xxxxx.crdownload mit einer Größe von 0 KB. Das ist die temporäre Datei, die von Chromium-Browsern für die Zwischenspeicherung des Downloads verwendet wird. Erst wenn alle Segmente des Downloads erfolgreich vom Download-Manager übermittelt wurden, kopiert der Browser das Ergebnis unter dem Namen der Zieldatei ab (hier die .msi-Datei). Gleichzeitig wird im Folgeschritt die alte .crdownload-Datei gelöscht, da nicht mehr benötigt. Dieser Schritt funktioniert im Microsoft Edge 103.0.1264.44 aber nicht mehr, so dass der Download-Order mit temporären Download-Dateien der Größe 0 zugemüllt wird.


Anzeige

Bernie war so freundlich, einen Link auf diese Diskussion bei Dr. Windows zu posten. Dort wird bereits der Edge 103.0.1264.37 mit diesem Problem berichtet. Dort findet sich die Aussage, dass die temporären Reste bei allen Dateitypen beim Download zurückbleiben. Hier im Blog gibt es in den Kommentaren vor allem den Hinweis auf .exe- und .msi-Dateien.

Recherchiert man im Internet, kommt dieser Fehler seit längerem immer wieder in Anfragen (z.B. auf reddit.com hier und hier). Auf Techcommunity gibt es diese ältere Diskussion vom April 2022 zum Edge 100, wo dies auch schon beobachtet wurde.

Das Ganze deutet darauf hin, dass der Edge-Browser beim Download nicht alle Zustände, vom Herunterladen der Datei-Fragemente, über die Virenschutzprüfung zum Kopieren des Ergebnisses in die Zieldatei bis hin zum Löschen der temporären .crdownload-Datei erfolgreich durchlaufen kann. Der letzte Schritt scheitert, möglicherweise, weil die .crdownload-Datei gesperrt ist.

Erste Vermutung meinerseits wäre, dass eine Drittanbieter Virenschutzlösung den Download zum Löschen blockiert. Aber auf Dr. Windows gibt es hier und hier den Hinweis, im Windows-Sicherheitscenter im Bereich App- & Browsersteuerung auf Verwerfen zu klicken. Dann ist dort im Zuverlässigkeitsbasierten Schutz der Punkt:

  • SmartScreen für MS Edge zu deaktivieren und
  • die Option Potenziell unerwünschte Apps werden blockiert ist zu aktivieren

Das signalisiert, dass das Problem in den bordeigenen Windows-/Edge-Schutzmechanismen zu suchen ist. Die Deaktivierung sollte man sich aus Sicherheitsgründen gut überlegen. Aktuell bleibt eigentlich nur, auf einen Fix von Microsoft zu warten – einzelne Nutzer haben über die Edge-Feedback-Funktion den Fehler gemeldet – ob das gelesen wird, weiß ich nicht. Ich versuche auf jeden Fall den englischsprachigen Beitrag an Microsoft zu melden (ist über Twitter erfolgt).

Ähnliche Artikel:
Microsoft Edge 102.0.1245.30 erzeugt Fehler beim PDF-Drucken
Workaround für Edge 102.0.1245.xx PDF-Druckprobleme
Edge 102.0.1245.30 ff.: "Hardware-erzwungener Stackschutz" verhindert Start
Edge Stable 103.0.1264.37 macht Gruppenrichtlinien kaputt (Chrome-Bug)
Microsoft Edge 103.0.1264.44 fixt CVE-2022-33680 (30. Juni 2022)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Edge, Software abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

24 Antworten zu Download-Bug bei Microsoft Edge 103.0.1264.44: .crdownload-Dateien bleiben zurück

  1. MrX1980 sagt:

    Moin, ich kann bestätigen, dass es schon länger so ist und nicht erst mit der Edge Version 103.0.1264.44. Ich nutze den Windows Defender.

    Übrig bleibt auch bei mir:
    Nicht bestätigt 836357.crdownload
    Nicht bestätigt 628709.crdownload

    Aufgrund der Sonderzeichen/Umlaute im Dateinamen, könnte es ein länderspezifisches (deutsches) Problem sein. Daher dauert es sicherlich länger bis Microsoft darauf reagiert.

      • Peter sagt:

        Das schein so zu sein. Ich habe das einmal genauer angeschaut. Bei einem Download werden zwei Dateien erzeugt:
        "Nicht bestätigt xxxxx.crdownload"
        "Nicht bestätigt xxxxx.crdownload"

        Die Datei "Nicht bestätigt xxxxx.crdownload" wird auch ordnungsgemäß wieder gelöscht, die Datei "Nicht bestätigt xxxxx.crdownload" bleibt zurück.

        Ich vermute, das Problem liegt nicht beim Löschen der Datei, sondern das diese schon falsch angelegt werden bzw. wird.

  2. J. Dessecker sagt:

    Hallo Herr Born,

    das Problem muss schon länger bestehen. Ich kenne das bereits seit einigen Wochen.

    Mit freundlichen Grüßen,

    J. Dessecker

  3. Grisu_1968 sagt:

    Ich hatte in älteren Versionen das Problem das .crdownload Dateien zurückgeblieben sind. Seit dem Update auf Edge 103.0.1264.44 habe ich das Problem nicht mehr.

    Dieses Thema wird seit einiger Zeit auch bei dr.windows.de behandelt. Link: https://www.drwindows.de/xf/threads/downloads-mit-edge-crdownload-anhang.180859/
    Eventuell gibt es da einen Zusammenhang mit dem Deutsch Local Experience Pack? Ist jetzt nur eine Verutung wegen solcher "Nicht bestätigt 123456.crdownload" kryptischen Bezeichnungen?

  4. Luzifer sagt:

    da hakt irgendwie die Aufräumfunktion nach dem Download, hab das Problem nur wenn ich nen Download abbreche, dann werden die crdownload Daten nicht mehr gelöscht, läuft der Download durch existiert das Problem nicht, sprich dann werden die Temp Daten auch sauber entfernt. Kommt es zum Abbruch oder hakt sonst wie beim Download erkennt Edge/Windows das nicht mehr und räumt nicht auf.

  5. MOM20xx sagt:

    das Problem ist etwas tiefergreifender meines Erachtens und hat auch was mit lokalisierung zu tun.

    nimmt man eine ausreichend grosse datei, damit der download länger aktiv ist wie bspw. https://www.microsoft.com/de-de/download/details.aspx?id=102619

    so stelle ich bei mir folgendes fest:

    der download startet mit

    "Nicht bestätigt 676173.crdownload" ist der download fertig verschwindet diese Datei, die exe erscheint und zusätzlich die Datei "Nicht bestätigt 676173.crdownload" wo eben der Umlaut im Dateinamen falsch kodiert ist.

    Vielleicht kann das so auch noch jemand nachstellen. Weil wenn das file nur gelocked wäre würd es ja weiterhin "Nicht bestätigt 676173.download" heissen.

  6. Carsten sagt:

    Womöglich liegt das Problem an der neuen SmartScreen Engine, die mit dem Release 103.0.xx.xx eingeführt wurde. Wir hatten festgestellt, das im Edge ohne Defender auf Server 2016, die vorher mit 102.0.xx.xx funktionierenden SmartScreen Blocks, nicht mehr angewendet wurden. Per GPO kann allerdings die "alte" SmartScreen Engine wieder zugewiesen werden, die dann einwandfrei funktioniert.
    Tests haben wir mit der SmartScreen Demoseite von MS durchgeführt https://demo.smartscreen.msft.net/
    Vielleicht kann das jemand bestätigen.

    • Christoph sagt:

      Hallo,

      ja, das Problem konnte mit der alten Library-Version umgangen werden ("Enable new SmartScreen library = Disabled, dazu benötigt man die aktuellsten admx-Templates, oder via Registry – HKCU\SOFTWARE\Policies\Microsoft\Edge\NewSmartScreenLibraryEnabled = 0, danach Neustart des Browsers und geht wieder)

      • CarstenW sagt:

        Das Problem mit der alten SmartScreen Engine ist: Sie ist deprecated und soll mit Edge 105 komplett aus dem Browser entfernt werden. Die neue Engine läuft bei uns unter Windows Server 2016 leider nicht sauber, debug trace zeigt, dass sie in einen Timeout läuft und als Ergebnis dann kAllow liefert (also die Aktion einfach zulässt)…
        {"args":{"response":"NO RESPONSE"},"cat":"SmartScreen","id":"0x2f41dd8d478200","name":"SendRequestProxy","ph":"n","pid":576,"scope":"SmartScreen","tid":5024,"ts":93752716811},
        {"args":{"result_decision":"decision=kAllow, \nurl:https://ntp.msn.com/edge/ntp?locale=en-US&title=New%20tab&dsp=1&sp=Bing&prerender=1","step":"OnComplete"},"cat":"SmartScreen","id":"0x2f41dd8d477a47","name":"CheckUrlsForNavigation","ph":"T","pid":576,"scope":"CheckUrlsForNavigation","tid":5024,"ts":93752716902},
        {"args":{"error":"SS_ERROR_TYPE_CLIENT_CRITICAL","step":"SmartScreenError"},"cat":"SmartScreen","id":"0x2f41dd8d477a47","name":"CheckUrlsForNavigation","ph":"T","pid":576,"scope":"CheckUrlsForNavigation","tid":5024,"ts":93752716910},

        Unter Windows 10 läuft die neue SmartScreen Engine hingegen sauber. Kann mir das unterschiedliche Verhalten leider nicht erklären. Auch wenn Defender unter Windows Server 2016 aktiviert ist und läuft, die OS SmartScreen Engine vorhanden ist, läuft die neue Edge Chromium Browser SmartScreen Engine an die Wand.

  7. MichaelK sagt:

    Kann man die cdrdownloaddatei nicht irgendwie per Batchdatei oder so automatisch löschen lassen zumindest bis es eine richtige Lösung gibt.
    Ich nutze Edge"103.0.1264.49" und das Problem ist das selbe wie bei Edge"103.0.1264.37".
    Bin schon gewillt Edge zu verbannen.

  8. MichaelK sagt:

    Im Microsoft-Edge "103.0.1264.62"das selbe Problem.Keine Besserung.Cdrdownload Datei bleibt zurück

  9. merinber sagt:

    Das Problem hatte ich in der vorletzten Version von Edge auch. Nach dem darauf folgendem Update verschwand das Problem. Nun spukte der Ungeist wieder in der aktuellen Version 104.0.1293.54.

  10. Wildp sagt:

    Auch hier tritt das Problem immer mal wieder auf, kann aber nicht anhand Dateigröße o.Ä. festgemacht werden, bei 3 maligem Download der gleichen Datei:
    – "Nicht bestätigt xxxxxx.crdownload" Datei wird erstellt
    – nach Abschluss verschwindet diese
    – in einem von 3 Versuchen wurde dann die tatsächliche Datei & eine Nicht bestätigt xxxxxx.crdownload Datei mit 0 byte erstellt.
    – bei den anderen beiden Versuchen (gleicher Rechner) blieb keine .crdownload-Datei zurück

  11. Erdin sagt:

    Das problem mit dem crdownload file besteht weiterhin Version 104.0.1293.63 (Offizielles Build) (64-Bit)

  12. ZinnStop sagt:

    Das ganze ist ziemlich schräg … derzeit noch Edge Version 102.0.1245.44 (im Hintergrund sei gerade ein Update aktiv) auf einem selten genutzten W11 (gestern für Tests hervorgekramt; zuvor letztmals vor einigen Monaten eingesetzt) …

    Eine Datei wird begonnen, heruntergeladen zu werden, und im Zielverzeichnis ist vorläufig "Nicht bestätigt 123456.crdownload" zu sehen (NB: mit korrektem ä geschrieben). Nachdem die Datei vollständig heruntergeladen ist und im Verzeichnis dann mit eigenem Namen auftaucht, bleibt danach ein "Nicht bestätigt 123456.crdownload" zurück …

  13. Anonymous sagt:

    Der Fehler dürfte wieder vorhanden sein!
    Microsoft Edge 120.0.2210.61 in Windows 10/11

    Der download (einer pdf-Datei) wird zwar durchgeführt, die Datei "Nicht bestätigt 643904.crdownload" im Downloadordner angelegt, der Download wird aber nicht vollständig abgeschlossen und die "Nicht bestätigt 643904.crdownload" auch nicht gelöscht. Es gibt somit keine downgeloadete pdf-Datei. In der Edge-Vorgängerversion funktionierte alles korrekt.
    Scheint offensichtlich wieder ein bug in Edge zu sein. Es bleibt also nur übrig – wie oben schon einmal erwähnt – auf einen Bugfix von Microsoft zu warten!

    • Diehl sagt:

      ja, bei mir heute das gleiche Problem festgestellt (Aktualisierung erfolgte wohl am 10.12.23). Ich habe mir einen Wolf gesucht…wegen evtl. fehlerhafter Einstellungen…bis ich zum Glück diese Seite mit der letzten Meldung gefunden habe…:-)

  14. Anonymous sagt:

    Der Fehler ist beseitigt!
    Microsoft Edge 120.0.2210.77 in Windows 10/11

    Heute Abend, 15.12.2023, gab es von MS ein Edge update, jetzt funktioniert wieder alles.

Schreibe einen Kommentar zu merinber Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.