D10.4.2 TWebBrowser funktioniert in der IDE nicht immer

[Michael II]

In einer VCL App verwende ich TWebBrowser zum Anzeigen von News. Seit 10.4.2 werden in der IDE beim Laden von Seiten immer wieder Exceptions angezeigt. Ich verwende Microsoft Windows [Version 10.0.19043.844]

Ich kann einen Teil der Probleme mit einem einfachen Beispiel nachbauen: Formular mit einer TWebBrowser Komponente und einem Button.

Delphi-Quellcode:

procedure TForm56.Button1Click(Sender: TObject);
begin
  webbrowser1.Navigate('http://www.google.ch' );
end;

Wenn ich den Button klicke und damit
webbrowser1.Navigate('http://www.google.ch' );
aufrufe, dann werden immer wieder in

Delphi-Quellcode:

function TApplication.ProcessMessage(var Msg: TMsg): Boolean;
...
begin
...
    if MsgExists then
    begin
...
          not Handled and not IsMDIMsg(Msg) and
          not IsKeyMsg(Msg) and not IsDlgMsg(Msg) then
        begin
          TranslateMessage(Msg);
          if Unicode then
            DispatchMessageW(Msg) <<<====

bei gewissen Msg Werten ((m=32770 w=0 l=0), (m=275 w=8200 l=0)) Exceptions ("Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x69763714" -- Zugriffsverletzung bei Adresse 69763714 in Modul 'MSHTML.dll (11.00.19041.844 (WinBuild.160101.0800) Timestamp 6.12.13)'. Lesen von Adresse xxx) ausgelöst. Wenn ich Anhalten klicke, dann zeigt die IDE auf <<<==== (siehe Code oben).
Wenn das Programm ausserhalb der IDE läuft, dann tritt kein Problem auf.


Wenn ich eine lokale Datei lade
webbrowser1.Navigate('C:\Users\micha\Desktop\bug.t xt');
dann meldet die IDE Exceptions in

Delphi-Quellcode:

procedure TOleControl.DefaultHandler(var Message);
begin
...
          Result := CallWindowProc(DefWndProc, Handle, Msg, WParam, LParam); <<== m=514 p=0 L'

Liegt dies an der aktuellen Beta von Windows oder an der Delphi IDE?

[himitsu]

Die Exceptions werden nur in der IDE angezeigt?
Es geht in der gedebugten Anwendung kein Fehlerdialog auf?

Wenn ja, dann "ignoriere" es doch einfach.
Diese Exception wurde dann ja wohl irgendwo mit einem Try-Except (o.Ä) abgefangen.



Und ja, beim Debuggen ist es nervig, aber das ist wie, wenn ein Archloch im Code sowas versteckt

Delphi-Quellcode:

try
  i := StrToInt(S);
except
  i := 0;
end;

, anstatt

Delphi-Quellcode:

i := StrToIntDef(S, 0);

.

[Michael II]

Zitat:

Zitat von himitsu (Beitrag 1484374)

Die Exceptions werden nur in der IDE angezeigt?
Es geht in der gedebugten Anwendung kein Fehlerdialog auf?

Wenn ja, dann "ignoriere" es doch einfach.
Diese Exception wurde dann ja wohl irgendwo mit einem Try-Except (o.Ä) abgefangen.
[/DELPHI].

Wenn ich die App aus dem Windows Explorer starte wird nix angezeigt.

Wenn ich die App exe in Delphi (Start > Prozess laden...) lade, dann wird die Exception angezeigt.

Wie du schreibst: Ich verwende natürlich überall try finally/except, aber nicht in einem solchen Minimalprojekt.

Hier würde ein

Delphi-Quellcode:

procedure TForm56.Button1Click(Sender: TObject);
begin
 try
  webbrowser1.Navigate('http://www.google.ch' );
 except
  ...
 end;
end;

nichts nützen, da Navigate das Laden der Webseite zwar auslöst, aber sofort zurückkehrt und die Exception dann erst nach dem end; der procedure
TForm56.Button1Click in der MSHTML.dll auftritt.

In deinem Beispiel (strtoint) könnte ich nach dem Auftreten der Exception weiter debuggen. Hier geht das nicht, da nach der Anzeige der Exception nach Klick auf "Fortsetzen" die Meldung

Benachrichtigung über Debugger-Problem
---------------------------
In Projekt C:\..Project19.exe trat ein Problem mit folgender Meldung auf:
'access violation at 0x696a3714: read of address 0x0c259000'.
Prozess angehalten. Mit Einzelne Anweisung oder Start fortsetzen.
---------------------------
OK

angezeigt wird und nach OK Klick eine weitere Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x00000000: read of address 0x00000000' angezeigt wird. Und nix geht mehr.

Ich habe mein System mit MSERT gecheckt. Die DLLs scheinen alle OK zu sein.

Du schreibst "Exception einfach ignorieren". Das möchte ich nicht - eher baue ich den WebBrowser aus. (Es gibt ja bei solchen Fehlern Windows Versionen, welche solche Exceptions ernster nehmen als andere.)

Falls jemand das Problem und eine Lösung kennt, dann bin ich natürlich froh um Meldung.

Das mit Delphi mitgelieferte Beispielprogramm läuft natürlich genau gleich in diese Exception.

[Ich muss die App wohl oder übel mal auf einem anderen System remote debuggen.]

[TiGü]

Zitat:

Zitat von Michael II

Beta von Windows

Wichtige Information, ist aber leicht zu überlesen.

Hast du das Problem auch bei der letzten normalen Release-Version von Windows 10 20H2?

[himitsu]

Der Webbrowser lädt die Seiten asynchron, also Navigate startet nur und kehrt zurück.
Daher gibt es auch die vielen Events an der Komponente, für "bin fertig" und Dergleichen.

Probiere auch mal das Property Silent.

[Michael II]

Zitat:

Zitat von TiGü (Beitrag 1484403)

Zitat:

Zitat von Michael II

Beta von Windows

Wichtige Information, ist aber leicht zu überlesen.

Hast du das Problem auch bei der letzten normalen Release-Version von Windows 10 20H2?

Ja hast Recht, die Info Windows Beta gehört unbedingt in den Titel... hab's angepasst.

[ Die Exceptions können natürlich immer auch durch irgend ein "lokales" Problem ausgelöst werden. Da Windows aber relativ neu aufgesetzt ist und sfc und MSERT OK melden... Mal sehen. Heute habe ich noch auf einem [Version 10.0.17763.1757] Windows Server via PAServer getestet. Dort ist alles OK]

Auf das navigate(..) Problem aufmerksam geworden bin ich, weil navigate2(..) neu in meiner App immer ein Speicherleck auslöst (Code seit Jahren gleich und nie Probleme), wenn ich einen WebBrowser zur Laufzeit erzeuge und WebBrowser1.SelectedEngine := EdgeIfAvailable; setze. ]


Tipp von himitsu: Silent spielt keine Rolle. Exception bleibt.

[Michael II]

Ich habe eine alte Kiste mit XE3 gefunden (im Umzugkarton seit über 1 Jahr...), dort die WebBrowser App erstellt und auf mein Win10 Microsoft Windows [Version 10.0.19043.844] kopiert.

Gleiches Bild: Die App funktioniert aus dem Windows Explorer gestartet. Wenn ich microsofts "App Verifier" laufen lasse, wird die App in vielen Fällen geschlossen und der Fehler wird protokolliert.

Es liegt also definitiv nicht speziell an D14.2.

Sollte ich noch was finden (ob's generell an Windows oder speziell an meiner Konfiguration liegt), dann werde ich's hier posten.

[Der schöne Günther]

Die Windows-Version ist ja jetzt nicht so exotisch, das ist doch die aktuelle Build aus dem Beta-Channel, läuft z.B. auch bei mir.

[himitsu]

TWebBrowser kann man in verschiedenen Konfigurationen nutzen.
Seit Edge kann man auch wählen zwischen IE, NurEdge und EdgeWennnichtdadannIE. (auktuell steht der Default noch auf IE)

Und über die Registry konnte man, wenn ich mich nicht irre, auch festlegen welche IE-Version genommen werden soll. (kannst dazu was im Forum finden)

Windows Sandbox
Damit hast erstmal ein sauberes Windows, zum Testen (ab Professional)
https://winaero.com/enable-windows-1...wershell-dism/ (Menü oder Befehle zum Installieren)
https://docs.microsoft.com/de-de/win...ndbox-overview (Werbevideo)
https://www.delphipraxis.net/207151-...ml#post1484308 (noch nicht fertig, aber wäre genau was für dich gewesen :oops:)

Und da du mit IE/Edge Probleme hast, gäbe es auch noch
https://developer.microsoft.com/en-u...dge/tools/vms/


PS: https://www.delphipraxis.net/204466-...ebrowsers.html

[Michael II]

Herzlichen Dank für alle Tipps. Edge lief und läuft absolut problemlos, sowohl die neue Edge-Komponente wie auch TWebBrowser, wenn Edge selektiert.

Im Minimalprojekt nutzt TWebBrowser natürlich die Standardeinstellungen, also IE11.

Windows habe ich via RestoreHealth und sfc gecheckt. Zeigt nix an. (Was natürlich immer noch nicht bedeutet, dass alles OK.)

Peinlich wegen Win-Sandbox: Ich verwende noch Win Home... (Ich verspreche mir Besserung.)

Ich glaube, es liegt an ieframe.dll vom 18.2.21. (11....844).

Bei eingeschaltetem AppVerifier aus dem Win SDK tritt der Fehler (access violation at 0x69f43714) beim Debuggen (zum Beispiel) via Delphi immer (also reproduzierbar) auf.

Beim Abarbeiten (DispatchMessageW(Msg)) der ersten msg.Message=1125 in VCL.Forms function TApplication.ProcessMessage(var Msg: TMsg): Boolean;

direkt nach dem Rücksprung aus (pchKey=NIL, dw=0)

Delphi-Quellcode:

SHDocVW.pas: function TWebBrowser.GetOptionKeyPath(var pchKey: POLESTR; const dw: DWORD): HRESULT;
begin
  Result := E_FAIL;
end;

Dies nachdem zuvor

Delphi-Quellcode:

VCL.OleCtrls.TOleControl.Invoke(DispID: Integer; const IID: TGUID;
  LocaleID: Integer; Flags: Word; var Params;
  VarResult, ExcepInfo, ArgErr: Pointer): HResult;

DispID = -5512 => Result := DISP_E_MEMBERNOTFOUND;



- App Verifier aus dem Win SDK starten
- sich vergewissern, dass ieframe.dll vom 18.2.21, .844 installiert ist
- in SHDocVW einen Breakpoint in TWebBrowser.GetOptionKeyPath setzen
- das Minimalprojekt laufen lassen
- weitersteppen nach TWebBrowser.GetOptionKeyPath
=> access violation at 0x69f43714