.exe Dateien kleiner / UPX-Windows-7 Problem / ntdll.dll

[berens]

Hallo mal wieder.

Nachdem ich eben stundenlang nach meinem Programmier"fehler" gesucht habe, weshalb meine Software nicht unter Windows 7 läuft, und geflucht habe, warum nur die Dateien aus dem fertigen Installer nicht laufen, aber die frisch kompilierten Dateien, bin ich dahinter gekommen, dass das Packprogramm UPX (um meine .exe Dateien kleiner zu machen) folgende Fehlermeldung produziert:

Zitat:

---------------------------
MeinProgramm
---------------------------
Zugriffsverletzung bei Adresse 77028C39 in Modul 'ntdll.dll'. Schreiben von Adresse 00000014.
---------------------------
OK
---------------------------

Ich verwende UPX 3.04w und komprimiere alle Dateien jeweils mit dem Befehl "upx.exe Project1.exe --force".
--force deshalb, weil es ab und zu Meldungen gab/gibt, dass es nicht komprimieren kann.
Steht vll. in Zusammenhang mit der Meldung oben, aber nicht unbedingt.

Die Systeme mit der Fehlermeldung haben beide Windows 7 Home Premium, einer 32 Bit und der andere 64 Bit. Auf Windows XP laufen die .exe Dateien problemlos.


Problem bekannt? Gibt es Abhilfen? Alternativen um die .exe Dateien (~2,5 MB) kleiner zu machen?

Lg Mathias

[himitsu]

Die Frage ist, warum man überhaupt unbedingt UPX und Co. verwenden muß, wo es doch viele Nachteile gibt (vorallem vom Speichermanagemente her) und, wie hier, sogar Fehler verursacht.

Zitat:

Zitat von berens

Alternativen um die .exe Dateien (~2,5 MB) kleiner zu machen?

kleiner/optimaler programmieren?

[Bernhard Geyer]

Da wird vermutlich der entpacker-Algorithmus noch noch nicht Win7 kompatible sein. Die Adresse deutet jedenfalls darauf das irgendwas nicht korrekt initialisiert wurde.

[berens]

Naja, leider kommt unser Programmpaket mit ~ 10 .exe Dateien daher. Uns schon alleine von der Last des FTP-Servers lohnt es sich, die Dateien zu komprimieren (> 60% Traffic Einsparung).

Mir war allerdings nicht bewusst, dass UPX so viele Probleme verursacht. Muss ich mal die SuFu nutzen.

Um die .exe kleiner zu bekommen, werde ich mal andere Threads durchsuchen, eine kleine Zusammenfassung hier wäre aber auch ganz nett ;)

Ich denke, ich schaffe die UPX-Komprimierung (erstmal) ab, damit ich auf der sicheren Seite bin.

Danke soweit.


Edit:

Zitat:

kleiner/optimaler programmieren?

Klar, sofern möglich ;) Leider brauchen die ganzen LMD und TMS Tools / units schon viel Platz in den .exe Dateien.

[BUG]

Zitat:

Zitat von berens

Uns schon alleine von der Last des FTP-Servers lohnt es sich, die Dateien zu komprimieren (> 60% Traffix Einsparung).

Du könntest die Dateien auch einfach zippen, das würde Traffic sparen und dir UPX ersparen.

MFG,
Bug

[OldGrumpy]

Wenn die Dateien sowieso in einer Installation stecken, lohnt es sich vermutlich eher, einen Installer mit ordentlicher Kompression zu verwenden. Was den FTP-Traffic angeht, kann man zusätzlich einen kleinen Webupdater entwickeln der FTP mit Kompression beherrscht und nur Delta-Downloads macht. Dann braucht nicht jeder User das grosse Installationsarchiv herunterladen sondern nur die Teile die für ihn relevant sind.

//Edit: Genau wegen solcher Probleme gibts diesen Check in UPX der manchmal das Komprimieren einer Exe verweigert. Und wer die Warnung ignoriert, muss halt mit den Folgen leben :mrgreen:

[berens]

Habe lustigerweise selbiges festgestellt. Unser Installer wird standardmäßig über NSIS komprimiert, und dann nochmal gezippt. Somit ist der Download selbst nicht größer geworden ^^.

Interessanterweise bekomme ich diese Fehlermeldung aber immernoch, wenn ich das Programm direkt im Anschluß an (aber durch) den NSIS Installer starten lasse ("Project1.exe nach beendigung der Installation starten"), auch wenn Project1.exe nicht komprimiert ist...

Bei nachfolgenden Starts ist die Meldung nicht zu sehen. Wenn ich den Installer nicht das Programm starten lasse, ist die Meldung ebenfalls nicht zu sehen. Schon merkwürdig.

[Assertor]

Hi,

UPX gepackte Programme funktionieren Einwandfrei unter Win 7 (x32 und x64). Eine Anpassung für die Entpackroutine ist nicht erforderlich (warum sollte es auch, das PE Format von < Win7 ist ja in jedem Fall mit Win7 Kompatibel).

Die Diskussion der Notwendigkeit hat auch nichts mit dem Problem zu tun: Entwickler (@berens), der Fehler liegt bei Dir. Insbesondere das Force sollte nie notwendig sein, wenn Du es schon anwendest mußt Du eben selbst dafür sorgen, dass alle unkomprimierbaren Resourcen dies trotz Komprimierung überstehen. Ich keine keinen einzigen Fall wo Force notwendig ist - und setzte UPX seit vielen vielen Jahren ein.

Und die ganzen Argumente gegen UPX sind technisch sowieso seit vielen vielen Jahren hinfällig. Es gibt immer gute Gründe für und gegen den Einsatz jedes Tools. Frage: Einsatzgebiet (z.b. hier portable Medien).

Ergo: Kein Force bei UPX

Roter Kasten: Falls es auch so kracht, liegt es an Deinem Code.

Gruß Assertor

[berens]

Naja... wie kann ich denn rausfinden weshalb UPX sich weigert, die .exe zu komprimieren?

Sau merkwürdig: Wenn ich den Installer im Windows XP SP 2 Kompatibilitätsmodus laufen lasse, gibt es keine Fehlermeldung. Es scheint also zu sein, dass der Installer meine .exe mit niedrigeren Rechten aufruft, als das Startmenü oder der Doppelklick auf die .exe (wenn der Kompatib. Modus nicht benutzt wird).

[Assertor]

Hi,

Zitat:

Zitat von berens

Naja... wie kann ich denn rausfinden weshalb UPX sich weigert, die .exe zu komprimieren?

Das erhälst Du als Textausgabe des Kompressors. Falls die Details nicht reichen, upx mit Parameter -v aufrufen (also upx -v exename.exe).

Diese Meldung dann hier posten als Anhang (Screenshot).

Gruß Assertor

[berens]

Also ich habe jetzt auch versucht mich über RemoteDebugger zu verbinden. Problem: Die (zwei) Fehlermeldungen nach dem Aufruf durch den NSIS Installer kommen vor der ersten Gelegenheit, mich mit dem Prozess zu verbinden:

Delphi-Quellcode:

program Project1;

uses
  ExceptionLog,
  Forms,
  uProject1_Main in 'uProject1_Main.pas' {frmMain},
  uProject1_Events in 'uProject1_Events.pas',
  uProject1_EventCopy in 'uProject1_EventCopy.pas' {frmEventCopy},
  uProject1_frmMemo,
  uProject1_LivePreview2 in 'uProject1_LivePreview2.pas' {frmLivePreview},
  uProject1_frmSort in 'uProject1_frmSort.pas' {frmSort},
  uProject1_frmWarning in 'uProject1_frmWarning.pas' {frmWarning},
  dialogs
  ;

{$R *.res}

begin
  showmessage('Jetzt Debugger verbinden!');

  Application.Initialize;

  Application.CreateForm(TfrmMain, frmMain);
  Application.CreateForm(TfrmEventCopy, frmEventCopy);
  Application.CreateForm(TfrmMemo, frmMemo);
  Application.CreateForm(TfrmLivePreview, frmLivePreview);
  Application.CreateForm(TfrmSort, frmSort);
  Application.CreateForm(TfrmWarning, frmWarning);

  Application.Run;
end.

Da alle .OnCreate Ereignisse etc. und initialization erst nach der ShowMessage kommen, dürfte der Fehler ansich nicht bei mir liegen, oder? Die Fehlermeldung kommt schließlich vor ShowMessage.

[Assertor]

Zitat:

Zitat von berens

Da alle .OnCreate Ereignisse etc. und initialization erst nach der ShowMessage kommen, dürfte der Fehler ansich nicht bei mir liegen, oder? Die Fehlermeldung kommt schließlich vor ShowMessage.

Kann trotzdem sein: Vor der VCL App.Initialize werden alle Initializations der Units durchlaufen. Wenn dort irgendwo etwas falsch ist knallt es vor dem ShowMessage.

Gruß Assertor

[Bernhard Geyer]

Hast du eine COM/Automatisierung-Schnittstelle die registriert werden muss?
Was passiert wenn du die Anwendung mit Adminrechten (Klick auf Exe -> Aufruf Kontextmenu) startest?

[GPRSNerd]

Ich komprimiere meine Executables ebenfalls mit UPX 3.04w (aber ohne jegliche weitere Parameter) und hier laufen alle Programme unter Win7 32bit/64bit einwandfrei.

[berens]

> Hast du eine COM/Automatisierung-Schnittstelle die registriert werden muss?
Ja, ich brauche unter anderem MSXML, welches z.B. CoInitialize(NIL) benötigt.

> Was passiert wenn du die Anwendung mit Adminrechten (Klick auf Exe -> Aufruf Kontextmenu) startest?
1) Ich bin Admin, weiss aber nicht, wie das Programm (mit welchen Rechten) gestartet wird, wenn ich die .exe Datei doppelklicke.
2) Mit einem Doppelklick auf die .exe klappt alles und es kommt keine Fehlermeldung.
3) Installer im Kompatibilitätsmodus laufen lassen bring auch _keine_ Fehlermeldung, wenn anschließend meine .exe gestartet wird.
4) Ohne Kompatibilitätsmodus kommt die Fehlermeldung, wenn der Installer meine .exe (ohne Adminrechte) startet. Ich wüsste jetzt nicht auf die Schnelle, wie ich NSIS beibringe, die nachfolgende .exe mit Admin-Rechten zu starten.

[OldGrumpy]

Zitat:

Zitat von berens

Interessanterweise bekomme ich diese Fehlermeldung aber immernoch, wenn ich das Programm direkt im Anschluß an (aber durch) den NSIS Installer starten lasse ("Project1.exe nach beendigung der Installation starten"), auch wenn Project1.exe nicht komprimiert ist...

Das könnte mit den Rechten zusammenhängen. Wenn das Programm vom Installer gestartet wird, bekommt es je nach Installer die Rechte des Installprozesses oder halt nur eingeschränkte Rechte. Wenn das Programm auf die Rechte gemäß seinem Manifest angewiesen ist, kann es hier zum Problem kommen. Das lässt sich nur langwierig debuggen, empirisch testen ist vermutlich schneller :)

[Bernhard Geyer]

Zitat:

Zitat von berens

Ich bin Admin, weiss aber nicht, wie das Programm (mit welchen Rechten) gestartet wird, wenn ich die .exe Datei doppelklicke.

Bei aktiver UAC - ohne Adminrechte.
Deshalb ja der Test.

[berens]

UAC ist bei mir standardmäßig aus. Eben mal mit UAC auf Standardeinstellungen getestet, selbes Problem.

Das mit "rechte Maustaste" - "als Admin ausführen" kann ich ja nicht machen, da die Fehlermeldung _nur_ auftritt, wenn die .exe vom NSIS Installer selbst gestartet wird.

Wenn ich den Installer als Admin ausführe, ändert das nichts, Fehlermeldung bleibt.

[generic]

Zitat:

Zitat von berens

Interessanterweise bekomme ich diese Fehlermeldung aber immernoch, wenn ich das Programm direkt im Anschluß an (aber durch) den NSIS Installer starten lasse ("Project1.exe nach beendigung der Installation starten"), auch wenn Project1.exe nicht komprimiert ist....

Klingt für mich als ob du Probleme mit dem UAC hast.

Edit:
Huch, der Beitrag war wohl länger auf.
Ihr habt es ja schon, also vergesst das hier mal.

[berens]

Selbst wenn ich Probleme mit der UAC habe... Wie bekomme ich das raus, bzw. wie finde ich den Fehler in meinem Delphi-Programm? Ich kann das Problem ja nicht nachvollziehen (weder als normaler Benutzer, noch als Admin). Es tritt ja nur auf, wenn durch NSIS aufgerufen.

[Progman]

Kleine Anmerkung:
Die erste Zeile im NSIS-Script sollte "RequestExecutionLevel admin" sein.
Jedenfalls hat das unter Vista Wirkung und unter Win7 stört es zumindest nicht. Unsere Installationen funktionieren jedenfalls bisher.

[berens]

Wie befürchtet löst "RequestExecutionLevel admin" zwar das Problem (Fehlermeldung ist weg, Danke Progman!), aber nicht die Ursache.

Irgendeine Idee wie ich das Problem "reproduzierbar" machen kann, so dass es auch auftritt, wenn ich es mit eingeschalteter UAC als normaler Benutzer ohne Adminrechte ausführe?

[OldGrumpy]

Mit einem Tool wie madExcept kannst Du Dir zumindest den Callstack sichern und das ganze eingrenzen. Wenn das noch nicht hilft, kannst Du mittels der Win32-API OutputDebugString in den einzelnen Initialization-Abschnitten zumindest abklären was noch initialisiert wird bevor es rummst.

[berens]

Ich verwende bereits Eurekalog, aber das konnte mir bei diesem Problem leider auch nicht helfen :(

[himitsu]

Wenn das mit dem Debuggen daran hapert, daß es schneller knallt, als du verbinden kannst,
dann bau dir 'ne Verzögerung ein, damit du die Zeit bekommst.

erstell dir eine Unit, schreib da z.B. ein Sleep rein und füge diese Unit als aller Erste in die Usesliste des Projektes (.DPR) ein.

[generic]

Welches Manifest tust du an dein Programm dran?

[OldGrumpy]

Mich hätte mal interessiert, ob es da nun eine "richtige" Lösung gegeben hat :) *push*

[berens]

Sry, komplett vergessen gehabt noch ne Antwort zu schreiben, weil ich die letzten Tage viel unterwegs war.

Als Manifest verändere ich nichts, was mir Delphi 2007 mitliefert. Ist halt die Frage, ob ich da noch konkret was ändern muss (auf Dauer).

Zitat:

Wenn das mit dem Debuggen daran hapert, daß es schneller knallt, als du verbinden kannst,
dann bau dir 'ne Verzögerung ein, damit du die Zeit bekommst.

erstell dir eine Unit, schreib da z.B. ein Sleep rein und füge diese Unit als aller Erste in die Usesliste des Projektes (.DPR) ein.

Muss ich demnächst mal ausprobieren, leider aktuell kein Windows 7 PC zu testen da.

Das Problem ist nun vorläufig so "gelöst", dass ich im NSIS Script tatsächlich "RequestExecutionLevel admin" verwende (Danke Progman), seitdem funktioniert es.

Mir ist schon klar, dass das Problem irgendwie mit Benutzerrechten und der UAC zusammenhängt, leider konnte ich aber noch nicht herausfinden, woran genau, da sich das Problem ja wie gesagt nicht nachvollziehen lässt außer direkt im Anschluss an den Installer. Auch Ausführung als Gast-Benutzer macht keine Probleme.

[berens]

Auch wenn dieses Thema ein wenig abgedriftet ist, da der Fehler nicht eindeutig benennbar ist, führe ich es mal mit aktuellen Informationen fort:

Mittlerweile tritt diese ntdll.dll Fehler auch ohne die UPX-Komprimierung unter Windows 7 auf. Ich habe jetzt einen Laptop mit Windows 7 Pro und habe dort mein Delphi mit allem drum und dran zum Laufen bekommen. Jetzt wird es interessant:

Wenn ich das Projekt ganz normal mit F9 starte, klappt zunächst alles. Wenn ich nun eine beliebige Änderung am Quelltext vornehme (z.B. x := 0; y := 0; ersetzen durch y := 0; x := 0) dann kommt bei allen nachfolgenden Starts mit F9 (oder auch ohne Debugger direkt mit der .exe) die o.g. Fehlermeldung mit der .dll Datei.

Wenn ich nun ein Leerzeichen einfüge (als den Quelltext geringfügig verändere) und dann wieder mit F9 starte, kommt die Fehlermeldung nicht mehr. Wunder der Technik. Zumindest bis zur nächsten Änderung, wo mehr als ein Leerzeichen geändert wird; dann kommt beim Programmstart wieder die Fehlermeldung.

Kurz zusammengefasst: Die Fehlermeldung mit der ntdll.dll erscheint, wenn das Projekt (manche/alle Units) komplett neu compiliert wurde. Solange, bis es danach nochmal kompiliert wird.

Das ergibt für mich keinen Sinn.

Ich habe bei _allen_ Units, die mein Programm verwendet (oder verwenden könnte) in der ersten Zeile nach "initialization" (sofern vorhanden) einen Haltepunkt gesetzt, falls dieser Abschnitt eine Exception verursacht. Da initialization immer vor der ersten Zeile des Projekts ausgeführt wird (Application.Initialize; <-- hat auch einen Haltepunkt von mir bekommen), könnten ja auch die eingebundenen Units das Problem sein. Sind Sie aber scheinbar nicht, denn die Fehlermeldung kommt immernoch _bevor_ die erste Zeile von initialization bei irgendeiner Unit aufgerufen wird.

Könnte Windows 7 selbst das Problem verursachen?
Hm, ich habe 2 (eigene) DLL-Dateien in meinem Programm eingebunden wie z.B.

Delphi-Quellcode:

function File_IsAccessDB(FileName: string): Boolean; external 'datenbank.dll';

Prüft die .exe beim Programmstart vor initialization vielleicht, ob die angegebenen .dll Dateien vorhanden sind und die Funktionen/Prozeduren exportieren, die ich verwende?

Oder: Wenn die .exe erstellt ist, kann es sein, dass sie vom Virenscanner, Windows IndexDienst oder einem anderen Programm so gesperrt wird, dass die nicht korrekt ausgeführt werden kann? (Auch mit deaktiviertem AntiVir klappt es nicht.)

Zum Thema Manifest: Ich habe wir in http://www.delphipraxis.net/internal...nifest+windows und http://www.delphi-treff.de/tutorials/vcl/vista/ beschrieben "Laufzeit-Themes" aktiviert. D.h. angeblich ist in meine .exe automatisch ein Manifest für Vista / Windows 7 enthalten. Stimmt das, oder brauche ich noch extra Modifikationen.

Wie bekomme ich meine .exe dazu, unter Win7 immer als Administrator zu starten (Bitte die Fragen, wie "sinnvoll" dies ist, zurückstellen. Danke.) Ich werde dazu gleich mal die SuFu anwerfen, falls wer spontan nen Tip hat, bitte sagen ;)

[Sherlock]

Zitat:

Zitat von berens

Wie bekomme ich meine .exe dazu, unter Win7 immer als Administrator zu starten (Bitte die Fragen, wie "sinnvoll" dies ist, zurückstellen. Danke.) Ich werde dazu gleich mal die SuFu anwerfen, falls wer spontan nen Tip hat, bitte sagen ;)

Ins Manifest schreiben, daß sie mit Adminrechten gestartet werden soll.

Sherlock

[hoika]

Hallo,

Zitat:

Prüft die .exe beim Programmstart vor initialization vielleicht, ob die angegebenen .dll Dateien vorhanden sind und die Funktionen/Prozeduren exportieren, die ich verwende?

Nein, die Exe nicht, aber Windows selbst !
Beim Start der Exe werden auch die beiden DLL's geladen
und deren Methoden-Adressen an die Ladeadressen "angepaßt".

Es sein, dass beim Start der Exe über den Installer das Install-Verzeichnis
also Anwendungs-Verzeichnis genommen wird.
Dann findet Windows beim Start deiner Exe natürlich die Dlls nicht.

Ich würde mal folgendes machen
c:\temp anlegen
Install nach c:\temp\

Und auch nach c:\temp installieren !


Heiko

[Assertor]

Hi,

sag mal berens, verwendest Du EurekaLog? Sieh laut einem Deiner obigen Posts so aus (Unit ExceptionLog).

Fall ja, dann ist es das:
http://news.eurekalog.com/showthread.php?t=2622

Wird im nächsten RC von EurekaLog wohl gefixt.

Gruß,
Assertor

[berens]

Ich hatte tatsächlich EurekaLog installiert. Dieses habe ich nun komplett deinstalliert und aus allen Projekten die Verweise darauf entfernt. Danach neu kompiliert: Fehler immernoch da.

Ich habe nun mit Himatsu's Manifest-Create ein Manifest erstellt, es als Resource im selben Ordner wie das Projekt kompiliert und dann in die Projekt-Quelltext Unit eingefügt {$R w7.res}. Leider keine Besserung. Weitere Vorschläge?

Das Manifest. Zu Testzwecken mit Administrator Rechten.

Delphi-Quellcode:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
    version="0.0.0.0"
    processorArchitecture="X86"
    name="welcome-soft"
    type="Win32"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="true"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
    </application>
  </compatibility>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        publicKeyToken="6595b64144ccf1df"
        language="*"
        processorArchitecture="*"/>
    </dependentAssembly>
  </dependency>
</assembly>

Das Manifest schein nicht korrekt zu funktionieren.

Wenn ich die identische .exe (mit Fehlermeldung) nach dieser Anleitung: http://www.virtual-cbfunk.de/Win7.htm starte (im Klatsch&Tratsch Forum verpöhnt; jetzt bitte keine Diskussionen um den Programmierstiel etc), funktioniert das Programm tadellos ohne eine einzige Fehlermeldung.

Was mache ich falsch?

Bzw.: Kann ich über ShowMessage oder so ausgeben, mit welchen Rechten das Programm jetzt tatsächlich gestartet wurde? Im Taskmanager steht die .exe immer mit dem aktuellen Benutzername drinnen.

Edit: Den Post von Hoika eben erst gesehen.
Hoika: Das "aktuelle" Problem dreht sich ja drum, dass der Fehler sogar bei Compilieren&Starten durch Delphi auftritt. Wenn ich das Programm über rechte Maustaste "als Admin starten" ausführe, kommt die Fehlermeldung nicht. Also ist das denke ich kein Problem mit den Pfaden. (Regulär bin ich im Moment auch Admin, btw.)

Kann es sein, dass die beiden .dll's auch die .res Datei mit dem Manifest brauchen?

Edit: Es scheint so als würde es nun funktionieren, nun, da die .dll Dateien auch das Manifest eingebunden haben. Da das Problem generell ja eher zufällig autritt, kann ich es aber noch nicht abschließend sagen.

Wenn das Problem gelöst ist, ist nun die Frage: Funktioniert es, weil das Manifest auch in den dlls eingebunden ist (generell) oder weil das Manifest den dlls (im Moment) Admin rechte gibt.

Auf Deutsch: War es nun ein Kompatibilitäts- oder ein Zugriffsrechteproblem?

Ich muss es demnächst nochmal mit einem Manifest mit normalen Benuterrechten testen. Bin mal gespannt.