Excel 4.0 macros are not working properly after last update Oct 2026
One of the functions I use in the name manager Eval1=LAMBDA(x,IF(TODAY(),EVALUATE(x),)) has stopped providing results. It only returns #NAME? as result. I have been using it for years without a problem and the last update (Oct 2026) I believe was the source of this issue. I have already checked the settings in the Trust Centre and are fine.
Excel “Trace Dependents” stops working in XLSX files generated by ChatGPT
Excel “Trace Dependents” stops working in XLSX files generated by ChatGPT – Cause and tested solution Problem When opening Microsoft Excel workbooks (.xlsx) generated by ChatGPT, the Trace Dependents feature may stop working, reporting that a cell has no dependents even when other cells explicitly reference it. The Trace Precedents feature may continue to function normally. In our testing, the problem was particularly difficult to diagnose because: It occurred repeatedly with Excel workbooks generated by ChatGPT. Opening an affected workbook caused Trace Dependents to stop working even in other workbooks that had previously worked correctly. The malfunction persisted after closing the affected workbook. Recalculating formulas, rebuilding the calculation chain and reconstructing the workbook did not consistently resolve the issue. Root cause identified The affected XLSX files generated by ChatGPT contained the following setting in xl/workbook.xml: forceFullCalc="1" This setting enables forced full calculation, bypassing Excel's normal dependency-based calculation mechanism. Tested solution Close Excel completely, including any remaining EXCEL.EXE processes. Open the affected XLSX file as a ZIP archive. Locate xl/workbook.xml. Find the <calcPr> element. Change forceFullCalc="1" to forceFullCalc="0", or remove the attribute. Save the corrected XLSX file. Restart Excel in a clean session. Open only the corrected workbook and test Formulas → Trace Dependents. Experimental confirmation We verified that: An original ChatGPT-generated workbook containing forceFullCalc="1" triggered the malfunction. The problem affected the entire Excel session and persisted after closing the original workbook. A corrected version containing forceFullCalc="0" worked when opened in a clean Excel session. The same issue was reproduced through multiple tests, including Excel Safe Mode. Recommendation for ChatGPT and XLSX-generation developers ChatGPT's spreadsheet-generation workflows should explicitly prevent the unnecessary activation of forceFullCalc=True. Before delivering generated XLSX files, the system should inspect xl/workbook.xml and ensure that persistent forced full calculation is disabled unless specifically required. This check is particularly important because the problem may affect not only the generated workbook but also other Excel workbooks opened in the same session. Scope and limitation This issue was repeatedly observed in workbooks generated through ChatGPT in our testing. The results do not establish that all ChatGPT-generated Excel files are affected, nor that this setting is responsible for every Trace Dependents malfunction. Nevertheless, the relationship between forceFullCalc="1" and the observed behavior was confirmed experimentally in the tested environment. Conclusion A ChatGPT-generated XLSX workbook with forceFullCalc="1" can trigger a persistent malfunction of Excel's Trace Dependents feature. Disabling this setting and restarting Excel restored the functionality in our tests.
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.Excel can still use legacy “Move and Size with Cells” checkboxes — but can no longer create them
Excel Can Still Use “Move and Size with Cells” Form Checkboxes — But It Can No Longer Create Them A reproducible Excel compatibility regression hiding inside legacy Form Controls For years, I have used Excel workbooks containing hundreds of Form Control checkboxes attached to product rows. These checkboxes behaved exactly as you would expect: - change the row height, and the checkbox stays inside that row; - filter the worksheet, and the checkbox disappears together with its product; - remove the filter, and the checkbox returns to the correct row; - no overlapping controls; - no “click one checkbox, activate another” behaviour. Recently, while rebuilding one of these workbooks in Excel 2024 LTSC, I discovered something very strange. The old checkboxes still work perfectly. But if I delete one and recreate it — even using the same VBA code that originally created the controls — Excel creates a different kind of placement behaviour. After a full day of controlled testing, XML inspection and A/B workbook comparison, the problem became clear: Excel can still read, display, save and execute legacy Form Control checkboxes using true “Move and size with cells” behaviour — but current Excel cannot recreate that same state for a newly created Form Control checkbox through the normal UI or VBA object model. That is not just inconvenient. For existing business workbooks, it is a serious backward-compatibility problem. The simple VBA code that used to work The original controls were created with ordinary Excel VBA: Set myCBX = wks.CheckBoxes.Add( _ Top:=cell.Top, _ Left:=cell.Left, _ Width:=cell.Width, _ Height:=cell.Height) Nothing exotic. No custom event engine. No ActiveX. No external add-in. Just a standard Excel Form Control checkbox positioned exactly over a cell. The workbook contains roughly 1,000 of these controls. The old ones still behave correctly today. The problem starts only after deleting them and creating new ones. What changes? In the Excel UI, the difference is immediately visible. For an original legacy checkbox: Format Control → Properties shows: Move and size with cells The option is selected, although it is greyed out. For a newly created checkbox in current Excel: Move but don’t size with cells is selected instead. That already suggests something changed internally. But the real evidence is inside the .xlsm package. The OOXML tells the story I created two controlled test workbooks: Workbook A Original legacy Form Control checkboxes that behave correctly. Workbook B The same workbook, but the checkboxes were deleted and recreated in current Excel using the original VBA logic. The internal OOXML differs. The working legacy controls contain placement information equivalent to: moveWithCells="1" sizeWithCells="1" and use genuine two-cell anchoring. The newly generated controls are instead stored using one-cell-style placement semantics, including: <xdr:twoCellAnchor editAs="oneCell"> The important part is not merely the XML syntax. The resulting behaviour is observably different. With the legacy control, both ends of the object are anchored to the worksheet grid. With the newly created control, Excel effectively preserves the control size while cells move underneath it. That distinction becomes disastrous when rows are resized, hidden or filtered. Why filtering exposes the problem Imagine a checkbox sitting on row 50. With the legacy behaviour: Checkbox ↔ Row 50 boundaries When row 50 changes size, the checkbox changes with it. If row 50 is filtered out, the control disappears with the row. When the row becomes visible again, the control is still exactly where it belongs. With the newly generated control, its dimensions are not tied to both cell boundaries in the same way. After repeated resizing and filtering, controls can begin to overlap. That leads to one of the worst possible spreadsheet UI failures: You click the checkbox you can see, but another checkbox receives the click. For a workbook containing hundreds or thousands of rows, this makes the controls unreliable. “Just use .Placement = xlMoveAndSize” That was the obvious first solution. Excel VBA defines: xlMoveAndSize as the placement mode where an object moves and resizes with cells. So I tested: myCBX.Placement = xlMoveAndSize and: myCBX.Placement = 1 I also tested placement through the corresponding Shape: ws.Shapes(myCBX.Name).Placement = xlMoveAndSize And through a ShapeRange. And through DrawingObjects. And even the commonly suggested workaround: Group controls → set Group.Placement = xlMoveAndSize → Ungroup None of these recreated the original internal state in Excel 2024 LTSC. The workbook continued to serialize the new controls differently. This matches long-standing Microsoft guidance that Form Control checkboxes do not normally support “Move and size with cells” as an editable option, while ActiveX checkboxes do. And yet — this is the important part — existing legacy Form Control checkboxes in real workbooks can still possess and use that state. The most revealing experiment I then modified the OOXML manually. I took the newly generated workbook and patched the checkbox placement metadata to match the working legacy controls: moveWithCells="1" sizeWithCells="1" with proper two-cell anchoring and without the one-cell override. Then I reopened the workbook in Excel 2024 LTSC. And it worked. Immediately. No custom VBA reposition engine. No ActiveX. No workaround running continuously. The same Excel installation that would not create this state through VBA had absolutely no problem: - reading it, - displaying it, - saving it, - resizing the controls with rows, - and filtering them correctly. That is the key finding. The Excel rendering and file engines still fully understand this checkbox state. The missing part is the supported creation path. So is this an unsupported feature or a compatibility regression? Microsoft has historically documented Form Control checkboxes as not supporting “Move and size with cells” in the normal UI. That makes the situation unusual. The issue is not simply: “Excel removed a documented checkbox feature.” The stronger and more accurate statement is: Excel supports a legacy Form Control state in existing workbooks, continues to execute it correctly, but no longer provides an ordinary supported mechanism to reproduce that same state for a replacement control. For users maintaining long-lived Excel systems, the difference is academic. If an old control is accidentally deleted, replacing it with an apparently identical Form Control changes the behaviour of the workbook. That is a backward-compatibility problem. Why not switch to ActiveX? ActiveX checkboxes support richer placement behaviour. But that creates another problem. Microsoft now disables ActiveX controls by default in Microsoft 365 and Office 2024 for security reasons. When ActiveX is disabled, users cannot create new ActiveX objects or interact with existing ones. So the official alternatives are hardly attractive: Legacy Form Controls Lightweight and reliable — but cannot reproduce this legacy placement state normally. ActiveX Supports more control behaviour — but is now a legacy security-sensitive technology disabled by default in current Office. New in-cell checkboxes Architecturally much better — because the checkbox is part of the cell and represents TRUE/FALSE. But Microsoft’s own documentation currently lists the feature for: - Excel for Microsoft 365 - Excel for Microsoft 365 for Mac not Excel 2024 LTSC. That leaves perpetual Office users in an uncomfortable middle ground. This is where the product story becomes difficult to defend I am not claiming that Microsoft intentionally removed this behaviour in order to sell subscriptions. There is no evidence for that claim. But the resulting user experience is still hard to justify: 1. Excel can execute the legacy checkbox behaviour. 2. Excel can preserve it. 3. Excel can save it. 4. Excel accepts a manually patched workbook containing it. 5. Excel’s current object model does not provide a reliable way to recreate it. 6. The modern replacement — native in-cell checkboxes — is documented for Microsoft 365 rather than Excel 2024 LTSC. 7. The other legacy alternative, ActiveX, is now disabled by default for security reasons. For users maintaining mature Excel applications, this is a poor migration path. Why this matters beyond checkboxes This is not really a story about one checkbox property. It is about the contract users expect from long-lived productivity software. Excel workbooks are often not disposable documents. They can be: - product-management systems, - pricing tools, - engineering calculators, - operational forms, - purchasing systems, - inventory tools, - reporting applications, - or business processes maintained for ten or twenty years. When Excel continues to support the execution of an old document feature but silently prevents users from recreating an equivalent object, maintaining those systems becomes unnecessarily difficult. Backward compatibility should mean more than: “The file still opens.” It should also mean: “A user can maintain the workbook without reverse-engineering its OOXML package.” What Microsoft could do There are several reasonable fixes. Option 1 — Restore proper placement support Allow: CheckBox.Placement = xlMoveAndSize to generate the same placement state that Excel already understands for legacy controls. Option 2 — Expose the existing capability If the engine already supports it, expose “Move and size with cells” again for Form Control checkboxes. Option 3 — Provide a migration path Make the new in-cell checkbox functionality available to perpetual Excel releases as well, or provide an official conversion tool from legacy Form Controls to cell checkboxes. Option 4 — At minimum, document the limitation If this legacy state is intentionally read-only for compatibility, document it clearly. Currently, a user can spend hours debugging VBA without realizing that two visually identical Form Control checkboxes can have fundamentally different internal placement semantics. A workaround exists — but users should not need it The workaround I eventually used was to modify the .xlsm OOXML package so that newly generated controls use the same anchor metadata as the working legacy controls. That solved the problem immediately. But manually patching Office XML should not be necessary to restore behaviour that Excel itself already supports. It is a useful proof of concept. It is not an acceptable product-level solution. The reproducible evidence I have retained minimal A/B test workbooks demonstrating the problem: OLD Original Form Control checkboxes with correct legacy placement. NEW The same workbook after deleting and recreating the controls. The differences can be reproduced and inspected directly in the workbook OOXML. I would be happy to provide the files to Microsoft Excel engineering. Final thought Excel’s reputation was built partly on extraordinary backward compatibility. That is why companies still trust .xls and .xlsx files created years — sometimes decades — ago. This case shows an uncomfortable edge of that compatibility: Excel remembers how to use an old feature, but appears to have forgotten how to create it. When the workaround is to unzip an .xlsm, manually alter OOXML placement records, rebuild the package and reopen it in Excel — and Excel then works perfectly — it is difficult to argue that the capability itself is gone. The engine still knows how. The user simply no longer has a supported button or VBA path to ask for it. Microsoft, please give that capability back — or provide a proper migration path. Sources Microsoft documentation for native cell-based checkboxes: https://support.microsoft.com/en-us/excel/using-check-boxes-in-excel Microsoft-hosted discussion on Form Control checkbox limitations: https://learn.microsoft.com/en-us/answers/questions/4813119/is-there-a-way-to-assign-a-checkbox-to-a-cell Microsoft documentation on ActiveX controls being disabled by default: https://support.microsoft.com/en-us/office/vba/activex-controls-are-disabled-by-default-in-microsoft-365-and-office-2024Excel x64/VBE event entry loses execute permission in the default segment heap
Excel x64/VBE event entry loses execute permission in the default segment heap; reproduced after Office update Please route to the Office VBA runtime team and Windows heap team. We need a supported runtime fix or deployment workaround, not DEP/ASLR disablement or VBA page-permission patching. Environment: Windows 11 Pro 25H2 build 26200.9457; ntdll 10.0.26100.9278. Excel x64 16.0.20430.20140 updated through official Click-to-Run to 16.0.20430.20146. VBE7.DLL remains 7.1.11.58, unchanged SHA256; Microsoft signatures Valid. Retail Office 2021 + Project 2024. No heap override or disabled mitigations. A fresh native blank workbook (15 blank sheets, counters/empty document-method bodies) plus ordinary GetProcessHeap/HeapAlloc/HeapFree DATA allocations reproduces the same execute AV seen in our business workbook. No PMS business implementation, save/protection logic, project data, license logic, userform, custom executable buffers or permission-writing APIs are present in the minimal fixture. After the update, the SAME isolated repro ran with CDB attached. All generated VBE entries were initially executable. A paired entry/return of the SAME NtAllocateVirtualMemoryEx call recorded base 0x1b8ef147000, size 0x3c000, MEM_COMMIT, PAGE_READWRITE. The live VBE entry page 0x1b8ef166000 changed from protection 0x40 to 0x04. !heap -x confirmed the allocation was still LFH Allocated (requested 4144, block 4352), with entry bytes intact. A normal Worksheets.Add then delivered Workbook_NewSheet and faulted at 0x1b8ef166dc4: C0000005, Parameter[0]=8. Stack includes DispCallFuncAmd64, VBE7 EpiInvokeMethod and EVENT_SINK_Invoke. The permission-change stack is RtlAllocateHeap -> LFH subsegment reformat -> SegLfhVsCommit -> SegPageRangeCommit -> SegMgrCommit -> NtAllocateVirtualMemoryEx. An earlier minimal run and the original/freshly rebuilt business project also showed this mechanism. Rebuilding VBA compilation state did not remove it. Traditional-heap business/save smoke acceptance passed, but that is not a portable commercial fix. Limitations: the compact fixture has reproduced with CDB attached; two no-debugger minimal runs were negative. We do not claim universal impact or an already accepted Microsoft bug. Heap documentation warns against executable permission changes on heap allocations, so ownership of the VBE/heap interaction requires vendor assessment. Reviewed minimal workbooks/source and sanitized paired traces are available in a small technical package. No real project, license credentials, private keys, Microsoft DLLs or full dump will be uploaded. Please advise: (1) supported VBE allocation/protection behavior; (2) serviced runtime/Windows build fixing this precise mechanism; (3) supported administrator-deployable mitigation pending servicing; (4) private upload/case route for the minimal evidence. The latest Office update was tested and still reproduces. https://1drv.ms/u/c/1644b30db0d6b1af/IQBeYS8AqSSGQrK18Grn-wSIAfaKRoioKUlgAWOSZILSR9k?e=GztbpL
Security risk - Microsoft has blocked macros
Hello. I have used 3 different macro spreadsheets from a developer through upwork for over a year with no problems. Last week I can no longer open the files. It comes up with a pick security risk - Microsoft has blocked macros from running because the source of this file is untrusted. I deleted a recent Microsoft update which I think caused the problem. I then redownloaded the files from upwork and was able to tick the unblock box through preferences. I was then able to use the files. Today however the warning has come up again and I can no longer use the files. I need to be able to use them for my work ASAP. Please help me.
Enabling Office 2021 Excel Macros on a Mac
I just installed Office Home & Student on my Mac. An existing worksheet macro will not run. Upon opening the worksheet, I was prompted, as with the previous Excel version, to enable or disable the worksheet macros. The enable button doesn't seem to work as in the past. The new version of Office Excel for Macs is 16.55
Publisher ExportAsFixedFormat ignores “Publication Page” while manual PDF/XPS export works
I am migrating a large archive of Microsoft Publisher files to PDF before Publisher is retired. We have isolated a repeatable problem in older publications. Example publication: Publisher page size: 210 x 148 mm, landscape • Manual export through File → Export → Create PDF/XPS → Options → Print Options • Settings shown by Publisher: • One page per sheet • Paper size: Publication Page • 210 x 148 mm • Landscape • Resulting PDF: 210 x 148 mm — correct However, both PowerShell/COM and VBA using Document.ExportAsFixedFormat produce a 215.9 x 279.4 mm portrait PDF. Explicitly using: PrintStyle:=pbPrintStyleOnePagePerSheet does not fix the problem. We tested the same publication using: Application.CommandBars.ExecuteMso "FileSaveAsPdfOrXps" This opens Publisher’s own PDF/XPS dialog. The dialog still shows Publication Page, 210 x 148 mm, landscape, and when published through that UI the resulting PDF is correct. We analysed 349 Publisher files: •120 exported with the correct page size • 229 exported with the wrong page size • all 229 failing files opened with an Adobe PDF / A4 portrait printer context The Publisher PageSetup.PageWidth and PageHeight values themselves remain correct. Question: Is there any documented or undocumented Publisher VBA/COM property, parameter, registry setting, or command that corresponds specifically to the PDF/XPS Print Options setting “Paper size: Publication Page”? In other words, how can ExportAsFixedFormat be made to reproduce exactly the same page-size behaviour as Publisher’s interactive PDF/XPS dialog? If this is not exposed through the Publisher object model, is automating the built-in FileSaveAsPdfOrXps command the only reliable approach? Publisher: Microsoft 365 desktop version on Windows.Macro buttons not working
Hi, when I try to run a macro using its buttons, the buttons do not respond, animate, or function. Often a box will hover above the button containing its text, and when I am able to click on the box the macro runs; however, the buttons themselves are completely non-responsive. I can run macros successfully from the quickaccess toolbar.