Hilfe - HTTPS unterschiedliches Verhalten

[KlausV]

Hallo,
Umgebung Delphi 7 mit Indy 10.6.2.5459.
Entwicklungsumgebung: VMWARE mit Windows XP

Nun zum Problem:
Ich habe einen Client vor vielen Jahren geschrieben, der mit einem HTTP Server komuniziert und Aufträge auf den Server überträgt aber auch Daten abholt. Die hat alles wunderbar funktioniert.
Nun hat der Kunde auf HTTPS umgestellt.
Ich habe nun auch den Client auf HTTPS Logik umgestellt.
Dabei musste ich auch die Indy Version entfernen und neu installieren.

Der Kunde hat einen Test und Live Appache Server.
Auf beiden Servern hat es unter meiner Entwicklungsumgebung (Windows XP) mit dem neuen Client mit HTTPS funktioniert, auch jetzt noch. Nun nach dem Rollout gibt es Probleme mit dem live server unter windows 7 und 8. Auf dem test server weiterhin keine Probleme.
Ich bekomme folgenden Fehler:
Runtime Error 216 at 00403752

Da es unter der Entwicklungsumgebung funktioniert, kann ich das Programm nicht debuggen. Eine Entwicklungsumgebung unter Windows 7 / 8 wollte ich mir aktuell noch ersparen. Das wäre ein größerer Akt.
Komisch ist, dass die Verbindung stehen muss, auch unter HTTPS, weil der Auftrag wird übertragen und erst dann kommt die Fehlermeldung, also irgendwie im Nachgang.
Hat jemand eine Idee? Vor allem wie kann ich herausfinde, was das Problem ist.
Nun habe ich die URL im Delphi Programm wieder auf HTTP umgestellt und da kommt auch der runtime Fehler. Dann liegt es vermutlich gar nicht an HTTPS sondern an der der neu installierten Inddyy version. Sehr seltsam und wieso nur mit dem live server?
Schon mal vielen Dank.
Gruß Klaus

[himitsu]

Erstmal: 216 = AccessViolation (Zugriffsverletzung)

Zitat:

Zitat von KlausV (Beitrag 1409539)

Da es unter der Entwicklungsumgebung funktioniert, kann ich das Programm nicht debuggen. Eine Entwicklungsumgebung unter Windows 7 / 8 wollte ich mir aktuell noch ersparen. Das wäre ein größerer Akt.

Remote Debugging (delphi 7 remote debugging)

Ist im Prinzip das Geleiche wie bei 64 Bit Windows und den anderen Platformen (Mac, Linux, iOS und Android),
also der RemoteDebugger (oder neuerdings der PAServer) läuft beim Programm und der Debugger/DelphiIDE eventuell wo anders (via TCP/IP auch über das Internet und durch VPNs hinweg).

http://docwiki.embarcadero.com/RADSt...r_installieren
http://docwiki.embarcadero.com/RADSt...ernen_Debugger
http://docwiki.embarcadero.com/RADSt...tform_Assistan

Zitat:

Zitat von KlausV (Beitrag 1409539)

Hat jemand eine Idee? Vor allem wie kann ich herausfinde, was das Problem ist.

manuelles Logging
oder ein ErrorLog (Eurekalog, madExcept, ...)

[Delphi.Narium]

Das Programm bei Dir im Debugger starten und nach der Adresse 00403752 suchen. Dann solltest Du ungefähr in der Fehlergegend landen.

Programm mit MAP-Datei erstellen und in der dann nach der Adresse suchen, eventuell kommst Du damit etwas mehr an Info.

Nutzt Du zufällig die JVCL?

Dann den ExceptionDlg.pas aus \jvcl\install\JVCLInstall\Debug einbinden.

(in https://www.delphipraxis.net/187827-...einer-ist.html ca. ab Post #19)

Ansonsten: https://www.delphipraxis.net/794513-post2.html

[KlausV]

Zitat:

Zitat von Delphi.Narium (Beitrag 1409543)

Das Programm bei Dir im Debugger starten und nach der Adresse 00403752 suchen. Dann solltest Du ungefähr in der Fehlergegend landen.

Programm mit MAP-Datei erstellen und in der dann nach der Adresse suchen, eventuell kommst Du damit etwas mehr an Info.

Nutzt Du zufällig die JVCL?

Dann den ExceptionDlg.pas aus \jvcl\install\JVCLInstall\Debug einbinden.

(in https://www.delphipraxis.net/187827-...einer-ist.html ca. ab Post #19)

Ansonsten: https://www.delphipraxis.net/794513-post2.html

Danke schon mal für die schnelle Info.
JVCL nutze ich nicht.
In der MAP Datei finde ich diese Nummer nicht.
Während des Debug habe ich die Nummer gesucht mit Search->Find Error. Dann kommt: 8BC3 mov eax,ebx. Wenn ich weiter nach oben scrolle, dann kommt EIdWinsockStubError.Build. Keine Ahnung, ob es das ist was du meinst.

[Luckie]

Runtime Error 216 deutet auf eine Zugriffsverletzung hin. Du greifst auf ein Objekt zu, das nicht mehr existiert.

[KlausV]

Zitat:

Zitat von Luckie (Beitrag 1409547)

Runtime Error 216 deutet auf eine Zugriffsverletzung hin. Du greifst auf ein Objekt zu, das nicht mehr existiert.

Ich habe das Programm mit mehr debug infos kompiliert und dann auf meinem PC installiert.
Nun kommt Runtime Error at 00458706. Dies bleibt nun auch so, egal wie oft ich es aufrufe.

Nur, wieso habe ich den Fehler nur beim Zugriff auf das Live System?

[mjustin]

Zitat:

Zitat von KlausV (Beitrag 1409549)

Zitat:

Zitat von Luckie (Beitrag 1409547)

Runtime Error 216 deutet auf eine Zugriffsverletzung hin. Du greifst auf ein Objekt zu, das nicht mehr existiert.

Ich habe das Programm mit mehr debug infos kompiliert und dann auf meinem PC installiert.
Nun kommt Runtime Error at 00458706. Dies bleibt nun auch so, egal wie oft ich es aufrufe.

Nur, wieso habe ich den Fehler nicht beim Zugriff auf das Test System?

Es ist nicht unüblich dass das Testsystem anders konfiguriert ist als das Produktionssystem. Bei den UPS.com APIs hat man zum Beispiel dort alte Sicherheitsverfahren abgeschaltet, damit die Entwickler auf neuere umstellen.

Was genau es ist kann man schwer sagen. Einen ersten Anhaltspunkt könnte man mit SSL Test-Tools erhalten, zum Beispiel https://www.ssllabs.com/ssltest/ als Online-Test.
Diese Tools listen alle Parameter und Sicherheitsverfahren auf die der Server unterstützt. Wenn der Echt-Server zum Beispiel nur TLS 1.2 und TLS 1.1 unterstützt, und der Testserver auch TLS 1.0, kann man die entsprechende Konfiguration des Indy SSL IO Handlers prüfen.

[Delphi.Narium]

Das EIdWinsockStubError.Build klingt ja schonmal nach 'ner Fehlermöglichkeit im Umfeld der Sockets.

Runtimeerror 216 läßt (in der Regel) darauf schließen, dass was nach seiner Freigabe noch genutzt wurde.

Prüf' bitte mal, wo und in welcher Reihenfolge Du (Indy)Komponenten erstellst und wieder freigibst. Eventuell hakt da was.

Der Fehler scheint letztlich irgendwo vor dem EIdWinsockStubError.Build aufzutreten. Du müsstest jetzt quasi rückwärts debuggen können. Da das nicht geht versuche mal irgendwie die letzten Schritte vorher zu loggen.

Eventuell beschreibst Du uns mal kurz die letzten Programmschritte vor dem Fehler.

Also z. B.: Fehler tritt nur beim Programmende auf.
Fehler tritt in 'nem Timerereignis auf ...

Werden die Indy-Komponenten einmalig erstellt (z. B. sind auf ein Formular gepappt) oder werden sie je nach Bedarf erstellt und anschließend freigegeben?

Findest Du EIdWinsockStubError.Build in der MAP-Datei?
Wenn ja: Davor steht eine Adresse in der Art: 0001:001877A4
Suche bei laufendem Debugger bitte mal nach dieser Adresse: 001877A4 und versuche dann im Quelltext rückwärts zu gehen, bis Du einen möglichen Auslöser dieser Exception findest.

Definiert ist das Teil in der Unit IdWinsock2.

Welche SSL-Methode Du nehmen musst, kannst Du eventuell mit ('ner abgewandelten Version) des folgenden Quelltextes erfahren:

Delphi-Quellcode:

function MyGetSSLMethod(http: tidHTTP; SSL : TIdSSLIOHandlerSocketOpenSSL; sUrl: string; var sMessage: string): Integer;
var
  sMethod: string;
  myIdSSLVersion: TIdSSLVersion;
begin
  Result := -1;
  for myIdSSLVersion := Low(TIdSSLVersion) to High(TIdSSLVersion) do begin
    SSL.SSLOptions.Method := myIdSSLVersion;
    sMethod := GetEnumName(TypeInfo(TIdSSLVersion), Ord(myIdSSLVersion));
    try
      http.RedirectMaximum := 0;
      http.HandleRedirects := false;
      http.Response.Clear;
      http.Get(sUrl);
      http.Disconnect(True);
      http.IOHandler.InputBuffer.Clear;
      sMessage := sMethod;
      Result := Ord(myIdSSLVersion);
      break;
    except
      on e: Exception do begin
        case http.ResponseCode of
          301, 302 : begin
                      sMessage := sMessage + #13 + http.ResponseText;
                     end;
        else
          sMessage := sMessage + #13 + AnsiReplaceText(e.Message, #13#10, ' ');
        end;
        PSReg.WriteAppLog(Format('Scriptaufruf : GetSSLMethod(%s)', [sUrl]));
        PSReg.WriteAppLog(Format('Fehlermeldung: %s', [AnsiReplaceText(e.Message, #13#10, ' ')]));
        PSReg.WriteAppLog(Format('SSLMethod    : %s', [sMethod]));
        http.Disconnect(True);
        http.IOHandler.InputBuffer.Clear;
      end;
    end;
  end;
end;

[KlausV]

Ich habe madexcepts installiert und hier steht u.a.:
executable : DMSClient.exe
exec. date/time : 2018-08-02 18:10
version : 3.1.0.0
compiled with : Delphi 7
madExcept version : 4.0.20
DMSClient.exe.mad : $0000d5c4, $81484d02, $a5ca6cfd
callstack crc : $71fbbae8, $b07f6f5a, $b07f6f5a
exception number : 1
exception class : EIdWinsockStubError
exception message : Error on call to Winsock2 library function shutdown: Die Anwendung hat die Funktion WSAStartup nicht aufgerufen, oder bei dieser Funktion ist ein Fehler aufgetreten.
Das deutet auf einen Socket error hin.

[Delphi.Narium]

Weiß nicht, welche Indykomponenten alle bei Dir im Einsatz sind, deshalb mal sinngemäß für TIDHttp:

Delphi-Quellcode:

  // immer!!!
  // nachdem eine Aufgabe erledigt wurde, auch im Fehlerfalle:
  idhttp.Disconnect(True);
  idhttp.IOHandler.InputBuffer.Clear;

Seit dem ich das so handhabe, hab' ich bei der Nutzung dieser Komponente deutlich weniger Fehlermeldungen (eigentlich fast keine mehr).

Schau bitte mal, ob Du bei Deinem Quelltext etwas ähnliches umsetzen kannst. Alle Verbindungen explizit beenden, alle Buffer explizit leeren.

Wenn beim Programmenden nämlich noch 'ne Verbindung offen ist, eine Komponenten schon freigegben wurde, während eine andere die beim Beenden der Verbindung noch braucht, kann der Fehler 216 auftreten.

Diese Abhängigkeit hat man z. B. bei 'ner TIDHTTP und 'nem zugewiesenen IOHandler, also z. B. 'ner TIdSSLIOHandlerSocketOpenSSL.

TIDHTTP wird freigegeben und anschließend erst TIdSSLIOHandlerSocketOpenSSL.

Oder umgekehrt:

TIdSSLIOHandlerSocketOpenSSL ist schon weg und TIDHTTP will dann seine Verbindung schließen.