DISP_E_BADINDEX exception in ExcelComAddInHelper

[Sebastien Cadorel]

Hello,

After a few days of usage, the addin ribbon cannot be loaded anymore (it is not disabled).

COMException with DISP_E_BADINDEX error occurred in ExcelComAddInHelper.LoadComAddIn around the line:

comAddIn = excelComAddIns.GetType().InvokeMember("Item", BindingFlags.InvokeMethod, null, excelComAddIns, new object[] { progId }, ci);

When looking at the list of items, all exceldna addins are not present.

Full callstack:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException: Invalid index. (Exception from HRESULT: 0x8002000B (DISP_E_BADINDEX))
   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
   at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture)
   at ExcelDna.Integration.ExcelComAddInHelper.LoadComAddIn(ExcelComAddIn addIn)

This is the exact same exception described at https://groups.google.com/forum/#!msg/exceldna/FzkZz9giA4M/mTNkqLSPP1MJ.

It happen on one of our client using Office 2013 x86 on Windows 8.1 x64 and only happen after a few days of usage.

User does not have administrative rights, thus the registration is done in HKCU. UAC is enabled.

We use the latest version of ExcelDNA (currently 0.33.9).

Rebooting the computer fix the issue but it occurred again after a few days.

I've tried all workaround described on those two articles but unfortunately none of them fixed the issue.

https://groups.google.com/forum/#!msg/exceldna/FzkZz9giA4M/mTNkqLSPP1MJ

https://groups.google.com/forum/#!searchin/exceldna/DISP_E_BADINDEX/exceldna/P2L0kYJg2xk/RuaYyKQhBdsJ

I’ve also made some registry traces (ProcessMonitor) before and after the issue and it appear that at some point, the key is not registered at the same place, resulting in a NOT_FOUND when excel tries to read it back.

Working:

Process Name Operation Path Result Detail
EXCEL.EXE RegOpenKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672\Software\Classes\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\CLSID REPARSE Desired Access: Read/Write
EXCEL.EXE RegOpenKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672_CLASSES\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\CLSID NAME NOT FOUND Desired Access: Read/Write
EXCEL.EXE RegCreateKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672\Software\Classes\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\CLSID REPARSE Desired Access: Read/Write
EXCEL.EXE RegCreateKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672_CLASSES\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\CLSID NAME NOT FOUND Desired Access: Read/Write
EXCEL.EXE RegCreateKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672_CLASSES\Dna.4c9ad8da6aa653248b7340f81c7832a8.0 SUCCESS Desired Access: Maximum Allowed, Granted Access: None 0x0, Disposition: REG_CREATED_NEW_KEY
EXCEL.EXE RegOpenKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672_CLASSES\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\Clsid SUCCESS Desired Access: Query Value

Not working:

Process Name Operation Path Result Detail
EXCEL.EXE RegOpenKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672\Software\Classes\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\CLSID NAME NOT FOUND Desired Access: Read/Write
EXCEL.EXE RegCreateKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672\Software\Classes\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\CLSID NAME NOT FOUND Desired Access: Read/Write
EXCEL.EXE RegCreateKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672\Software\Classes\Dna.4c9ad8da6aa653248b7340f81c7832a8.0 SUCCESS Desired Access: Maximum Allowed, Granted Access: None 0x0, Disposition: REG_CREATED_NEW_KEY
EXCEL.EXE RegOpenKey HKU\S-1-5-21-337817132-3591569431-2285286604-1672_CLASSES\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\Clsid NAME NOT FOUND Desired Access: Query Value
EXCEL.EXE RegOpenKey HKCR\Dna.4c9ad8da6aa653248b7340f81c7832a8.0\Clsid NAME NOT FOUND Desired Access: Query Value

Difference between 1st and 2nd is the REPARSE missing and the fact that it is written in SID_CLASSES instead of Software\Classes.

As a workaround, in ComRegistration.cs, in “public static RegistryKey ClassesRootKey”, I’ve changed

Registry.CurrentUser.CreateSubKey(@"Software\Classes", RegistryKeyPermissionCheck.ReadWriteSubTree);

to

Registry.Users.CreateSubKey(WindowsIdentity.GetCurrent().User + "_CLASSES", RegistryKeyPermissionCheck.ReadWriteSubTree);

to force the same path as excel and the addin is not disabled anymore. However, not sure it is safe to do that.

Any ideas?

Thanks.

Best regards,

Sebastien

[Govert van Drimmelen]

Hi Sebastien,

 

Thank you very much for your detailed investigation!

I’ll have a closer look at what you’ve found, and your suggested fix.

 

-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 post to this group, send email to exce...@googlegroups.com.
Visit this group at https://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.

[Sebastien Cadorel]

Hi Govert,

Thanks.

Don't hesitate to ask if you need more information.

Best regards,

Sebastien

[Randy Qian]

I'm experiencing something similar. Again. :-/ I wonder why this registry address reference becomes a moving target once in a while.

[Randy Qian]

I was able to address the issue by replacing all HKCU references with

HKU\<SID>

references or

HKU\<SID>+"_CLASSES"

as appropriate. This second case is used as Sebastien described, when replacing paths with the prefix HKCU\Software\Classes.

In the past I fixed this issue by using process monitor and searching in the code for the specific registry paths that screwed up and doing the first replacement above; it seems that this new issue was caused by some different registry path not using the <SID> hardened paths that started screwing up recently and this was fixed by case 2 described above.

I think HKCU is an unreliable reference for some reason, I have no idea why. Maybe it's some unforeseen behavior of windows patches or av software.

[Govert van Drimmelen]

Thanks Randy,

When we discussed this in August, I was a bit nervous about implementing the changes just before a release.

Now is a good time to try to fix this.

Would either of you like to make a Pull Request on GitHub for this?

Otherwise I am happy to do it, too.

-Govert

[Randy Qian]

Would be happy to give it a shot. I'll clean up my code and test it on my end first. I'll do a pull once I'm satisfied.

-Randy

[Govert van Drimmelen]

Great - thank you!

-Govert

---

From: exce...@googlegroups.com [exce...@googlegroups.com] on behalf of Randy Qian [rand...@gmail.com]
Sent: 21 March 2016 11:29 PM
To: Excel-DNA
Subject: Re: [ExcelDna] DISP_E_BADINDEX exception in ExcelComAddInHelper

[Sebastien Cadorel]

Thank you for the PR and the fix. :)

Great - thank you!

-Govert

To post to this group, send email to exc...@googlegroups.com.