Compiled XLS Padlock EXE closes when Windows file dialog opens (Save As / Insert Image)

L

lucho-0512

New member
Hello, I have a problem where when a user tries to save the file, as soon as the Windows file explorer dialog opens, the compiled .exe file created with XLS Padlock closes. The same thing happens when they try to insert images — when the Windows file explorer opens to select the image, the application closes as well. It seems the conflict occurs specifically when the Windows explorer dialog is opened. We disabled the antivirus and the issue still happens. It does not happen on my machine — it only happens to one of my clients. I saw in this forum that this issue has been reported since 2019. Is there any solution or recommended action to fix this?
 
I had the same problem with a customer in 2025 and it was at the end the NORTON anti-virus protection. Never understood why though.
 
Thanks for sharing this data point! We've seen similar file-dialog crashes pinned on Norton's behavioral/exploit protection intercepting the Excel process when the Windows common dialog is spawned from inside a protected EXE.

For anyone hitting this in the future, the usual fixes on the Norton side are:

  • Add the compiled EXE (and the XLS Padlock secured workbook folder) to Norton's exclusion/allow list, including the Auto-Protect, SONAR / Behavioral Protection, and Data Protector exclusions
  • Disable (or whitelist) Norton's "Exploit Prevention" / "Proactive Exploit Protection" for the EXE
  • Code-sign the EXE (see https://www.xlspadlock.com/doc/code-sign-your-exe-file-digital-signature) — a signed binary is much less likely to be flagged by heuristic/behavioral AV engines
Code signing + an AV exclusion is the combination that resolves this in most cases we've seen.
 
I have the same issue. When I try to save an XLSC file, Excel crashes. If I try to insert an image, no problem.
I disabled Norton 360, included XLS Padlock, the compiled EXE file, and Excel in the "Add Permissions" (whitelist) and recompiled the spreadsheet file and got the same issue. It happens even when I compile a fresh, empty spreadsheet with no information or VBA code.
I thought it was the XLS Padlock version (I have 2025.2), so I downloaded the 2026.1 trial version, but it didn't resolve the issue.
 
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.
 
Thank you for your prompt response. By sequence:

Yes, the dialog box actually always appears for 5 to 10 seconds before the crash; during that time I can't select a folder or the box to name the file. Every option in the dialog box is frozen. The crash happens with no message. The dialog looks like the classic, simpler one with folders on the left and files on the right. The 2026.1 version displays a nicer one, but the issue behaves the same.

Windows does record an event ID 1000.
Faulting application name: excel.exe, version: 16.0.20131.20154, time stamp: 0x6a55133b
Faulting module name: AppVIsvSubsystems64.dll, version: 16.0.20131.20012, time stamp: 0x6a21335f
Exception code: 0xc0000005
Fault offset: 0x00000000000b3a4b
Faulting process id: 0x5F50
Faulting application start time: 0x1DD189C045AE796
Faulting application path: C:\Program Files\Microsoft Office\root\Office16\excel.exe
Faulting module path: C:\Program Files\Microsoft Office\root\Office16\AppVIsvSubsystems64.dll
Report Id: 7668360d-8ef5-43be-8664-998c38c81dea
Faulting package full name:
Faulting package-relative application ID:

The runtime.log file is absent.

Rebuilding the blank workbook with the option "Save changes automatically and load them without prompt next time" does not crash. Works well.

The default file path is "Documents" and I disconnected all Claude drives, thinking it could be hanging due to some timeout. Anyway, I included the VBA, rebuilt the file, and got the same results.

Windows version 11, version 25h2 (OS Build 26200.8894)

Excel Version Home and Student 2021

The compiled EXE is in the Documents folder. Everything is done in this folder to simplify. I don't have any network policy restrictions, as this is an isolated computer.

When the crash happens, the EXE file and Excel close with no warning. When I reopen any Excel sheet, it asks me if I want to open it in safe mode.

"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."

Yes, I was aware of this, and I'm very much convinced that the issue is Norton interference. I took the empty compiled file to a friend's computer with a different antivirus, and it worked well.
Not only did I disable Norton, but I also disabled "Block vulnerable kernel drivers".

Since I will be selling my compiled spreadsheet next month, I need to find a workaround for this issue with Norton 360, or else, I will be very busy dealing with unhappy customers.

Thank you.
 
fsarre, the Event Viewer entry you posted is the decisive piece, thank you for it. It changes where this needs to be looked at.

The faulting module is AppVIsvSubsystems64.dll, with exception code 0xc0000005, an access violation. That DLL is not part of XLS Padlock, and it is not a Norton driver. It belongs to Microsoft Office itself: it is a component of Office's Click-to-Run virtualization layer (the same App-V-based technology that packages modern Office). So what actually crashes is a piece of Office, inside excel.exe, at the moment the save dialog does its work. Two of your own results line up with that: your runtime.log is absent, meaning XLS Padlock's own code caught nothing and the fault is downstream of it, and a Norton kernel driver crashing the process would show up as a Symantec module here, not an Office one.

That also puts your Norton conclusion in a more precise light. Your test on a friend's PC proves the problem is specific to this machine's environment, which is real and useful, but it does not by itself prove Norton is the cause: your friend's Office may be a different build or update channel that does not carry this fault. I am not ruling Norton out, its behavioural protection does inject into excel.exe and can destabilise exactly this kind of component, but the module that faulted is Office's, so that is where I would look first. If you do want to settle the Norton question definitively, the only conclusive test remains a temporary full uninstall of Norton followed by a reboot, then reproduce, because disabling and whitelisting leave its hooks loaded.

Now the part that matters for your launch next month, because you already found the answer without realising it. You reported that rebuilding with "Save changes automatically and load them without prompt next time" does not crash. That is not a coincidence: in that mode no browse dialog is ever shown, so the code path that faults is never entered. If that save behaviour fits how you want your product to work, it is a perfectly legitimate way to ship, and it takes the crash off the table entirely while the underlying Office issue is dealt with separately. That is your safety net for the deadline.

To actually repair the machine, target Office rather than XLS Padlock:

  • Run an Online Repair of Office (Settings, Apps, Microsoft Office, Modify, Online Repair). This is Microsoft's own remedy for an access violation in AppVIsvSubsystems64.dll, and it rebuilds the virtualization component that faulted.
  • Update Office fully afterwards. Your Excel build is 16.0.20131.20154; a corrupted or outdated virtualization subsystem is exactly what Online Repair plus a full update fixes.
  • Tell us whether this Excel is the Microsoft Store version of Office or the regular Click-to-Run installer version. Home and Student 2021 ships both ways, and the Store packaging leans more heavily on this virtualization layer. If it is the Store version, installing the standard Click-to-Run build instead is worth trying.
Two last things that would help us reproduce it here, since we would need to match your setup rather than a plain machine:

  • Look again, carefully, at the save dialog in your 2026.1 build. You wrote that 2026.1 shows a "nicer" dialog than 2025.2. That is important, because in 2026.1 we deliberately switched the secure-save dialog to the older, plainer style precisely to avoid this class of crash. If what you see in 2026.1 is the modern dialog with a folder tree pane on the left, then your crash is coming through a path our change did not cover, and that tells us something specific. So please confirm which of the two styles the 2026.1 build actually shows when it hangs.
  • If you are willing, open a support ticket and attach your project file and the compiled EXE. With your Office build identified, reproducing it against a matching Office install on our side is the fastest route to a real fix rather than a workaround.
 
So in a nutshell, this is what I did,

I ran sfc / scannow from an elevated command prompt and then DISM /Online /Cleanup-Image / RestoreHealth to fully fix Excel.
It identified corrupted files and fixed them. Rebuilt the empty no VBA Excel file with XLS Padlock 2025.2. The issue subsisted. Rebuild the file with version 2026.1. The issue remained.

Next, I uninstalled Norton 360, restarted, and tested with both the XLS Pad version. The issue went away on both versions.

My Excel is the desktop version. Product link: https://apps.microsoft.com/detail/CFQ7TTC0H8N8?hl=en-US&gl=US&ocid=pdpshare

When I mention that the 2026.1 version shows a "nicer" dialog box, I mean that on the left it doesn't show folders; it shows icons.

How can I open a support ticket?

Thank you for all your help.
 
Thank you for coming back with real test results rather than impressions!

Your two tests together are conclusive. You uninstalled Norton, rebooted, and the crash disappeared on both. That is the test that actually proves something, and it means Norton is the trigger. Your instinct was right from the start.

That said, the Event Viewer entry was not misleading, and the two facts fit together rather than contradicting each other. Norton injects itself into excel.exe. The component that gives way under that injection is Office's, which is why the faulting module is AppVIsvSubsystems64.dll and not a Symantec one. Norton is the cause, Office's virtualization layer is the casualty. That single picture explains everything you observed: why your friend's machine with a different antivirus was fine, why disabling and whitelisting changed nothing while uninstalling changed everything, since those hooks stay loaded as long as the product is installed, and why repairing Office could not help, because nothing was broken in Office to begin with.

One detail worth noting: the link you posted is the Microsoft Store listing, so your Excel is the Store-packaged build. It is the same desktop Excel, but that packaging is the one that leans hardest on the virtualization layer that faulted. That is very likely why this combination breaks on your machine and not everywhere.

Now the part that matters for selling next month, since you cannot ask your customers to uninstall their antivirus.

The measure we would put first is code signing your compiled application. Earlier in this thread, signing plus an exclusion is what resolved this same Norton behaviour for another user. We want to be straight with you about what it does and does not do: signing will not switch off Norton's behavioural engine, so it is not a guarantee. But publisher reputation is a heavy input into how aggressively that engine treats a process, and an unsigned freshly built executable that hosts Excel is close to the worst profile you can present to it. You also need signing anyway to sell without SmartScreen warnings scaring off your buyers, so it is not effort spent only on this problem.

There is a free way to get most of that benefit immediately, before buying anything. In the distribution options, choose the EXE plus XPLAPP Application Bundle format instead of a single standalone executable. In that format the main launcher is already signed by us, so your application presents a valid signature without you purchasing a certificate. You distribute the resulting files together. Your own certificate remains the stronger option later, since then the signature carries your name, but the bundle costs nothing and you can test it today.

Your second lever is the one you already found yourself. You confirmed that rebuilding with "Save changes automatically and load them without prompt next time" does not crash, because no browse dialog is ever shown and the failing path is never entered. If that save behaviour suits your product, shipping that way removes this crash from your launch entirely, whatever antivirus your customers run. Given your deadline, I would treat that as the decision to make first and the signing as what you do in parallel.

There is a third avenue worth five minutes, even though I want to be careful not to oversell it. You did try the SetDefaultSaveFilename snippet and reported no change, but you also said your default file path was Documents. On Windows 11 that is one of the worst possible choices for this: it is a shell-heavy location and it is frequently redirected to OneDrive without the user ever being asked. Another customer with a similar crash, from a completely different cause, resolved his by pointing that call at a plain, ordinary local folder that no sync client and no shell extension manages, something like C:\YourApp\Data rather than Documents or Desktop. There is one trap to know about: the call only takes effect if the folder already exists, so create it first from your VBA before calling it, otherwise it silently does nothing and the dialog opens wherever the shell decides. Given that removing Norton is what actually fixed your machine, we would not expect this to be the whole answer for you, but it is cheap to test and it costs you nothing to have your application always point somewhere dull and local.

For the occasional customer who still reports it, the exclusions that matter in Norton are not the plain file exclusions. They are the SONAR and behavioural protection exclusions plus Proactive Exploit Protection, and the only way to confirm Norton is involved on their machine is a temporary uninstall and reboot, exactly as you did.

There is one more thing you can do: you are a Norton customer with a valid license, which means you have access to their technical support. We do not. A crash report coming from a paying subscriber carries considerably more weight with them, and it is the kind of report their support desk will escalate to their own developers. You have an unusually strong case to hand them, because you already did the work: a reproducible crash on a blank Excel workbook, the Event Viewer entry naming AppVIsvSubsystems64.dll with exception 0xc0000005, no crash on a machine with a different antivirus, and the crash disappearing the moment Norton 360 is uninstalled and reappearing when it is reinstalled. That is a cleaner report than most vendors ever receive. If they fix it on their side, it is fixed for every one of your customers at once, which no workaround on our side can achieve.

And to answer your question, you can open a ticket here, no account needed:

https://www.gdgsoft.com/support/ticket

Thanks again!
 
fsarre said:
Thank you for your prompt response. By sequence:

Yes, the dialog box actually always appears for 5 to 10 seconds before the crash; during that time I can't select a folder or the box to name the file. Every option in the dialog box is frozen. The crash happens with no message. The dialog looks like the classic, simpler one with folders on the left and files on the right. The 2026.1 version displays a nicer one, but the issue behaves the same.

Windows does record an event ID 1000.
Faulting application name: excel.exe, version: 16.0.20131.20154, time stamp: 0x6a55133b
Faulting module name: AppVIsvSubsystems64.dll, version: 16.0.20131.20012, time stamp: 0x6a21335f
Exception code: 0xc0000005
Fault offset: 0x00000000000b3a4b
Faulting process id: 0x5F50
Faulting application start time: 0x1DD189C045AE796
Faulting application path: C:\Program Files\Microsoft Office\root\Office16\excel.exe
Faulting module path: C:\Program Files\Microsoft Office\root\Office16\AppVIsvSubsystems64.dll
Report Id: 7668360d-8ef5-43be-8664-998c38c81dea
Faulting package full name:
Faulting package-relative application ID:

The runtime.log file is absent.

Rebuilding the blank workbook with the option "Save changes automatically and load them without prompt next time" does not crash. Works well.

The default file path is "Documents" and I disconnected all Claude drives, thinking it could be hanging due to some timeout. Anyway, I included the VBA, rebuilt the file, and got the same results.

Windows version 11, version 25h2 (OS Build 26200.8894)

Excel Version Home and Student 2021

The compiled EXE is in the Documents folder. Everything is done in this folder to simplify. I don't have any network policy restrictions, as this is an isolated computer.

When the crash happens, the EXE file and Excel close with no warning. When I reopen any Excel sheet, it asks me if I want to open it in safe mode.

"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."

Yes, I was aware of this, and I'm very much convinced that the issue is Norton interference. I took the empty compiled file to a friend's computer with a different antivirus, and it worked well.
Not only did I disable Norton, but I also disabled "Block vulnerable kernel drivers".

Since I will be selling my compiled spreadsheet next month, I need to find a workaround for this issue with Norton 360, or else, I will be very busy dealing with unhappy customers.

Thank you.
Click to expand...
I've gotten the same crash but it is intermittent, I don't use Nortons, and no client has reported it. Will attempt to reproduce, check event logs, and reply if I can find something substantive.
 
gdgsupport said:
Thank you for coming back with real test results rather than impressions!

Your two tests together are conclusive. You uninstalled Norton, rebooted, and the crash disappeared on both. That is the test that actually proves something, and it means Norton is the trigger. Your instinct was right from the start.

That said, the Event Viewer entry was not misleading, and the two facts fit together rather than contradicting each other. Norton injects itself into excel.exe. The component that gives way under that injection is Office's, which is why the faulting module is AppVIsvSubsystems64.dll and not a Symantec one. Norton is the cause, Office's virtualization layer is the casualty. That single picture explains everything you observed: why your friend's machine with a different antivirus was fine, why disabling and whitelisting changed nothing while uninstalling changed everything, since those hooks stay loaded as long as the product is installed, and why repairing Office could not help, because nothing was broken in Office to begin with.

One detail worth noting: the link you posted is the Microsoft Store listing, so your Excel is the Store-packaged build. It is the same desktop Excel, but that packaging is the one that leans hardest on the virtualization layer that faulted. That is very likely why this combination breaks on your machine and not everywhere.

Now the part that matters for selling next month, since you cannot ask your customers to uninstall their antivirus.

The measure we would put first is code signing your compiled application. Earlier in this thread, signing plus an exclusion is what resolved this same Norton behaviour for another user. We want to be straight with you about what it does and does not do: signing will not switch off Norton's behavioural engine, so it is not a guarantee. But publisher reputation is a heavy input into how aggressively that engine treats a process, and an unsigned freshly built executable that hosts Excel is close to the worst profile you can present to it. You also need signing anyway to sell without SmartScreen warnings scaring off your buyers, so it is not effort spent only on this problem.

There is a free way to get most of that benefit immediately, before buying anything. In the distribution options, choose the EXE plus XPLAPP Application Bundle format instead of a single standalone executable. In that format the main launcher is already signed by us, so your application presents a valid signature without you purchasing a certificate. You distribute the resulting files together. Your own certificate remains the stronger option later, since then the signature carries your name, but the bundle costs nothing and you can test it today.

Your second lever is the one you already found yourself. You confirmed that rebuilding with "Save changes automatically and load them without prompt next time" does not crash, because no browse dialog is ever shown and the failing path is never entered. If that save behaviour suits your product, shipping that way removes this crash from your launch entirely, whatever antivirus your customers run. Given your deadline, I would treat that as the decision to make first and the signing as what you do in parallel.

There is a third avenue worth five minutes, even though I want to be careful not to oversell it. You did try the SetDefaultSaveFilename snippet and reported no change, but you also said your default file path was Documents. On Windows 11 that is one of the worst possible choices for this: it is a shell-heavy location and it is frequently redirected to OneDrive without the user ever being asked. Another customer with a similar crash, from a completely different cause, resolved his by pointing that call at a plain, ordinary local folder that no sync client and no shell extension manages, something like C:\YourApp\Data rather than Documents or Desktop. There is one trap to know about: the call only takes effect if the folder already exists, so create it first from your VBA before calling it, otherwise it silently does nothing and the dialog opens wherever the shell decides. Given that removing Norton is what actually fixed your machine, we would not expect this to be the whole answer for you, but it is cheap to test and it costs you nothing to have your application always point somewhere dull and local.

For the occasional customer who still reports it, the exclusions that matter in Norton are not the plain file exclusions. They are the SONAR and behavioural protection exclusions plus Proactive Exploit Protection, and the only way to confirm Norton is involved on their machine is a temporary uninstall and reboot, exactly as you did.

There is one more thing you can do: you are a Norton customer with a valid license, which means you have access to their technical support. We do not. A crash report coming from a paying subscriber carries considerably more weight with them, and it is the kind of report their support desk will escalate to their own developers. You have an unusually strong case to hand them, because you already did the work: a reproducible crash on a blank Excel workbook, the Event Viewer entry naming AppVIsvSubsystems64.dll with exception 0xc0000005, no crash on a machine with a different antivirus, and the crash disappearing the moment Norton 360 is uninstalled and reappearing when it is reinstalled. That is a cleaner report than most vendors ever receive. If they fix it on their side, it is fixed for every one of your customers at once, which no workaround on our side can achieve.

And to answer your question, you can open a ticket here, no account needed:

https://www.gdgsoft.com/support/ticket

Thanks again!
Click to expand...


I've been running tests on XLS Padlock for some time, and definitely I would not recommend using anything different from code signing if someone is trying to sell a professional spreadsheet online with some exceptions, of course.
All my tests were done choosing the EXE plus XPLAPP Application Bundle. So, having said that, the only issue I have encountered is this one on my computer.

Please don't take this as a criticism, but regarding contacting Norton since I have a paid license, I don't think the burden should be on me to improve XLS Padlock, although I can surely help by reporting this issue to Norton customer services, but the biggest effort should come from G.D.G. This is something your team of developers could reach out to Norton's developers to resolve this for all G.D.G. clients. Not only does your team have far more knowledge on how to respond to the Norton developers team, but I'm sure Norton will take it more seriously.

You mentioned having the Documents folder as the default folder is the worst possible choice. I disagree since it's the most intuitive location, especially for users with little literacy on computers. As I said before, I tested the empty file also with no virtual drives connected (completely offline) and got the same result.

Bottom line, although I'm looking for a solution for this problem, I don't want to compromise the quality of what I want to offer to my clients, like saving the XLSC file automatically, where the user has no idea where the file is being saved, or automatically pointing to the default folder different from the Documents folder.

Please, in a summarized sentence, how can I tweak Norton or XLS Padlock to overcome this issue? I understand that it's not that easy, but now that we have hard evidence that Norton antivirus identifies XLS Padlock as a threat, I'll leave this to your team.... Nevertheless, I truly appreciate all the effort and fast responses to my problem.
 
@fsarre: you're right, but as of today there is no setting, on the Norton side or on ours, that removes this while keeping the browse dialog. Every configuration that does not crash is one where the dialog is never shown. Offering you a fourth workaround after you have soundly rejected three would be avoiding your question. Closing this properly is our work, not yours.

Another user, StevegHI, reports the same crash on his machine, intermittently, and he does not use Norton. That changes the picture in a way that is worth stating clearly: this is not purely a Norton problem. It looks like a code path in the save dialog that is fragile whenever a third party is loaded inside the Excel process, and Norton is one trigger among several. We'll look into this. Your case remains the best documented of them, which is exactly why your Event Viewer entry was so useful.

On Norton, you are right, and we are not going to pretend otherwise: it should not fall to you to improve our product. But there is a reason about our query: the vendor channels Norton offers are built around detections. They exist so that a software publisher can say "you are wrongly flagging my file", and they resolve by adjusting definitions. That is not what happens here. Nothing of ours is detected, nothing is quarantined, there is no alert of any kind. What happens is that Norton's behavioural component injects itself into the Excel process and destabilises a Microsoft component inside it. There is no channel for reporting that, and without being a subscriber we have no direct line to open one. Your position as a paying customer genuinely reaches somewhere we cannot, which is the whole reason we raised it. But we are not making it a condition, and we are not waiting on it.

We cannot stop another program from injecting hooks into the Excel process our application runs in. When those hooks bring down a component Office itself depends on, Excel goes down and our application goes with it, and there is no defensive move available to us from the outside. That is the uncomfortable part of this whole class of problem, and it is not specific to us.

What we are doing instead: now that a second person reports the same crash without Norton, we are continuing to work on isolating it. Two independent environments failing the same way is a much better starting point than one, and that work is on us.

Two practical things in the meantime, neither of which asks you to compromise your product.

If a customer does report it, the exclusions that work in Norton are not the plain file exclusions, they are the SONAR and behavioural protection exclusions plus Proactive Exploit Protection. Worth having ready as a support answer rather than as a change to your application.

And StevegHI said he would try to reproduce and check his event logs. If he posts a second Event Viewer entry from a machine without Norton, that would be genuinely valuable, because two crash dumps from two different environments say far more than one.

Thank you again for the quality of your testing on this!
 
You must log in or register to reply here.
Back
Top