XE2 / Error after compile : 0xc000007B

[CCRDude]

Zitat von bernhard_LA:

ich denke der Crash passiert noch vor dem Ausführen der ersten Zeile Code

Weil ein Breakpoint auf der ersten Zeile des Hauptprogrammes nicht vor dem Crash erreicht wird, oder bist Du Dir da sicher?

Je nach eingebundenen Units haben die ja initialization-Parts, die theoretisch auch schon vor dem Laden von SysUtils und damit dem Initialisieren des exception handlings ausgeführt werden und Fehler werfen können.

Du hast bei der OS-Angabe die Sprache vergessen. Wäre es ein englisches Delphi auf deutschem OS oder genau umgekehrt, wäre die Herkunft der Meldung zumindest klar.

Ansonsten... bei Startproblemen würd ich zuerst einen elevated Start probieren, und danach das Manifest peinlich genau überprüfen, ggfls. auswechseln.

Externe DLLs verwendet zudem jedes Programm (zumindest Delphi-Programm, denn ohne Delphi-RTL geht's nicht)! Auch statisch gelinkte DLLs können Streß machen. Unter anderem aufgrund des Suchpfades, wenn DLLs unterschiedlicher Version im Programm- sowie im Systemverzeichnis liegen.

[Uwe Raabe]

Zitat von CCRDude:

Externe DLLs verwendet zudem jedes Programm (zumindest Delphi-Programm, denn ohne Delphi-RTL geht's nicht)!

Die Delphi-RTL liegt allerdings gerade nicht als DLL vor! Insofern sind die externen DLLs, die ein Programm benutzt vorwiegend die des Betriebssystems. Solange sich also nicht irgendwelche (und sei es Kopien) davon im Suchpfad oder gar im Exe-Pfad befinden, kann man erstmal davon ausgehen, daß das OS weiß, wo es die findet.

[CCRDude]

Zitat von Uwe Raabe:

Die Delphi-RTL liegt allerdings gerade nicht als DLL vor!

Wo habe ich das denn behauptet? Ich habe nur geschrieben, daß Teile der RTL immer verwendet werden. Und in diesen Teilen sind statische Imports auf System-DLLs.

[himitsu]

Weil ein Breakpoint auf der ersten Zeile des Hauptprogrammes nicht vor dem Crash erreicht wird, oder bist Du Dir da sicher? Mit F7 starten bringt auch nicht?
Eventuell auch mal die Debug-DCUs aktivieren, in den Projektoptionen.

Welches Ausgabeformat ist denn eingestellt? (Win32, Win64, OSX ...)

[Harry Stahl]

Genau das gleiche Problem habe ich jetzt auch bei XE7, wenn ich die 32-Bit-Version als 64-Bit laufen lassen möchte. Kompilieren geht, aber Programm stürzt sofort ab.

Gibt es hierfür inzwischen nähere Erkenntnisse?

[Perlsau]

Zitat von Harry Stahl:

Genau das gleiche Problem habe ich jetzt auch bei XE7, wenn ich die 32-Bit-Version als 64-Bit laufen lassen möchte. Kompilieren geht, aber Programm stürzt sofort ab. Gibt es hierfür inzwischen nähere Erkenntnisse?

Wie kann man "die 32-Bit-Version als 64-Bit laufen lassen"? Meintest du nich vielmehr 64-Bit-Kompilat? Also du entwickelst und testest deine Anwendung mit 32 Bit und am Ende erstellst du aus demselben Code eine 64-Bit-Anwendung, die dann abstürzt?

Also ich hab's weder mit XE2 noch mit XE7 je erlebt, muß allerdings dazusagen, daß ich mit beiden immer nur sporadisch arbeite. Manche Dinge scheinen mit 64-Bit ein wenig anders zu laufen. So hatte ich seinerseits von Hathor und dem schönen Günter den Tip bekommen, in OnCreate des Hauptformulars folgede IfDefs einzutragen (gemeint ist nicht das mit der Caption):

Delphi-Quellcode:

  Saved8087CW := Default8087CW;
  {$IFDEF WIN64}
  Self.Caption := GLD.Programmtitel + '64-Bit-Version';
  System.Set8087CW($133f);
  {$ELSE}
  Self.Caption := GLD.Programmtitel + '32-Bit-Version';
  System.Set8087CW(Saved8087CW);
  {$ENDIF}

Danach ist mein 64-Bit-Kompilat nicht mehr abgestürzt. Mir ist natürlich klar, daß es sich bei dir um eine andere Fehlermeldung handelt, aber ich wollte nur darauf hinweisen, daß man für 64 Bit nicht immer denselben Code verwenden kann wie für 32 Bit.

[Harry Stahl]

Ja klar, ich meinte die kompilierte 64-Bit-Version. Dass einige Sachen anders in der 64-Bit-Version sein müssen, habe ich natürlich berücksichtigt.

Aber zum Oncreate-Ereignis des Hauptformulars kommt das Programm gar nicht, sondern stürzt direkt ab. Es werden also auch nicht die Initialisierungsabschnitte der einzelnen Units durchlaufen.

Wenn ich mit F7 das Programm bzw. den Debugging-Prozess starte, lande ich direkt im CPU-Fenster, siehe anliegenden screenshot. Einmal weiter auf F7 gedrückt und schon stürzt das Programm ab.

Die Theorien, dass es an irgendwelchen geladenen 32-bit-Dlls liegen könnte trifft nicht zu, da ich keine DLL's direkt zum Programmstart lade sondern nur dynamisch bei Bedarf (zur Sicherheit habe ich auch auch mal alle DLL's aus dem Programmverzeichnis entfernt).