Nach Update auf Delphi12 startet compiliertes Prog nicht mehr. Fehler bei LoadResStri

[bernau]

Ich bin von Delphi 11 auf Delphi 12 umgestiegen. Eigentlich alles gut. Nun habe ich festgestellt, dass ein Programm nicht mehr startet.

Breakpoint auf die erste Zeile im Projekt-Quelltext gesetzt. Dort kommt das Programm erst gar nicht an.

Also mit F7 gestartet und festgestellt, dass beim initialisieren der Units der Fehler auftritt.

In der Procedure InitUnits (Zeile 242003) aus der Unit System werden die einzelnen Units initialisiert.

Delphi-Quellcode:

// Unit System 

procedure InitUnits;
var
  Count, I: Integer;
  Table: PUnitEntryTable;
  P: Pointer;
begin
{$IF defined(EXTERNALLINKER)}
  dbk_RTL_initialized := 0;
{$ENDIF}
  if InitContext.InitTable = nil then
    exit;
  Count := InitContext.InitTable^.UnitCount;
  I := 0;
  Table := InitContext.InitTable^.UnitInfo;
{$IF defined(LINUX) and not defined(EXTERNALLINKER)}
  Inc(PByte(Table), InitContext.Module^.GOT);
{$ENDIF}
  try
    while I < Count do
    begin
      P := Table^[I].Init;
      Inc(I);
      InitContext.InitCount := I;
      if Assigned(P) and Assigned(Pointer(P^)) then
      begin
{$IF defined(MSWINDOWS)}



        TProc(P)();  // <----- Hier wird zum Initialisieren in die jeweilige Unit gesprungen.



{$ELSEIF (defined(POSIX) and defined(CPUX86)) and defined(ASSEMBLER)}
        CallProc(P, InitContext.Module^.GOT);
{$ELSE}
        TProc(P)();
{$ENDIF}
      end;
    end;
  except
    FinalizeUnits;
    raise;
  end;
{$IF defined(EXTERNALLINKER)}
  dbk_RTL_initialized := 1;
{$ENDIF}
end;

Bei der Unit "Soap.XSBuiltIns" lande ich sofort in der letzten QuellcodeZeile

Delphi-Quellcode:

// Letzte Zeilen der Unit Soap.XSBuiltIns

procedure InitXSTypes;
begin
  RemClassRegistry.RegisterXSClass(TXSDateTime, XMLSchemaNameSpace, 'dateTime', '',True);
  RemClassRegistry.RegisterXSClass(TXSTimeInstant, XMLSchemaNameSpace, 'timeInstant', '', True);
  RemClassRegistry.RegisterXSClass(TXSTime, XMLSchemaNameSpace, 'time', '', True);
  RemClassRegistry.RegisterXSClass(TXSDate, XMLSchemaNameSpace, 'date', '', True);
  RemClassRegistry.RegisterXSClass(TXSDuration, XMLSchemaNameSpace, 'duration', '', True);
  RemClassRegistry.RegisterXSClass(TXSDuration, XMLSchemaNameSpace, 'timeDuration', '', True);
  RemClassRegistry.RegisterXSClass(TXSHexBinary, XMLSchemaNamespace, 'hexBinary', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'decimal', '', True);
  {
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'integer', '', True);
  }
  RemClassRegistry.RegisterXSClass(TXSString, XMLSchemaNamespace, 'string', '', True);
  RemClassRegistry.RegisterXSClass(TXSBoolean, XMLSchemaNamespace, 'boolean', '', True);
  RemClassRegistry.RegisterXSClass(TXSInteger, XMLSchemaNamespace, 'int', '', True);
  RemClassRegistry.RegisterXSClass(TXSLong, XMLSchemaNamespace, 'long', '', True);

  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'negativeInteger', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'nonNegativeInteger', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'nonPositiveInteger', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'positiveInteger', '', True);
end;

end. // <---- Von TProc(P)(); landet der Debugger hier

Dann geht es weiter mit F7 in die Procedure _InitResStringImports

Delphi-Quellcode:

procedure _InitResStringImports(InitTable: Pointer);

//...
//...
//...

@@ustring:
        CALL    LoadResStringU

Dort geht es weiter mit F7 in die Procedure LoadResStringU

Delphi-Quellcode:

function LoadResStringU(ResStringRec: PResStringRec): UnicodeString;
begin
  Result := UnicodeString(LoadResString(ResStringRec));
end;

Und zum Schluss geht es weiter mit F7 in die Procedure LoadResString

Delphi-Quellcode:

function LoadResString(ResStringRec: PResStringRec): string;
var
  Buffer: array [0..4095] of Char;
begin  // <--- Hier landet der Debugger. Mit F8 erscheint sofort die Exception
  if ResStringRec = nil then Exit;
  if Assigned(LoadResStringFunc) then
    Exit(LoadResStringFunc(ResStringRec));
  if ResStringRec.Identifier < 64*1024 then
    SetString(Result, Buffer,
      LoadString(FindResourceHInstance(ResStringRec.Module^),
        ResStringRec.Identifier, Buffer, Length(Buffer)))
  else
    Result := PChar(ResStringRec.Identifier);
end;

Dann erscheint sofort die Exception

Code:

Im Projekt comcept3.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0xce93d58d: access of address 0xce93d58d' aufgetreten.

Ab hier stehe ich auf dem Schlauch.

Hat jemand eine Idee, wo ich weiter suchen kann?

[dummzeuch]

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

[Kas Ob.]

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

What did happen ?
Either : (these what came to mind, may be there is more)
1) a unit in initialization section directly had corrupted the stack, aka overwrite it,
2) a unit in initialization section performed an operation that pushed/fooled the memory manager to corrupt a global variable or singleton class, that lead to corrupted stack,
3) a unit in initialization section corrupted the stack by using the wrong calling convention.

Example : loading a library (DLL) with broken declaration (wrong call convention, like missing stdcall where it is needed or using it when it is not needed) could lead to this.

In all cases the error root is in the initialization section of one unit being initialized before "Soap.XSBuiltIns".

[bernau]

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Ich habe es befürchtet. Ist ja nicht so mein Ding. :x

[bernau]

Zitat:

Zitat von Kas Ob. (Beitrag 1538007)

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

What did happen ?
Either : (these what came to mind, may be there is more)
1) a unit in initialization section directly had corrupted the stack, aka overwrite it,
2) a unit in initialization section performed an operation that pushed/fooled the memory manager to corrupt a global variable or singleton class, that lead to corrupted stack,
3) a unit in initialization section corrupted the stack by using the wrong calling convention.

Example : loading a library (DLL) with broken declaration (wrong call convention, like missing stdcall where it is needed or using it when it is not needed) could lead to this.

In all cases the error root is in the initialization section of one unit being initialized before "Soap.XSBuiltIns".

The Unit called before "Soap.XSBuiltIns" is "Web.HTTPApp".

No Code in the initialization section

Delphi-Quellcode:

function TCustomWebFileDispatcher.DispatchRequest(Sender: TObject;
  Request: TWebRequest; Response: TWebResponse): Boolean;
var
  LDispatcher: TWebBrokerDispatchFileRequest;
begin
  LDispatcher := TWebBrokerDispatchFileRequest.Create(Self,
    Request, Response);
  try
    Result := LDispatcher.DispatchFileRequest;
  finally
    LDispatcher.Free;
  end;
end;

initialization
finalization
  FreeAndNil(FContentParsers);
end.

[Uwe Raabe]

Anhand der Stelle mit dem Fehler würde ich auch eine defekte Resource in Betracht ziehen.

[MichaelT]

Howdy,

Auch auf die Gefahr, dass ich mich unbeliebt mache. Clean und Build?

lg
Hoppy

Zitat:

Zitat von bernau (Beitrag 1538010)

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Ich habe es befürchtet. Ist ja nicht so mein Ding. :x

[bernau]

Zitat:

Zitat von MichaelT (Beitrag 1538022)

Howdy,

Auch auf die Gefahr, dass ich mich unbeliebt mache. Clean und Build?

lg
Hoppy

Zitat:

Zitat von bernau (Beitrag 1538010)

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Ich habe es befürchtet. Ist ja nicht so mein Ding. :x

Nope :cry:

[bernau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1538013)

Anhand der Stelle mit dem Fehler würde ich auch eine defekte Resource in Betracht ziehen.

Daran habe ich auch schon gedacht. Ich verwende keine selbst erstellten Ressourcen.

Habe die Ressourcen-Dateien *.rc, *.res und *.dres gelöscht. Die werden neu Aufgebaut. Fehler immer noch da.

Gibt es noch irgendwelche Ressourcen-Dateien, die ich vielleicht übersehen haben könnte?

[Kas Ob.]

Zitat:

Zitat von Kas Ob. (Beitrag 1538007)

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

Keep going back, i mean the empty initialization contains a simple ret instruction, which will work always, but some unit initialization before that did ruin you stack.
And to be exact, that exception you are receiving is hardware raised by a ret instruction while the stack value is $ce93d58d instead of the address pointing to right after "TProc(P)();"