Exceldna v1.7 excel crash

[Suki Gill]

Hi 

I’ve been using exceldna v1.6 on .net core 6.x for about a year.

I’ve just switched to v1.7 and noticed Excel crashing. They symptom it freezes for about 5s and then aborts the entire excel.exe process.

I found the following entry in event viewer.

CoreCLR Version: 6.0.2223.42425

.NET Version: 6.0.22

Description: The application requested process termination through System.Environment.FailFast(string message).

Message: A callback was made on a garbage collected delegate of type 'ExcelDna.IntelliSense!ExcelDna.IntelliSense.WinEventHook+WinEventDelegate::Invoke'.

Stack:

Any hints on how to best debug the issue?

Many thanks

[Govert van Drimmelen]

Hi Suki,

 

Thank you – that’s a very useful crash report.

We indeed made changes in the IntelliSense in version 1.7, exactly around the place you point to.

I can’t see a potential bug immediately, but will keep looking.

 

Are you able to reproduce this in a simple add-in that I could test?

 

-Govert

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/3ca3f9e1-3f69-4295-9f10-9d5e30aaabbfn%40googlegroups.com.

[Govert van Drimmelen]

OK, I managed to reproduce this once while debugging:

[Govert van Drimmelen]

Hi Suki,

After the first time, I've not been able to reproduce the error, even with some poking at the code to e.g. trigger the garbage collection more often. 

If I change the code, I can get the error in expected ways, but can't see the problem execution path in the current code yet.

Can you give some indication of whether your add-in is doing anything like opening and closing or creating and remove workbooks or sheets while it is running?

I'm wondering whether programmatic changes like that might mean the IntelliSense code misses some expected events.

Otherwise, I'll keep trying more, and will let you know if I can come up with a better debugging plan that you can do on your side.

-Govert

[Eduardo Martinez-Lopez]

Hi Govert,

I am seeing this exact same issue occur reliably on one particular client's machine. The exact same message is in the Event Viewer after Excel crashes, with only the .NET version numbers differing. I am using exceldna v1.9 with .NET 9.x. I am not able to reproduce the issue on my own machine, even when I work with the exact same workbook and files as the client. The issue occurs equally on 32-bit excel with x86 .NET runtime and with 64-bit Excel with the corresponding 64-bit version of the add-in.

If you have any more ideas for debugging this issue, please do share. Unfortunately being unable to reproduce the issue locally limits my options here but it may be helpful to use my client's machine that reliably demonstrates the issue as a testbed to sort this out.

[Eduardo Martinez-Lopez]

Hi Govert,

I'm following up to inform you that upon further investigation, I was finally able to isolate the cause of the issue and reproduce it reliably + resolve it for my case. In my case, this error occurred due to the add-in being registered duplicately in the registry, 

In the migration from .NET Framework to .NET 6+, I had to change the code I used to install my add-in on my clients' machines due to loss of access to some of the COM methods that were available in Framework for this. Per AI suggestion, the new method is to directly modify the user's registry keys (HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\options: OPEN, OPEN1,OPEN2, etc.) . The new code neglected to check whether the add-in was already on this list, so when the installation script was run again to update it, my add-in was added again, so that both OPEN and OPEN1 subkeys pointed to it. Once this happens, any use of the add-in will reliably crash Excel with the error above.

I'm guessing there's not much can be done to prevent this behavior once we get into that state, but it would be useful to somehow be able to detect this state and provide a more useful error message to the user? It certainly would have saved me some headaches trying to debug it.