4. Programm startet nicht... (Win7, 64bit - Einzelne Sonderfälle)

Programm startet nicht... (Win7, 64bit - Einzelne Sonderfälle)

  • M

    Verwendet ihr externe VCL Packages oder alles gelinkt? Es hört sich zumindest erstmal nach einem Package Problem an. Eventuell ist auf den betroffenen Systemen ein anderes Programm installiert, das ebenfalls mit BCB/Delphi erstellt ist und hat das System mit *.bpl's vollgemüllt. Dank der neuen Politik, das nach zu ladende DLL's erst im System und dann im Programmverzeichnis gesucht wird, bekommt eurer Programm eventuell falsche Versionen?!
    Ich hatte auch mal ein ähnliches Problem mit ATI Grafiktreibern. Mein Programm hatte Speedbuttons mit BMP's die ATI überhaupt nicht mochte und das Programm ist sang und klanglos abgeschmiert.
    Könnt ihr feststellen, "wie weit" euer Programm kommt, bevor es abstürzt? Noch vor main? dann werden es die Packages sein.

    0
  • A

    matze555 schrieb:

    Verwendet ihr externe VCL Packages oder alles gelinkt?

    Alles gelinkt, es wird keine bpl ausgeliefert.

    matze555 schrieb:

    Könnt ihr feststellen, "wie weit" euer Programm kommt, bevor es abstürzt? Noch vor main? dann werden es die Packages sein.

    Vor dem Eintritt in die WinMain...

    0
  • A

    asc schrieb:

    Hat jemand einen Ansatzpunkt wie man herausfinden kann an was ein solcher Fehler liegt?

    Debug-Build von der C++-RTL erstellen und mit dem Remote-Debugger reinsteppen. Anweisungen dazu in der Readme in $(BDS)\source\cpprtl .

    0
  • D

    Das Problem gatte ich auch nach Umstellen auf Win 7 64bit (Premium Home).

    Auf meinem System! :
    - Kompatibilitäts- Modus hilft absolut nix.
    - Virenscanner sind NICHT deran Schuld

    => Gutes Rad ist teuer...

    Abhilfe: (obwohl das paradox scheint)

    - In alle Projekte (in der WinMain...)

    Am Anfan
    CoInitialize(NULL)

    Am Ende
    CoUninitialize()

    Voila, seitdem klaptt es, zumindest bei mir.

    ACHTUNG: CoUninitialize nur, wenn CoInitialize erfolgreich war!

    Gruss
    Frank

    0
  • A

    DerAltenburger schrieb:

    - In alle Projekte (in der WinMain...)

    Auch wenn ich den Tipp mir merken werde, falls noch andere Probleme auftreten, wird bei uns die WinMain schon nicht mehr aufgerufen...

    0
  • M

    ... also wenn das CoInit geholfen hat, wird eventuell mal wieder irgendwas mit MS schieflaufen. Versuch mal die Common-Controls Version zu erzwingen. Siehe dazu:
    http://www.c-plusplus.net/forum/p2018436#2018436
    Die ganzen gelinkten VCL Klassen haben meistens eigene init Blöcke, die noch vor WinMain aufgerufen werden. Eventuell will da jemand sich ein Windowscontrol holen, das nicht da ist oder es nur in falscher Version bekommt. Mit welcher BCB Version ist das Programm denn erstellt? 5, 6? oder schon Embarcadero?

    0
  • A

    matze555 schrieb:

    Mit welcher BCB Version ist das Programm denn erstellt? 5, 6? oder schon Embarcadero?

    Bei uns 2007 (den Umstieg auf eine neuere Version haben wir bislang wegen einzelnen, älteren Komponenten noch nicht geschafft, die wir noch am Austauschen sind - betrifft bei uns leider jegliche DB-Zugriffe...).

    0
  • A

    asc schrieb:

    Alles gelinkt, es wird keine bpl ausgeliefert.

    Also benutzt ihr auch nicht die dynamische C++-RTL (cc32*mt.dll)? Mit dieser DLL, speziell im Zusammenhang mit CodeGuard, kann sowas bei falscher Konfiguration schon mal passieren.

    Ansonsten kann ich nur meinen Ratschlag bekräftigen und einen Debug-Build der RTL ausprobieren.

    Außerdem ist vielleicht das hier noch hilfreich:
    http://blogs.embarcadero.com/chrishesik/2007/05/24/34829 - C++Builder: Debugging application startup

    0
  • D

    matze555 schrieb:

    ... also wenn das CoInit geholfen hat, wird eventuell mal wieder irgendwas mit MS schieflaufen. Versuch mal die Common-Controls Version zu erzwingen. Siehe dazu:
    http://www.c-plusplus.net/forum/p2018436#2018436

    Mit Manifesten hab ich nix am Hut...

    matze555 schrieb:

    ... Eventuell will da jemand sich ein Windowscontrol holen, das nicht da ist oder es nur in falscher Version bekommt.

    Das dachte ich auch schon, nur wer soll das sein? Und die haben ja eigentlich (hoffentlich) eigene Initialisationen...
    Ich habe auch nur BCB Zeug drin oder eigene Komponenten.
    Ausnahme: IE/ Mediaplayer alsd ActiveX. Da hab ich aber das CoInit & Co drin.

    matze555 schrieb:

    Mit welcher BCB Version ist das Programm denn erstellt? 5, 6? oder schon Embarcadero?

    Ich mach noch mit dem BCB 4.0 rum.

    Komisch ist, ja, dass es mit meinem Trick klappt...

    Gruss
    frank

    0
  • M

    DerAltenburger schrieb:

    matze555 schrieb:

    ... also wenn das CoInit geholfen hat, wird eventuell mal wieder irgendwas mit MS schieflaufen. Versuch mal die Common-Controls Version zu erzwingen. Siehe dazu:
    http://www.c-plusplus.net/forum/p2018436#2018436

    Mit Manifesten hab ich nix am Hut...

    ... Du nicht, aber Windows. Ohne Manifest fängt Windows an die dollsten Sachen zu veranstalten. Nenn Deine EXE mal *setup*.exe und starte es, schwups meint Windows Adminrechte einfordern zu müssen. Beendest Du das Programm wieder, hast aber nix in der Registry hinterlassen, gib't plötzlich eine Fehlermeldung das das Programm nicht ordnungsgemäß beendet wurde, etc etc. Abhilfe bringt da nur ein Manifest.
    Mein Tip hat sich auch nur auf die Common Controls Abteilung im Manifest bezogen. Wenn Du aus der VCL z.B. einen FileOpenDialog drin hast, hast Du auch die CommonControls am Hals. Ich kenn den Effekt mit Absturz vor WinMain in BCB Programmen. Das ist aber schon ein ganzes Weilchen her... 😞

    Die CControls auf Version 6.0 festzunageln hatte damit glaube ich zu tun. Auf jeden Fall hab ich seit dem generell weniger Probleme mit BCB5/6 unter Win7.
    Bei Verwendung von speziellen Windows API's, besonders alles was direkt mit COM zu tun hat, ist CoInit teilweise sogar ein Muss als allerersten Befehl in WinMain. Ansonsten können auch "Inkonsitenzen" bei den Packages Grund für den Absturz sein. BCB's Verzeichnisverwaltung ist absolut grottig. Wenn man eigene Packages verwendet und dadurch eventuell diverse Versionen davon rumfliegen hat, kann es passieren das im Designer zwar die aktuelle Version verwendet wird, der Linker jedoch eine ältere Lib erwischt. Im ungünstigen Fall können alle Symbole aufgelöst werden, aber die Pointer passen nicht mehr zum binary.
    Ein komplettes remake aller Beteiligten hat dann geholfen.
    Da es in diesem Fall aber auf einigen Rechnern geht und auf anderen nicht, spricht das eigentlich für einen Versionkonflikt von Systemkomponenten. Und da sind die CommonControls die erst Wahl für eine Untersuchung, da die VCL die initialisiert und verwendet bevor WinMain aufgerufen wird.

    0
  • A

    audacia schrieb:

    Außerdem ist vielleicht das hier noch hilfreich:
    http://blogs.embarcadero.com/chrishesik/2007/05/24/34829 - C++Builder: Debugging application startup

    Wäre es wohl... wenn es noch vorhanden wäre (ist gelöscht).

    0
  • A

    asc schrieb:

    audacia schrieb:

    Außerdem ist vielleicht das hier noch hilfreich:
    http://blogs.embarcadero.com/chrishesik/2007/05/24/34829 - C++Builder: Debugging application startup

    Wäre es wohl... wenn es noch vorhanden wäre (ist gelöscht).

    Tatsächlich. Vor ein paar Tagen war es noch da.

    Aber wir sind ja kreativ und werfen einen Blick ins Internet-Archiv 😉

    0
Anmelden zum Antworten