Excel x64/VBE execute AV: live segment-heap entry is PAGE_READWRITE (Windows 26H2)

Please assess this case with the Excel/VBA runtime and Windows heap teams and identify a supported serviced build or mitigation. The failure is intermittent; we are not claiming a confirmed Microsoft product defect or a specific permission-change mechanism.

Environment

- Windows 11 26H2, build 26300.9550; ntdll.dll 10.0.26100.9549.

- Microsoft 365 Click-to-Run, Current Channel, Excel x64 16.0.20430.20146.

- VBE7.DLL 7.01.1158, SHA256 8AD9E8D123B4FD84DE6DF7FC931D69A556540B38317DFCEF3B4CF7A5535D48E8.

- Microsoft signatures of Excel, VBE7 and ntdll validated locally.

- Kaspersky 21.27 com_antivirus.dll and product_info.dll were loaded. Their involvement is unknown; antivirus/AMSI and Windows mitigations were not disabled.

- No Excel-specific heap override or AppCompat Layers override was found in the inspected locations. Excel IFEO contains MitigationOptions=256; this was not modified.

Captured failure on 13 October 2026, 13:05 CEST

A normally launched, separate Excel instance opened a read-only copy of a macro-enabled binary workbook. Startup and its initial data refresh completed, followed by four CalculateFullRebuild calls with EnableEvents=False, True, True, False. Each returned xlDone and ScreenUpdating=True. A first external COM helper released its references and exited. After approximately 65 seconds idle, a fresh external COM helper invoked a public Boolean status getter using Application.Run. The getter body only returns a module-level Boolean variable.

CDB caught first-chance C0000005 before execution of that VBA getter body:

- Exception parameter 0: 8 (execute); target 0x00000260bb2b947c.

- !address: MEM_COMMIT, MEM_PRIVATE, PAGE_READWRITE (0x04), not executable.

- !heap -x: live LFH Allocated block in segment heap 0x0000026091000000.

- Block address 0x00000260bb2b8d70; requested size 4144; block size 4352; unused 208.

- Entry bytes contain movq xmm5,r12, a load referring to VBE7!g_PPExSP, and a jump to VBE7!ProcCallEngine.

- Call chain includes oleaut32!DispCallFuncAmd64, DispCallFunc, VBE7!DispCallFuncWrap, EpiInvokeMethod, CDispVbaStdMod::Invoke, EXCEL!HrGuardedDispatchInvoke, HrBookCallMacro and _HrGlobalRun.

After allowing normal exception handling, Excel started its recovery process and the failing process exited with code 0. The COM caller received DISP_E_EXCEPTION (0x80020009). Thus exit code 0 and absence of a Windows crash dialog were not evidence of a healthy session.

An earlier capture on the same machine showed an execute AV at another generated VBA entry during SheetCalculate dispatch. Users also reported black worksheet regions before unexpected Excel exit. We have not established that all rendering symptoms share this native cause.

What has and has not been established

The workbook source has no VirtualProtect/VirtualAlloc or heap-allocation calls. The runtime fault at a simple status getter is not explained by a long VBA loop or ScreenUpdating=False. The actor and moment that produced PAGE_READWRITE have not been captured.

A subsequent monitored repetition, watching 18 initially executable VBA entry pages and then 22 pages after recalculation, completed without the AV or an observed matching protection-change call. Monitoring included selected overlapping NtAllocateVirtualMemoryEx/NtAllocateVirtualMemory/NtProtectVirtualMemory calls. This negative run does not retract the captured failure. A separate synthetic blank-workbook event/ordinary data-allocation test also did not reproduce this execute AV; we do not have a reliable minimal reproducer.

Requested guidance

1. Is this generated VBA entry in a live 4144-byte segment-heap allocation, currently PAGE_READWRITE, consistent with a known serviced issue?

2. Which supported Office or Windows build, if any, addresses this precise failure class?

3. Which targeted next trace or supported mitigation should be used, preserving DEP/ASLR/AMSI and normal workbook functionality?

4. If further evidence is needed, please specify the minimum sanitized trace and a private support route.

Full dumps and workbooks have been retained locally only. This report contains no workbook data, account identifiers, local user paths, credentials or full dump attachments. Any request for those files requires a separate decision by the owner.

Related unconfirmed first-hand report under a different Windows version: https://techcommunity.microsoft.com/discussions/excelgeneral/excel-x64vbe-event-entry-loses-execute-permission-in-the-default-segment-heap/4563077 . I have not traced the same permission-changing call in my own process.