Windows 2022 Server, mit Delphi erstelltes exe hat Fehler

[himitsu]

Entweder es startet einfach nicht oder ist ohne Fehlermeldung plötzlich weg,

aber sonst gibt es doch eine Fehlermeldung, welcher immernoch nicht genannt wurde.


Bei Ersterem schaut man im Windows in Ereignisanzeige > Windows-Protokolle > Anwendung > nach seinem Programm, sowie nach Meldungen vom WER (Windows-Error-Reporting) oder Virenscanner usw.

Zitat von AndreasAutopoll:

* Auf einem relativ Blanken Windows

https://www.delphipraxis.net/207151-...s-sandbox.html

Und dann gibt es noch Dinge, wie z.B. das Remote-Debugging.

[AndreasAutopoll]

Zitat von himitsu:

aber sonst gibt es doch eine Fehlermeldung, welcher immernoch nicht genannt wurde.

Wenn Du meinst das es der Wahrheitsfindung dient, vgl Anhang.

Und ja mir ist klar
Er kann das zum IBData zugehörige DFM nicht laden. Er zeigt aber die Klasse nicht.
Auf dem DFM sind FireDac Komponenten, die fbclient.dll findet er aber ansonsten auf der fehlerhaften Maschine und auf anderen Maschinen geht das exe

Hier noch das .dfm

Delphi-Quellcode:

object DMMain: TDMMain
  Height = 201
  Width = 383
  object FDFIBConn: TFDConnection
    ConnectionName = 'ACONNECTION'
    Params.Strings = (
      'DriverID=FB'
      'User_Name=user'
      'Password=password'
      'Database='
      'SQLDialect=1'
      'CharacterSet=ISO8859_1'
      'CharLenMode=Chars'
      'Protocol=Local'
      'ExtendedMetadata=False'
      'OpenMode=Open')
    UpdateOptions.AssignedValues = [uvCheckRequired]
    UpdateOptions.CheckRequired = False
    Transaction = FDTransaction
    AfterDisconnect = DMDatabaseAfterDisconnect
    Left = 120
    Top = 24
  end
  object FDTransaction: TFDTransaction
    Options.Isolation = xiReadCommitted
    Connection = FDFIBConn
    AfterStartTransaction = FDTransactionAfterStartTransaction
    AfterCommit = FDTransactionAfterCommit
    AfterRollback = FDTransactionAfterRollback
    Left = 208
    Top = 24
  end
  object FDFIBLocalProc: TFDStoredProc
    Connection = FDFIBConn
    Transaction = FDTransaction
    Left = 176
    Top = 80
  end
  object FDLocalQuery: TFDQuery
    Connection = FDFIBConn
    Transaction = FDTransaction
    FormatOptions.AssignedValues = [fvStrsTrim]
    Left = 104
    Top = 128
  end
  object FBDriverLink: TFDPhysFBDriverLink
    DriverID = 'FB259'
    VendorLib = 'fbclient.dll'
    Embedded = True
    Left = 40
    Top = 24
  end
  object IBSecureService: TFDIBSecurity
    DriverLink = FBDriverLink
    Left = 304
    Top = 24
  end
end

Cheers

[AndreasAutopoll]

Ergänzung.

Ich habe den FBSecureService rausgenommen, und bekommen ein anderes Fehlerbild.

Ich habe immer mehr den Eindruch es ist ein Zugriff auf ein uninitilisierte Variabel, die nur in dem Kontext wird. Mal sehen. Die Ereignismeldung ist

Name der fehlerhaften Anwendung: apv4.exe, Version: 4.6.8.441, Zeitstempel: 0x66dac417
Name des fehlerhaften Moduls: apv4.exe, Version: 4.6.8.441, Zeitstempel: 0x66dac417
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00e130cd
ID des fehlerhaften Prozesses: 0xdf4
Startzeit der fehlerhaften Anwendung: 0x01db003b88334b55
Pfad der fehlerhaften Anwendung: E:\Autopoll_V45_441\apv4.exe
Pfad des fehlerhaften Moduls: E:\Autopoll_V45_441\apv4.exe
Berichtskennung: f0554075-8869-4f2f-91b0-2e2833acb708
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Falls das jemanden was sagt.

[Delphi.Narium]

In Delphi 7 würd' ich mal das Programm im Debugger starten, einen Breakpoint irgendwo am Anfang setzen und dann über Suchen / Laufzeitfehler suchen... nach der Fehleradresse forschen. Eventuell kommst Du damit ja in die Nähe des tatsächlichen Problemes.

Oder die Exe mit MAP-Datei erstellen und in der dann nach der Fehleradresse suchen. Da kann man dann ggfls. auch erkennen, in welchem Bereich des Programmes der Fehler auftritt und dort dann gezielt weitersuchen.

Wie's genau in Deinem Delphi geht, weiß ich nicht.

[AndreasAutopoll]

Zitat von Delphi.Narium:

nach der Fehleradresse suchen

Ich kenne die Programmzeile / stelle in der es scheppert.

Aber warum es auf dem einen PC scheppert und auf dem anderen nicht, das erschließt sich mir leider gar nicht.

[Kas Ob.]

I think can't find component is misleading error message and simply hide the real error.

I suggest to build a new and an empty project and start to add these component (you listed in DFM) one by one, BUT do the following:
1) try add them at design time, might be caught the culprit.
2) Create them at runtime and get the real exception, the one that TReader had eat.

In case that fail too, or may be as different approach, use DDetours https://github.com/MahdiSafsafi/DDetours on that offending TReader.FindComponentClass and capture the missing/failed class to register at runtime, because this is what is happening, some class/component should have registered itself at runtime in initialize clause (in a unit) but failed and didn't register, this left the DFM reader/builder/creator in the dark.

[Kas Ob.]

After thinking, may be the shortest way to to hook RegisterClass and log into a file, by comparing the result between 2 OSs you will find the failed one.

[AndreasAutopoll]

Zitat von Kas Ob.:

After thinking, may be the shortest way to to hook RegisterClass and log into a file, by comparing the result between 2 OSs you will find the failed one.

Goot idea, thanks. We will see.....