Subject: TAdvWebBrowser crashes on creation (Access Violation) — root cause identified in TAdvWinWebBrowser.SetupWebView (ICoreWebView2_13 / ICoreWebView2Profile)
Component: TAdvWebBrowser / TAdvWinWebBrowser (TMS VCL UI Pack Extra)
Package date: 20.07.2026
IDE: RAD Studio / Delphi XE7 (rtl210.bpl / vcl210.bpl)
Platform: Win32
Symptom:
Placing a TAdvWebBrowser on a form causes an immediate Access Violation — both at design-time (dropping the component, or opening any form containing it in the Form Designer) and at runtime (starting a compiled app whose form contains it). 100% reproducible in a brand-new, empty VCL project, with zero properties set on the component. Reproducible after a complete clean uninstall/reinstall of TMS VCL UI Pack and a full Windows restart, ruling out any local installation/cache issue.
Stack trace:
(8B504219){bds.exe } [8B505219]
[50066A9C]{rtl210.bpl } System.@IntfClear (Line 36046, "System.pas" + 10) + $0
[500635C0]{rtl210.bpl } System.@FinalizeRecord (Line 31136, "System.pas" + 25) + $0
[500636C0]{rtl210.bpl } System.@FinalizeArray (Line 31423, "System.pas" + 127) + $0
[500636D0]{rtl210.bpl } System.@FinalizeArray (Line 31435, "System.pas" + 139) + $0
[500635C0]{rtl210.bpl } System.@FinalizeRecord (Line 31136, "System.pas" + 25) + $0
[5071635B]{vcl210.bpl } Vcl.Forms.TApplication.ProcessMessage (Line 10352, "Vcl.Forms.pas" + 23) + $1
[5071639E]{vcl210.bpl } Vcl.Forms.TApplication.HandleMessage (Line 10382, "Vcl.Forms.pas" + 1) + $4
[507166D1]{vcl210.bpl } Vcl.Forms.TApplication.Run (Line 10520, "Vcl.Forms.pas" + 26) + $3
Root cause — confirmed by isolation testing:
We compared our currently installed AdvWebBrowser.Win.pas against an older, previously-working version we had archived. The diff is small (~90 lines) and one new block in TAdvWinWebBrowser.SetupWebView stood out — added right before FWebBrowserController.put_IsVisible(True), i.e. exactly in the async WebView2-controller-created completion callback (which explains why the crash surfaces via TApplication.ProcessMessage):
if Assigned(FWebBrowserWebView2) and (FWebBrowserWebView2.QueryInterface(IID_ICoreWebView2_13, w13) = S_OK) then
begin
if w13.get_Profile(p) = S_OK then
p.put_PreferredColorScheme(COREWEBVIEW2_PREFERRED_COLOR_SCHEME_LIGHT);
FWebViewVersion := 13;
end;
We tested this directly: commenting out this exact block (nothing else changed) and rebuilding the package eliminates the crash completely — confirmed in a fresh, isolated test project.
Suspected underlying issue in the interface declarations:
ICoreWebView2_13 = interface(ICoreWebView2_12)
[IID_ICoreWebView2_13GUID]
function get_Profile(out value: ICoreWebView2Profile): HRESULT; safecall;
end;
ICoreWebView2Profile = interface
[IID_ICoreWebView2ProfileGUID]
procedure Placeholder_get_ProfileName; safecall;
procedure Placeholder_get_IsInPrivateModeEnabled; safecall;
procedure Placeholder_get_ProfilePath; safecall;
procedure Placeholder_get_DefaultDownloadFolderPath; safecall;
procedure Placeholder_put_DefaultDownloadFolderPath; safecall;
function get_PreferredColorScheme(value: PCOREWEBVIEW2_PREFERRED_COLOR_SCHEME): HRESULT; stdcall;
function put_PreferredColorScheme(value: COREWEBVIEW2_PREFERRED_COLOR_SCHEME): HRESULT; stdcall;
end;
get_Profileis declaredsafecallbut also declares an explicitHRESULTreturn type — that combination looks inconsistent with the idiomatic Delphisafecall-COM pattern used elsewhere in this same file (wheresafecallmethods normally don't expose the HRESULT in the Pascal signature).ICoreWebView2Profilemixessafecall"Placeholder_*" stub methods withstdcallreal methods in the same vtable — if the calling convention and/or slot count/order here doesn't exactly match Microsoft's actualICoreWebView2ProfileCOM interface, any call through it (e.g.put_PreferredColorScheme) would invoke the wrong vtable slot with the wrong parameter-passing convention, corrupting the stack/heap — which would surface later as theFinalizeRecord/FinalizeArray/IntfClearcorruption we're seeing.
Also noticed in passing (probably unrelated, but possibly a copy-paste artifact worth checking): IID_ICoreWebView2Profile2 is declared but assigned the base IID_ICoreWebView2ProfileGUID constant rather than a distinct ...Profile2GUID:
IID_ICoreWebView2ProfileGUID = '{79110ad3-cd5d-4373-8bc3-c60658f17a5f}';
IID_ICoreWebView2Profile2: TGUID = IID_ICoreWebView2ProfileGUID;
Request: Could you review the ICoreWebView2_13.get_Profile / ICoreWebView2Profile declarations and the PreferredColorScheme initialization code in TAdvWinWebBrowser.SetupWebView against the actual WebView2 SDK ICoreWebView2Profile interface? We're happy to provide our patched (working) version of AdvWebBrowser.Win.pas for comparison if useful.