[Problem/Bug]: WebView2 / Edge 148 crashes in V8 TurboFan JSInliner::InlineCall; NULL read at [rdi+0x17]

[InoriNatsume]

What happened?

I filed the corresponding Chromium issue here:

https://issues.chromium.org/issues/512708691

Microsoft Edge 148.0.3967.54 / WebView2 crashes with STATUS_ACCESS_VIOLATION inside V8's TurboFan inliner, JSInliner::InlineCall.

This was observed in a Tauri application using WebView2. I could not reproduce the same crash in Chrome 148 with the same application data.

Crash signature

I collected 10 Edge Crashpad dumps from the same repro session. All 10 show the same crash signature:

• Exception code: 0xC0000005
• RIP: 0x7FF9D408B185
• RDI: 0x0000000000000000
• Fault address: 0x0000000000000017
• Faulting instruction: movzx eax, byte ptr [rdi+0x17]

This is consistent with a NULL read at [rdi+0x17] inside JSInliner::InlineCall.

Isolation

• Normal launch: crash
• --js-flags=--no-opt: no crash
• --js-flags=--no-turbofan: no crash
• Edge 147.x: not reproduced
• Chrome 148 with the same application data: not reproduced
• Edge 149 Dev: not reproduced on my post-update system

Repro steps

1. Use Microsoft Edge 148.0.3967.54 / WebView2 on Windows 11.
2. Install or run RisuAI 2026.4.180 Tauri build.
3. Generate a minimal RISUSAVE database using the attached make_crash_db.mjs: node make_crash_db.mjs 200
4. Place the generated database.bin at %APPDATA%\com.risuai.risuai\database\database.bin
5. Launch RisuAI.

Expected behavior

The WebView2-based application should start normally. V8 should not crash while compiling or optimizing the JavaScript reactive state access path.

Actual behavior

The WebView2 runtime crashes on startup with STATUS_ACCESS_VIOLATION in V8 TurboFan JSInliner::InlineCall.

Notes

The crash occurs while launching a Svelte 5 / Tauri application after assigning a large heterogeneous object to a $state reactive store. The synthetic repro database contains 200 heterogeneous properties, above the observed crash threshold of approximately 150 properties.

I only observed this in Edge 148.0.3967.54 / WebView2. I have not proven whether the difference from Chrome 148 is due to Edge-specific V8 changes, WebView2/Edge embedder configuration, build flags, or heap layout.

After rebooting into updated Windows system DLLs from KB5089549, I could no longer reproduce the crash on the same machine. I am including this as a reproducibility caveat. I do not know whether the OS update changed heap layout, timing, or another environmental factor.

Raw minidumps are not attached publicly because they may contain local process metadata. I can provide them privately to Microsoft Edge/WebView2 or V8 maintainers upon request.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

148.0.3967.54

SDK Version

N/A - WebView2 used via Tauri

Framework

Other

Operating System

Windows 11

OS Version

26200.8457

Repro steps

1. Use Microsoft Edge / WebView2 Runtime 148.0.3967.54 on Windows 11 25H2 build 26200.8457.

2. Install or run RisuAI(https://github.com/kwaroran/RisuAI) 2026.4.180 Tauri build.

3. Generate a minimal RISUSAVE database using the attached make_crash_db.mjs:

   node make_crash_db.mjs 200

dump_analysis.txt
read_dump.mjs.txt
make_crash_db.mjs.txt
Bug_Report_Chromium.md
Analysis_Report.md

(GitHub does not allow attaching .mjs files directly, but the repro generator and minidump parser are attached in the Chromium issue linked above. I can also provide them renamed as .txt if needed.)

4. Place the generated database.bin at:

   %APPDATA%\com.risuai.risuai\database\database.bin

5. Launch RisuAI.

Expected behavior:
The WebView2-based application should start normally. V8 should not crash while compiling or optimizing the JavaScript reactive state access path.

Actual behavior:
The WebView2 runtime crashes on startup with STATUS_ACCESS_VIOLATION in V8 TurboFan JSInliner::InlineCall.

Isolation:

• Normal launch: crash
• --js-flags=--no-opt: no crash
• --js-flags=--no-turbofan: no crash
• Edge 147.x: not reproduced
• Chrome 148 with the same application data: not reproduced

Repros in Edge Browser

Yes, issue can be reproduced in the corresponding Edge version

Regression

Regression in newer Runtime

Last working version (if regression)

Runtime 147.x (exact build unknown); affected Runtime 148.0.3967.54

[github-actions]

Hi, @InoriNatsume!

It seems that your issue contains the word "crash". If you have not already, could you attach a crash dump as a comment?

WV2 crash dumps are located in a subfolder of the app's user data folder (UDF): <UDF>\EBWebView\Crashpad\reports\. By default, the user data folder is created in the app's folder with a name like <App Exe Name>.exe.WebView2. Refer to Crash Diagnostics for more information.

Thank you for your cooperation!

[InoriNatsume]

Thanks. I have not attached raw minidumps publicly because they may contain local process metadata.

I attached dump_analysis.txt, which contains parser output from 10 Edge/WebView2 Crashpad dumps. All 10 dumps show the same crash signature:

• Exception code: 0xC0000005
• RIP: 0x7FF9D408B185
• RDI: 0x0
• Fault address: 0x17

I can provide the raw minidumps privately to Microsoft Edge/WebView2 or V8 maintainers upon request.

[InoriNatsume]

Update: Symbolized call stack from minidump analysis

I ran the original minidumps through WinDbg Preview with Microsoft's public symbol server (srv*https://msdl.microsoft.com/download/symbols). The crash signature now resolves to fully symbolized frames.

Verified crash context

RIP:  msedge!v8::internal::compiler::JSInliner::InlineCall+0x5a5
      00007ff9`d408b185 0fb64717  movzx eax, byte ptr [rdi+17h]
RDI:  0x0000000000000000
Fault address: 0x0000000000000017

Full call stack (.ecxr; kb)

00  msedge!v8::internal::compiler::JSInliner::InlineCall+0x5a5
01  msedge!v8::internal::compiler::JSInliner::ReduceJSCall+0x564
02  msedge!v8::internal::compiler::JSInliningHeuristic::InlineCandidate+0x55
03  msedge!v8::internal::compiler::JSInliningHeuristic::Finalize+0xfa
04  msedge!v8::internal::compiler::GraphReducer::ReduceNode+0xb56
05  msedge!v8::internal::compiler::InliningPhase::Run+0x35c
06  msedge!v8::internal::compiler::PipelineImpl::Run<InliningPhase>+0x51
07  msedge!v8::internal::compiler::PipelineImpl::CreateGraph+0xbc
08  msedge!v8::internal::compiler::PipelineCompilationJob::ExecuteJobImpl+0xdf
09  msedge!v8::internal::OptimizedCompilationJob::ExecuteJob+0xaf
0a  msedge!v8::internal::OptimizingCompileTaskExecutor::RunCompilationJob+0x6f
0b  msedge!v8::internal::OptimizingCompileTaskExecutor::CompileTask::Run+0xd7
0c  msedge!base::internal::Invoker<...job_task_source.cc:110...>::Run+0xa7
0d  msedge!base::internal::TaskTracker::RunSkipOnShutdown+0x301
0e  msedge!base::internal::TaskTracker::RunAndPopNextTask+0xb03
0f  msedge!base::internal::WorkerThread::RunWorker+0x6df
10  msedge!base::internal::WorkerThread::RunPooledWorker+0x18
11  msedge!base::`anonymous namespace'::ThreadFunc+0x128
12  kernel32!BaseThreadInitThunk+0x17
13  msedge_exe!TargetBaseThreadInitThunk+0x54
14  ntdll!RtlUserThreadStart+0x2c

Registers at crash (.ecxr)

rax=00003d8c008e58c0  rbx=00003d8c048c0080  rcx=0000000000000000
rdx=0000000000000000  rsi=00003d8c03743e90  rdi=0000000000000000
rip=00007ff9d408b185  rsp=000000cdf8dfdae0  rbp=00003d8c037439f8
 r8=00003d8c037439a8   r9=0000000000000000  r10=00003d8c037439d0
r11=0000000000000033  r12=00003d8c03741730  r13=0000000000000000
r14=000000cdf8dfe3b8  r15=00003d8c037407c8

WER metadata (!analyze -v)

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_msedge.dll!v8::internal::compiler::JSInliner::InlineCall
FAILURE_ID_HASH:    {fbb2fec6-7ff8-84f4-e14d-a25a5f5d64d1}
Module + offset:    msedge!+0xa7b185
Process version:    148.0.3967.54
OS version:         10.0.26100.1 (Windows 11 25H2, ge_release)
Crash thread:       ThreadPoolForegroundWorker (TID 0x2c1c)

Observations the resolved stack adds

1. The buggy path is specifically JSInliningHeuristic::Finalize, not the main inlining reduction loop. Finalize is the late-stage pass over candidates accumulated during graph reduction (src/compiler/js-inlining-heuristic.cc). This is a narrower failure path than the OP suggested.

2. The crash is on a V8 concurrent compilation worker (OptimizingCompileTaskExecutor::CompileTask::Run → WorkerThread::RunPooledWorker). Off the main renderer thread, on a background compile task.

3. The non-zero general-purpose registers all carry V8 isolate-shaped pointers — their high 32 bits are consistently 0x00003d8c, matching the isolate's compressed pointer cage base. Only rdi, rcx, rdx, r9, r13 are zero. This pattern is more consistent with a single uninitialized/cleared slot in a candidate structure than with broader memory corruption or stack damage.

4. The faulting instruction is a single-byte read (movzx eax, byte ptr [rdi+17h]), so the field at offset 0x17 is byte-sized (or a byte-access optimization over a wider bitfield). I don't have V8 source access to identify the exact field, but JSInliner::InlineCall+0x5a5 should map directly with internal symbols.

Refined hypothesis

When JSInliningHeuristic::Finalize iterates accumulated candidates and calls InlineCandidate → ReduceJSCall → InlineCall, one candidate appears to reference a node (or node-attached structure) whose required field is NULL. With 150+ heterogeneous properties accumulated on a $state reactive proxy, the candidate queue likely grows large enough that an entry whose dependency was invalidated (or never properly initialized) survives until Finalize runs and dereferences it.

Happy to provide additional dumps, raw !analyze -v output, or any other decoded fields privately.

[venky8951]

Thank you for the detailed report and the thorough crash analysis.

We've investigated this internally and confirmed that the crash in JSInliner::InlineCall is entirely within upstream V8/Chromium TurboFan compiler code. Microsoft Edge does not carry any modifications to V8's inlining pipeline (js-inlining.cc) the crash path (
InliningPhase::Run → GraphReducer::ReduceNode → JSInliningHeuristic → JSInliner::InlineCall) is mostly upstream V8.

Since you've already filed the upstream Chromium bug (crbug.com/512708691) good to follow it up on it