fsarre, your report is different from the one this thread started with, and the difference matters, so it is worth separating the two.
The original issue here was a crash on
any Windows file dialog, Save As and Insert Image alike, and it was traced to Norton's behavioural protection. Yours is narrower: saving crashes, inserting an image does not. That single detail points away from the Windows file dialog itself and towards the secure save path. Two further things you describe support that: it reproduces on a fresh empty workbook with no data and no VBA, so nothing in your own file is involved, and it behaves identically on 2025.2 and 2026.1.
We have one other reproducible report of a save crash on a blank workbook, and 2026.1 does include a change aimed at what we believed was the trigger. The fact that your crash is unchanged between 2025.2 and 2026.1 tells us that change does not cover your case, so rather than guess, we need to pin down where exactly the save fails on your machine. Could you post the following:
- When you save, does the "Save local workbook" dialog box actually appear before the crash? If it does: does the crash happen the instant it opens, while you browse folders, or only after you click Save? And does the dialog look like the modern Windows dialog (folder tree pane on the left) or like the classic, simpler one? That last detail tells us which internal path your build is taking, so please mention it either way.
- The crash entry from the Windows Event Viewer: Windows Logs, then Application, look for Event ID 1000 ("Application Error") for EXCEL.EXE at the time of the crash, and paste the whole entry, especially the "Faulting module name" and the exception code. This is the single most useful piece of information you can give us.
- After reproducing the crash with a 2026.1 build, press Win+R, type
%APPDATA%\XLSPadlock and look inside the folder named after your application for a runtime.log file. If it exists, attach it even if it looks almost empty (its absence is also useful information, so tell us either way).
- Rebuild the same blank workbook with the wizard option "Save changes automatically and load them without prompt next time" (Application Settings, save options) enabled, so that saving happens with no dialog at all. Does it still crash? This tells us whether the dialog is involved at all.
- Try giving the save dialog a valid default file path from VBA before the user saves, pointed at a simple local folder that certainly exists and is writable (plain local drive, not OneDrive or a network path):
Code:
Public Sub SetSecureWorkbookFilename(Filename As String)
Dim XLSPadlock As Object
On Error Resume Next
Set XLSPadlock = Application.COMAddIns("GXLS.GXLSPLock").Object
If Not XLSPadlock Is Nothing Then
XLSPadlock.SetDefaultSaveFilename Filename
End If
End Sub
' e.g. Call SetSecureWorkbookFilename("C:\Temp\mysave.xlsc")
- Your Windows version and build (Win+R,
winver), and your Excel version, update channel and bitness, 32-bit or 64-bit (File, Account, About Excel).
- Where is the compiled EXE when it crashes: Desktop, Documents, a OneDrive-synced folder, a network drive? Does it also crash when you copy it to a plain local folder such as
C:\Test and run it from there?
- When the crash happens, does Excel itself close (the Windows "Excel has stopped working" dialog), or does the compiled application close and leave Excel running?
One correction on the antivirus side, since it affects what your test actually proved. Turning Norton off through its interface does not unload its drivers and filter hooks, so a "disabled" Norton can still intercept the process; whitelisting has the same limitation, it changes scanning decisions, not whether the hooks are loaded. The only conclusive test is a temporary full uninstall, then reboot, then reproduce. Given your results so far we do not think Norton is the most likely cause, but please keep this in mind if we run out of other leads.
If you prefer, you can also open a support ticket and send us your project file and the compiled EXE. Reproducing with your exact configuration on our side is often faster than a long list of questions.
