Anwendung stützt ab wenn DELPHI deinstalliert wird

[bernhard_LA]

Hallo,

unserer Anwendung startet nicht mehr, stattdessen bekommen wir eine AV.
Solange Delphi auf dem System installiert war hatten wir keine Probleme .

Welche DLL könnte es sein die jetzt der Anwendung fehlt ???

[jaenicke]

Ohne weitere Informationen zu der Anwendung kann man da nur raten.

Herausfinden können solltest du das recht einfach mit dem Process Monitor.

[himitsu]

Ihr habt aber nicht mit Laufzeitpackages kompiliert?

[bernhard_LA]

welcher Process Monitor ?


unsere Anwendung ist x64 und hier habe ich kein Madshi oder vergleichbar , Compiler ist eh nicht mehr installiert

[himitsu]

Der von SysInternals.

[bernhard_LA]

Oje :-( angeblich bekomme ich einen FSCTL_LMR_QUERY_DEBUG_INFO Fehler bevor meine Anwendung loslegt , warum ??


Tante google und FSCTL_LMR_QUERY_DEBUG_INFO erlaubt mir keine Rückschlüsse auf meinen code

[Assarbad]

Zitat:

Zitat von bernhard_LA (Beitrag 1163209)

Oje :-( angeblich bekomme ich einen FSCTL_LMR_QUERY_DEBUG_INFO Fehler bevor meine Anwendung loslegt , warum ??


Tante google und FSCTL_LMR_QUERY_DEBUG_INFO erlaubt mir keine Rückschlüsse auf meinen code

Das ist vermutlich überhaupt nicht relevant. Nur weil dort Failure steht, bedeutet dies nicht, daß das eine Auswirkung hat. Wenn ein Programm versucht eine nicht existierende Datei zu öffnen, gibt das auch nen Fehler, aber wenn die Datei danach angelegt wird - nämlich von der Anwendung selber - hat es auch keine Auswirkung mehr.

Ich denke eure Anwendung ist gegen die falsche Laufzeit gelinkt bzw. ihr gebt die nicht mit gegen die ihr linkt. Weiß nicht wie das bei Delphi derzeit lizenztechnisch ist.

Übrigens: http://live.sysinternals.com ...

[jaenicke]

Das kommt aus der explorer.exe, hat also erst einmal nix mit deiner Anwendung zu tun. Als erstes setze einmal den Filter auf Process Name = Deine Exe. ;-)

Dann schaue nach Einträgen wie Debug oder Dr Watson, von unten startend. Irgendwann landest du dann bei den Daten, die vor dem Crash passieren. Ich sage nicht, dass diese Analyse einfach ist. Aber in der Regel wirksam. ;-)

[bernhard_LA]

habe mit dem process monitor jetzt auf "Mytestapp" gefiltert.
die Borland memory manger dll habe ich immer in den System Pfad kopiert und mit der Anwendung verteilt, benötigt x64 eine spezielle Borland DLL ?

[Assarbad]

Code:

//
// MessageId: STATUS_INVALID_IMAGE_FORMAT
//
// MessageText:
//
// {Bad Image}
// %hs is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.
//
#define STATUS_INVALID_IMAGE_FORMAT      ((NTSTATUS)0xC000007BL)

The clue is in the name :zwinker:

Der Loader spuckt immer native Fehlercodes aus.

Übrigens hat Sebastian vollkommen recht. Ich benutze den Process Monitor auch sehr gern für derlei Dinge. Dort sollte sich auch besagter Fehlercode finden lassen.

@shmia: jupp, ist auch in meiner Tool-Schatzkiste :mrgreen: ... allerdings benutze ich den dynamischen Modus im Prinzip nie. Bei StackOverflow hättest du jetzt ein Upvote bekommen ;)

[shmia]

Bei Problemen mit fehlenden DLLs hilft der Dependency Walker.
Schon beim Laden einer EXE oder DLL sieht man welche DLL angefordert wird, aber nicht gefunden wird.
Wenn man dann das Profiling mit F7 startet sieht man jedes dyn. Laden einer DLL und jeden Aufruf von GetProcAdress. :thumb:
Fehler werden im Protokoll rot angezeigt.

[jaenicke]

Zitat:

Zitat von bernhard_LA (Beitrag 1163229)

die Borland memory manger dll habe ich immer in den System Pfad kopiert und mit der Anwendung verteilt, benötigt x64 eine spezielle Borland DLL ?

Nein, da gibt es nur eine DLL. Was passiert denn, wenn du die in den Pfad deiner Anwendung legst? Gefunden wird sie ja offenbar nicht, falls das nicht noch später im Log passiert.

[bernhard_LA]

Jonny Walker behauptet ich habe vergessen IESHIMS.DLL einzubinden ....
die stammt nicht von mir sondern vom MSoft,

[Assarbad]

Zitat:

Zitat von bernhard_LA (Beitrag 1163238)

STATUS_INVALID_IMAGE_FORMAT diesen text sehe ich nicht, :?:

Mußt du auch nicht, denn es ist der symbolische Name für den Fehlercode den du (lt. Screenshot) bekommst. Und wie wir alle wissen sind symbolische Namen für uns Menschen da, nicht für den Rechner. Mußt mir auch nicht vertrauen in der Sache, hab ja erst ein paar Jahre Erfahrung, nicht Jahrzehnte (na gut, 1,5) oder Jahrhunderte :mrgreen:

Das ist dein Fehlercode. Und daher weißt du jetzt was es ist. Entweder ist diese Datei selber nicht i.O., oder - was wahrscheinlicher scheint - versucht eine DLL für die falsche Architektur zu laden.

[bernhard_LA]

anbei noch der screen dump von janny walker als beleg !

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1163236)

Nein, da gibt es nur eine DLL.

Wenn die benötigt wird, dann sollte man auch eine 64-Bit-Version davon verwenden.

'ne 32 Bit-DLL in einer 64 Bit-Anwendung läuft nicht unbedingt so gut.

[Assarbad]

Zitat:

Zitat von bernhard_LA (Beitrag 1163249)

anbei noch der screen dump von janny walker als beleg !

Der Screenshot zeigt doch wunderbar, daß borlndmm.dll und fastmm_fulldebugmode.dll 32bittige DLLs sind, während die Anwendung allem Anschein nach 64bit ist. Was wolltest du uns also damit sagen? Der Fehler ist doch somit offensichtlich und der Fehlercode hat gereicht um in diese Richtung zu weisen ...

... ieshims.dll und ieframe.dll sind übrigens, wie die kleine Sanduhr anzeigt, Delay Loaded Imports.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1163255)

'ne 32 Bit-DLL in einer 64 Bit-Anwendung läuft nicht unbedingt so gut.

An eine 64-Bit Anwendung hatte ich nicht gedacht. Aber eigentlich hätte ich das schon daran sehen müssen, dass nach der DLL im System32 Verzeichnis gesucht wurde. :oops:

Ja, dann müssen die DLLs dazu passen, ja.

[Assarbad]

Zitat:

Zitat von jaenicke (Beitrag 1163278)

An eine 64-Bit Anwendung hatte ich nicht gedacht.

Dazu gibt es ja das Hive-Mind (also uns alle zusammen). Mir war das so gut wie klar als ich den Fehlercode in der ntstatus.h nachgeguckt hatte und es STATUS_INVALID_IMAGE_FORMAT war. Den hatte ich früher schon gesehen und der kommt immer mal wieder (es gibt davon auch eine Win32-Variante), aber ich hatte noch nie ein wirklich beschädigtes Image. Mach auch keinen Sinn. Wenn nur Delphi deinstalliert wurde, aber die Anwendung nicht angetastet wird, bleiben nur noch Abhängigkeiten. Da dieser Fehler ganz offensichtlich vom Loader kommt (sonst wäre es kein nativer Fehlercode ala NTSTATUS), muß das auch schon während des Ladens passieren und somit war der Fall relativ klar.

Aber irgendwie scheint mir, bernhard_LA ist nicht sehr offen für unseren Input :lol:

[bernhard_LA]

ich habe eine Installation meiner Software auf meinem Entwicklungssystem (incl. Delphi in einem anderen Ordner) ,
Jonny Walker moniert auch hier das Fast MM4 debug.dll und dir Borland Memory Manger DLL in der falschen CPU version vorhanden sind ... nur läuft meine Anwendung hier ohne Probleme.


Akutell versuche ich jetzt beide dlls als x64 Bit Version neu zu erstellen ( die Projekte gibt es im FASTMM4 Ordner)

[jaenicke]

Brauchst du denn Sharemem? Und FastMM im Full Debug Mode?
Beide sind eigentlich in der Regel in der Releaseversion überflüssig (wenn man nicht Schweinereien mit Stringparametern o.ä. in DLLs macht, dann braucht man Sharemem natürlich, aber dann sollte man eher die Schnittstelle sauber machen...).

[bernhard_LA]

FastDebugModeDLL habe ich in X64 jetzt auch schon entfernt,

sharemem ist halt in vielen DLLS enthalten wegen der String Übergabe ... bin mir nicht sicher ob ich so schnell auf
borland memory manger dll verzichten kann müsste die ganzen includes überarbeiten
suche die schnellste Lösung für mein Problem

[bernhard_LA]

problem gelöst Anwendung spielt :


BorlandDLL aus fastMM4 Versichnis (sourge forge) im x64 Bit Mode erstellt .... dann geht jetzt

[himitsu]

Die Unit SimpleShareMem in alle DPRs der DLLs und EXE an erster Stelle eintragen.
Fertig.


Die neue borlndmm.dll (die mit dem FastMM drin) ist nur ein Kompatibilitätsupgrade für alte Programme, also für den Austausch der borlndmm.dll mit dem alten BorlandMM drin.
Dort werden alle Speicheranfragen immer über diese zusätzliche DLL behandelt.

FastMM kann aber mehr:
Man kann diesem über ShareMemoryManager sagen, daß er sich verteilen/sharen soll.
- also entweder er Findet einen anderen FastMM in einer anderen DLL/EXE und verbindet sich dann dort hin (innerhalb des eigenen Prozessraums)
- oder er ist der Erste und bietet sich anderen FastMMs an

Delphi-Quellcode:

{Searches the current process for a shared memory manager. If no memory has
 been allocated using this memory manager it will switch to using the shared
 memory manager instead. Returns true if another memory manager was found and
 this module is now sharing it.}
function AttemptToUseSharedMemoryManager: Boolean;

{Makes this memory manager available for sharing to other modules in the
 current process. Only one memory manager may be shared per process, so this
 function may fail.}
function ShareMemoryManager: Boolean;

SimpleShareMem braucht keine DLL mehr, da hier der FastMM der ersten statisch geladene DLL verwendet wird.
Oder der FastMM der EXE, wenn alle DLLs dynamisch geladen werden.
Halt immer der er FastMM, welcher für das Sharing aktiviert wurde.