Kurz notiert, aber wichtig. 7-zip hat ein neues Update auf die Version 26.02 erhalten. Die Release Notes ist sehr kurz und allgemein gehalten. Aber wichtig ist das Update trotzdem. Denn neben einigen Korrekturen wurden auch Sicherheitslücken geschlossen.
Man kann davon ausgehen, dass andere Programme, die auch 7-Zip als Basis nutzen, zeitnah nachziehen und die 26.02 integrieren. Falls einige Antiviren-Programme noch anschlagen sollten, dürfte sich das in ein paar Stunden wieder legen. Die Signaturen müssen erst aktualisiert werden.
[Update]: Von Jo habe ich eine Mail erhalten (danke dafür) mit dem Hinweis, dass sich bei ihm die 7-zip.dll nach dem Update auf die 26.02 nicht aktualisiert hat und bei der Version 26.01 blieb. Dafür wurde eine 7-zip.dll.tmp platziert.
Jo hat dann die 7-zip.dll.tmp mal umbenannt und festgestellt, dass diese die Version 26.02 hat. In der Registry unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager war dann ein Eintrag pending deletion. Nachdem er dann 7-Zip deinstalliert hatte, war auch der Eintrag weg. Es erfolgte ein Neustart und eine Neuinstallation. Danach war dann die 7-zip.dll wirklich in der Version 26.02 vorhanden.
Ihr könnt bei euch ja einmal nachschauen, ob es ebenfalls so angelegt wurde. Jetzt, da die Seite wieder geht, will Jo auch Igor Bescheid geben.
Info und Download:
Danke an alles für den Hinweis.
Wie üblich warnt MS Defender vor der Ausführung der .exe
Also noch einen Moment warten, bis die Signaturen aktualisert wurden.
Worauf warten, wenn man die Warnung abnicken kann?
deswegen z.B.:
https://stadt-bremerhaven.de/cpu-z-und-hwmonitor-vorsicht-vor-malware/
Nur weil bei solchen neuen Files immer wieder false positve vorkommen, heißt es ja nicht dass die irgendwann doch mal verseucht sind!
Irgendetwas stimmt hier nicht.
Die Seite 7-zip-org wird im Vivaldi und Edge als unsicher eigestuft und deshalb nicht aufrufbar.
War bei mir bisher nicht der Fall.
Sollte jetzt auch 7-zip mit Schadware kompromittiert worden sein, dann verzichte ich zukünftig auf dieses Programm. Gibt ja genug Alternativen.
Die Seite lässt sich derzeit nicht aufrufen
„www.7-zip.org antwortete dem Gateway nicht.“
Ja, diese Meldung steht bei mir auch.
Jedoch oben in dem Adressfeld steht vor der URL „unsicher ….“
Wenn ich mich richtig erinnere, dann war das bei CPU-Z auch so der Fall.
Aber hoffen wir mal das Beste. Wäre schade, aber heutzutage ist es leider nicht unwahrscheinlich, dass da nicht ein Hackerangriff dahinterstecken könnte.
Bei Computerbase wird die neue Version bisher nicht zum Download angeboten und das ist schon etwas verwunderlich, denn die sind eigentlich immer sehr schnell mit dem Einstellen von neuen Versionen.
https://github.com/ip7z/7zip – Da könnt ihr auch sehen, was sich geändert hat.
der link ist gut. anschließend auf der page nach rechts zu 7-zip 26.02 latest, da läuft dann auch das downloaden. irgendwie strange das ganze. Norton findet nichts zu meckern. Was übrigens auch tut: 7-zip aufrufen und über den Weg ‚Hilfe‘ und den button http://www.7-zip.org das herunterladen, was man benötigt.
Aehm, da hat sich wohl wegen der Hitze irgendwo eine Bit-Blockade gebildet :-))))))))))))))))))))))) Das ganze kühlt bestimmt dann auch wieder ab, irgendwann.
Also da habe ich keine Angst.
Wegen maleware da würde Norton inner 1 Sekunde das file in die Quarantäne, versetzten, wenn was drin währen
Die Releasenotes in der History-Datei auf der Homepage ist extrem knapp und wenig aussagekräftig gehalten.
Da steht bei der 26.02 nur:
– Some bugs and vulnerabilities were fixed.
Ist nicht wahr.
Entschuldige, aber das konnte ich mir jetzt nicht verkneifen.
Checkt es selbst:
https://www.isitdownrightnow.com/7-zip.org.html
Siehe unter: Down Right Now
Hilft nur warten
7-zip.de – Noch die „alte“ Version
Warum? sourceforge.net ist doch oben als offizielle Quelle verlinkt.
Die Originalwebseite (https://7-zip.org/) ist – spätestens nach einem Refresh – aktuell.
Die .de-Seite ist nicht vom Entwickler (s. Impressum)!
https://www.7-zip.org/ lässt sich hier ohne Probleme aufrufen
Dann funktioniert sie wieder.
Danke für den Hinweis von Jo mit der .dll, ich kann hier die selben Beobachtung machen.
Mal sehen, was Mr. Pavlov da unternimmt.
Eben geupdatet, DLL auf 26.02 keine Tempdatei….
Die .tmp Geschichte ist ganz normal, passiert bspw mit WinRAR genauso WENN eine .dll grad in Benutzung ist. Dann wird die neue als .tmp angelegt und überschreibt beim nächsten Neustart durch die PendingOperations in der Registry die alte Datei.
Hast recht!
Ich musste gerade aus anderen Gründen einen Neustart machen, und nun ist es so, wie Du gesagt hast:
Die .tmp ist weg, und die .dll nun die richtige.
Der Neustart machte den Unterschied.
Wieder was dazugelernt, vielen Dank dafür!
Kann ich hier nicht beobachten. Hat auf Anhieb geklappt. Aber ich hatte auch bei der Installation 7-zip geschlossen.
Die Version 26.02 x64 hier auf zwei Rechnern (Win10 und Win11) über die 26.01 drüber installiert und alles normal wie bisher auch.
Die Sache mit dieser temporären Dll ist schon merkwürdig.
Ich bin sicher keiner mit einem Aluhut, aber irgendwie habe ich, wie schon weiter oben von mir angemerkt, ein maues Gefühl bei dieser Version. Obwohl die Installation bei mir vermeintlich sauber über die Bühne gelaufen zu sein scheint.
Hab über die 26.01 installiert aber kein temporären Dll.
Same here. Tmp Datei und dll noch alt…
Gruss Uwe
7-zip und PC bleiben verwundbar, wenn:
.
Dass die alte DLL im Programmordner nach einem Update erhalten bleibt ist nur dann der Fall, wenn seit dem letzten Start des Rechners 7-zip genutzt wurde und es ist auch dann der Fall, wenn unter einem solchen Umstand 7-zip deinstalliert wird. Die neue Version als tmp-DLL existiert unter solchen Umständen nur dann für kurze Zeit, wenn ein Update durchgeführt wird.
.
Es fehlt also beim Installer als auch beim Uninstaller ein Hinweis zu einem gegebenfalls erforderlichen Neustart.
.
Da beim Update das 7-zip als auch der PC bis zum Neustart weiterhin verwundbar bleiben können, wäre dieser Hinweis angemessen.
.
Wenn seit dem PC-Start 7-zip nicht verwendet wurde, dann kommt es vor, dass die DLL beim Update auch ohne Reboot sofort getauscht wird.
.
Der richtige Name in der REG ist PendingFileRenameOperations (REG_MULTI_SZ), dessen Inhalt mehrzeilig sein kann. Er existiert nur in den beschriebenen Situationen und verschwindet nach einem Reboot.
Was aber nicht passiert, weil es bei den meisten hier klappt. Hat nicht jeder probleme mit installern und DLLs die noch geöffnet sind weil deren Kiste prozesse im hintergrund nicht schließen kann.
Bestimmt wieder Raptor Lake.
Wenn ein PendingFileRenameOperations ansteht, kann das ein Installer/Uninstaller auswerten und einen Hinweis einblenden.
.
Deinem Beitrag kann ich keinen Mehrwert entnehmen. Vielmehr ist es eher so, dass du andere abquailifizierst, weil du vorgeblich neuere (bessere) Hardware als andere nutzt und Du dich damit aufwertest und dein Gegenüber abwertest.
:
Solange Windows auf einer unterstützten Hardeware läuft und 7-zip für Windows 2000 bis Windows 11 konzipiert ist, ist dein Beitrag aber auch aus fachlicher Sicht unangebracht.
7-Zip ist ein essentieller Teil von Windows, ich sage nur mal kurz -Windows-Defender nutzt es und hat es in jeder aktuellen Windows-Installation- und diverse andere Hersteller nutzen es, die für Windows Software herstellen. „Erkläre mir mal einer“ warum Microsoft das nicht kauft und selbst für die Updates (überall in Windows) sorgt, die kaufen so viel Mist und vergessen stets die wichtigen Sachen einzukaufen.
Wenn du hier diskutieren willst, bleib bei einem Namen. Ansonsten lösche ich die Kommentare.
@moinmoin
Erklärung: „Skat am Vormittag hier“ (Der Post ist von Elias)
Das Problem mit dem Nichtupdate gab es mit winget/unigetui von 26.00 auf 26.01.0.0 auch schon.
Es scheinte mir so, dass winget jetzt mit der .msi statt der .exe Setupdatei updatete und das warum auch immer nicht richtig funktionierte.
Ist aber nur eine Vermutung.
Auf jeden Fall alle Versionen der 7z*.dll und 7z*.exe danach selbst überprüfen. Die stimmten auch nicht obwohl keine Zombidatei(en) zurückgeblieben war.
Sollte es nicht funktioniert haben einfach deinstallieren und mit dem .exe Setup 26.02 danach neu installieren. Erscheint dann wieder als installierte Version 26.02 statt 26.02.0.0 und alle Dateien stimmen.
Die alte/n 7z.dll 7z.exe sind überall in Windows, selbst nach dem aktuellen AMD-Update: amd-software-adrenalin-edition-26.6.3-win11-c – hofix.exe und diese sind teilweise nicht per Hand austauschbar, erst durch das nächste 3part Upd. Ein Blick in: C:\Program Files\AMD\AMDInstallManager und 7z.dll und 7z.exe (alt)
Ich sehe gerade, dass bei mir die 7-zip.dll sogar noch auf Version 26.0.0 ist, obwohl vor dem Update auf die 26.2.0 die 26.1.0 installiert war, und es seit der Installation Ende April natürlich schon mehrere Neustarts gab – alleine schon wegen der Windows 10 ESU-Updates.. Im Installationspaket der 26.1.0 ist die 7-zip.dll aber mit Version 26.1.0 enthalten. Ich habe die noch und gerade mal reingeschaut. Also da hat der Austausch dann gar nicht funktioniert.
ich meine, dass ich beim Test des 7-zip-Problems auch diesen Fall beobachtet hatte, dass die DLL einfach auf dem alten Stand blieb – trotz reboot.
.
Da Du es aber auch so wie ich gesehen hast, hatte ich mich wohl dann doch nicht getäuscht und das Problem ist größer als gedacht.
.
Ich muss aber auch sagen, dass bei den diversen Umständen und zahlreichen Varianten ich nicht alles sofort notierte und wollte mich nicht mit unbestätigten Behauptungen aus dem Fenster lehnen. Die ganzen „wenn, dann“-Umstände festzuhalte kostet leider viel Zeit.
Also bei mir hat sich die wohl auch nicht upgedatet. Alte Version deinstallieren, neue installieren.
Anscheinend ist da wohl ein Fehler in der Setup-Routine drinnen, der die Datei nicht vollständig erneuert oder erneuern kann?
Oder es hängt mit einer anderen Kombination zusammen.
Ich hab so ein ähnliches Phänomen derzeit auch bei der NanaZIP Version, dass ich sie nie updaten kann, weil angeblich das Programm in Benutzung ist. Was aber nicht sein kann, weil ich sie nie bewusst geöffnet habe und auch mind. 1-2 Neustarts dazwischen liegen (also echte Neustarts, kein herunterfahren und wieder einschalten). Ich muss da im Taskmanager nach einem laufenden Prozess von NanaZIP suchen, den beenden, dann geht erst die Aktualisierung obwohl es weder im Autostart noch ein sichtbarer Dienst dafür vorhanden ist, welcher NanaZIP im Hintergrund starten würde beim hochfahren. Hab ich auch bis jetzt noch nicht verstanden, ob sich ein Prozess oder ein Dienst automatisch startet, den das Updatezenario nicht beenden kann oder ob das Update selbst das Problem verursacht. War nun schon bei den letzten 2 Updates der Fall
laut Autoruns von Sysinternals ist die 7-zip.dll für den ContextMenuHandlers in 4 Konstellationen als Shell Extension verbandelt. Vermutlich dürfte somit spätestens die alleinige Verwendung eines Kontextmenüs – in dem 7-zip Einträge integriert sind – dazu führen, dass die DLL als in Gebrauch markiert ist, ohne dass man 7-zip bewusst in der laufenden Sitzung nutzte.
.
Das ändert aber nichts am Grundsatz, dass kein Reboothinweis eingeblendet wird oder dass die 7-zip.dll in manchen Fällen gar nicht aktualisiert wird.
Ah, das Kontextmenü, natürlich. Wie es andere auch schon schrieben, hat der Neustart mit der 26.2.0 die alte dll (in meinem Fall die 26.0.0) gelöscht und die 7-zip.dll.tmp in 7-zip.dll (26.2.0) umbenannt. Aber das von dir im letzten Satz Beschriebene, sollte der Entwickler fürs nächste Update adressieren.
Oder man bleibt bei 26.01, denn dieser eine Fix, den 26.02 beinhaltet, ist nicht lebensnotwendig.
Also nicht ein Fix, sondern mehrere… und oft wenn die Entwickler kurz nach einem Update gleich eins hinter herschieben, dann kannst du davon ausgehen, dass da ein grober Schnitzer drinnen sein kann, oder ein Fehler, der sich bemerkbar macht in der vorherigen Version – denk ich mir
Ist nicht wie bei MS, wo man es dann bis zum nächsten Patchday aussitzt oder es über Jahre ersteinmal unter dem Teppich kehrt, bis sich der nächste beschwert
Ich kann die Probleme nicht bestätigen, aber ich habe den Rechner schon mehrmal neugestartet.
Klar, ein Hinweis über den nötigen Neustart soll auf jeden Fall in der Zukunft hinzukommen, aber für alle die es hier lesen – wo ist das Problem den Rechner einfach neuzustarten und gut ist.
Die DLL wird trotz reboot nicht auf jedem Rechner zuverlässig ersetzt.
.
Die 7-zip.dll hat dann in den Angaben zur Dateiversion und der Produktversion die Werte älterer Versionen stehen.
.
Akuell mit Stand 2026-06-27 ist es:
Dateiversion: 26.2.0.0
Produktversion: 26.02
Ich kann mir aber nicht vorstellen, dass es an 7-zip liegt, aber dass kann man sicherlich rausfinden, ob sich an der Installationsroutine was geändert hat. Wieso ist es früher nicht aufgefallen?
Ich würde eher vermuten, dass es ein Windows Problem ist, verursacht vielleicht durch ein Windows Update.
Oder vielleicht funkt da eine AV Software dazwischen.
Hatte bereits in der Vergangenheit ab und an den 7-zip-Programmordner geöffnet und hier und da im Programmordner bemerkt, dass nach einem darüber installiertem Update immer wieder 7-zip-Programmdateien mit älterem Datum gelistet waren (Spalte: Datum). Welche das waren kann ich nicht mehr sagen, vermutlich aber eine DLL, hatte es aber nie näher betrachtet. Von der Datumsregel ausgeschlossen sind die nicht relevanten Beiwerkdateien, wie License.txt, readme.txt usf.
.
Im change-log steht leider nicht, welche Dateien mit dem Update geändert/ausgetauscht werden. Zum jetzigen Zeitpunkt habe ich es aber ganz genau angesehen und über die Dateieigenschaften einen Abgleich gemacht, ob es Unterschiede im Programmordner zwischen upgedateter Software und einer reinen Neuinstallation gibt. Die geringe Anzahl der Dateien erleichterte es und die Unterschiede waren einfach zu erkennen. Das ältere Datum bei einer Datei war das Hauptkriterium, um es genau anzusehen.
.
Die Eigenschaften-Datei-Klickerei im Explorer zur Versionsinfo ist in der Wiederholung natürlich etwas nervig und geht auch per Powershell, was aber die allgemeine Datumsprüfung im Programmordner nur ergänzt.
.
#### DLL-Versionsinfos per Powershell ####
.
#### 7-zip.dll Abfrage #### (bitte ohne Zeilenumbruch):
$vi = (Get-Item ‚C:\Program Files\7-Zip\7-zip.dll‘).VersionInfo; „Dateiversion: $($vi.FileMajorPart).$($vi.FileMinorPart).$($vi.FileBuildPart).$($vi.FilePrivatePart)“; „Produktversion: $($vi.ProductVersion)“
.
falls die 7z.dll auch mal betroffen sein sollte …
.
#### 7z.dll Abfrage #### (bitte ohne Zeilenumbruch):
$vi = (Get-Item ‚C:\Program Files\7-Zip\7z.dll‘).VersionInfo; „Dateiversion: $($vi.FileMajorPart).$($vi.FileMinorPart).$($vi.FileBuildPart).$($vi.FilePrivatePart)“; „Produktversion: $($vi.ProductVersion)“
.
Notfalls den Pfad zur DLL anpassen.
.
Das Abfrageergebnis liefert ganz schlicht, was man ansonsten mit vielen Klicks in den Dateieigenschaften betrachten könnte, hier als Beispiel der Stand vom Juni 2026:
.
Dateiversion: 26.2.0.0
Produktversion: 26.02
.
### Mein künftig schnellster Weg ###
Wenn nach einem „Update“ und erfolgtem Reboot bei den benannten einheitichen Datumsangaben im Programmordner nicht alle relevanten Dateien das Datum der letzten Update-Installation aufzeigen oder schlimmstenfalls sogar diese tmp-DLL vorhanden bleibt, werde ich künftig prinzipiell die vollständige Deinstallation durchführen, dann rebooten, dann prüfen, ob der Programmordner wirklich leer ist bzw. komplett gelöscht wurde, um dann eine saubere Neuinstallation durchzuführen.
Oder gleich Deinstallation mitsamt reboot, dann Erfolgsprüfen, dann Neuinstallation.
Wenn es künftig erneut zicken sollte, wird es wohl stehts mit der Deinstallation starten.
Wurde das Verhalten gemeldet?
Gibt es schon dazu hier https://sourceforge.net/projects/sevenzip/ einen Ticket oder Bug Report?
Hatte ich zwar am Freitag vor, die Site war aber nicht erreichbar.
Am Samstag habe ich dann gesehen, dass man Meldungen nur mit registrierter Nutzerkennung durchführen kann.
Also nein.
.
Falls jemand schon eine Kennung hat, kann dort gerne melden:
.
# reboot Hinweis fehlt ( somit kommt es zu ungepatchten Zuständen), was sicherlich steuerbar ist, wenn der Reg-Key als Bedingung abgefragt wird.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
PendingFileRenameOperations (wenn dessen Wert Hinweise zum 7-zip enthält)
.
# in seltenen Fällen werden Programmdateien bei einem Update trotzdem nicht upgedatet (da könnte der Installer nach dem reboot sicherlich eine simple Prüfung durchführen, ob die Dateiversionen dem Inhalt des Installers entsprechen und im Fehlerfall ein popup oder sowas in der Art bringen)
.
Es werden nur englische Requests akzeptiert.
Danke für den Hinweis. War hier ebenfalls. Ich habe 7zip deinstalliert und dann ein unlocking-Tool für die alte 7-zip.dll verwendet. Danach die 7-zip.dll und die 7-zip.dll.tmp gelöscht. Abschließend 7-Zip 26.02 neu installiert, funktioniert – ohne Neustart.
„Kompatible Plugins“ (wie das 7-Zip Plugin via 7-zip.dll)
Nutze noch Everything zur Suche oder den Process Explorer
für Aktualisierung von automatisierten Skripten, Backup-Prozessen und Integrationen.
Dekomprimierungs- oder Archivierungs-Skripte
Hat mit 7-Zip was zu tun? 🤔
Ich hatte heute morgen einen Austausch mit zwei Bekannten zu diesem Thema hier.
Beide hatten, wie ich auch, auf die neueste Version aufgesetzt.
Beide hatten nach dem Update diese temporäre Datei im Verzeichnis und demzufolge weiterhin die veraltete Dateiversion der 7z.dll.
Beide verwendeten für das Update das Dateiformat .msi, ich verwendete für das Update, wie immer, das Dateiformat .exe. Bei mit lief alles normal und ohne Auffälligkeit, auch ohne Neustart des Systems.
Für mich heißt das, dass man für die Installation von 7-zip entweder die .exe-Version des Programms, oder die portable Version verwenden sollte.
Nur mal so als Gedanke, ohne 100% zu wissen, ob das wirklich die Lösung für andere betroffene Benutzer ist.
Da ich auch nur die exe als Installer nutze und dennoch Problem hatte, ist dieser Unterschied vermutlich nicht der Hauptgrund. Was, wann, wie sein muss, damit dieses oder jenes passiert ..
.
Die Leute haben die Infos, es ist recht überschaubar und simpel den Ist-Zustand mit dem angesprochenen Datumsstempel im Explorer zu prüfen und eine evtl. erforderliche einfach umzusetzende Korrektur ist in meist weniger als fünf Minuten erledigt. Zumindest bis zum nächsten Update.
.
Wer mag, der kann ja die Tickets bei 7-zip erstellen.
Na denn, dann ist meine Vermutung wohl nicht die Lösung des Problems. Hätte ja sein können.
Die Prüfung über PowerShell ist sicher für Erfahrene recht sinnvoll, jedoch nicht für die meisten Benutzer.
Viele Benutzer sind nämlich per System-Default gar nicht berechtigt, eine derartige Überprüfung über PowerShell durchzuführen.
Die Einstellung der EP steht bei den meisten Benutzern auf „restricted“. Diese Fessel muss man erst lösen.
Darauf sollte man eigentlich immer hinweisen, wenn man Tipps im Zusammenhang mit PS gibt.
Ihr entdeckt Verhalten, das vollkommen normal ist weit ein Jahrzehnt „neu“. War ein Fehler Nutzern zu suggerieren der Neustart nach Installationen wäre überflüssig. Nur weil ein paar Ausnahmen das nicht brauchen. Bei einem Treiber ist es noch heute erforderlich. Natürlich auch bei Shell-Extensions.
m(
Nö, auch bei Treibern ist ein Neustart des OS nicht nötig.
Ich habe es schon bei diversen Treibern gesehen, das das Update ohne Neustart lief.
Das lief immer nach dem Schema Treiber deaktivieren, Dateien ausgetauschen/patchen, Reg-Einträge angepassen, Treiber wieder aktivieren ab.
Und was 7-Zip angeht:
In Windows steckt das auch drin, beispielsweise beim Defender.
Und da ist der Stand bei einem voll gepatchten Windows 10/11 immer noch bei der uralten 25.01 vom August 2025!
Wie man es richtig macht, sieht man z.B. bei Winmerge.
Da hat die 7z.dll die Version 26.01, ein Update von Winmerge wird bald kommen mit der aktuellen 26.02.
winget upgrade 7zip.7zip
Es wurden keine Aktualisierungen gefunden.
Aus den konfigurierten Quellen sind keine neueren Versionen des Pakets verfügbar.
¿¿??
winget list
7-Zip 26.01 (x64) 7zip.7zip 26.01 winget