Ribbon fails to load

[Paul Hatcher]

Just writing my first Excel-DNA addin and I have a problem where on start up I get...

 

The Ribbon/COM Add-in helper required by add-in xxxx could not be registered

This is an unexpected error

Error message: Exception has been thrown by the target of an invocation

 

This happens even if I use one of the samples or have a minimal ribbon definition...

 

public class MyRibbon : ExcelRibbon
{
}

 

This was working and I can't isolate what made it stop - any ideas?

 

Regards

 

Paul

[Govert van Drimmelen]

Hi Paul,

You should check whether there is anything in the 'Disabled Items' list under File->Options, Add-Ins, Manage ... at the bottom.

A more radical effort to fix it is to remove the add-in registrations in the registry. You can also search on the group for your error message - it does appear from time to time.

If there is an exception thrown by your ribbon code, Excel might mark your add-in as Disabled, and things get messy. But it should not be a problem once it works right.

-Govert

[Paul Hatcher]

Govert

 

Thanks for that - I found the registry key answer a few hours ago and that fixed it

 

I'll check the "Disabled Items" next time it happens

 

Paul

[Beastian]

Hi all,

Is there any update on this issue? I've been getting the exact same message since last Wednesday.

I've looked at the history of this issue and see no clear explanation. I'd rather not take the nuclear option of wiping the entire registry tree for Excel since I've a number of users who would rather keep some of their settings.

I suspect there's something to do w/ windows updates and how windows handles registry permissions. Fiddling with the CustomUIValidation entry and rebooting a machine using the XLL seems to get it working temporarily.

[Beastian]

One more thing, I might also be fighting for Ribbon space with other plugins such as Bloomberg. I'm not entirely sure how and when the ribbon registration code grabs space for the ribbon. Would it be possible to delay this?

[Govert van Drimmelen]

My understanding is that Excel will mark an add-in as disabled, if there are unhandled errors in either the ribbon loading (the GetCustomUI call) or in the ribbon callbacks. Excel-DNA does nothing to wrap these COM calls from Excel into your add-in, so you might like to put exception handlers around these. If you log these exceptions, that might give you an indication of what changes in your environment could have caused errors that lead Excel to disable the add-in.

The one aspect I don't have a good grip on, is the case where an add-in does not load, but does not appear in the Disabled Add-Ins list. This is the case where cleaning up some registry entries fix things, but I don't know exactly what the case is here. I've not had a reproducible report that would allow me to investigate this further, and there is no Excel documentation from Microsoft the gives me a clue on what to do in this case. It does seem that VSTO add-ins can also get into this state (that's how we learnt of the registry fix) so I don't think it's something that Excel-DNA is doing wrong.

I'm not sure what you mean by 'fighting for Ribbon space'. There might be identifiers that have to be unique across add-ins - there are some ways to add namespaces into your ribbon ids in the xml - you might like to look into this.

-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 http://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.

[Randy Qian]

Hi Govert,

I am unfortunately dealing with the mysterious case where the plugin isn't shown in the disabled list. I'm running my plugin made with ExcelDNA in 64 bit Windows 7 Professional, with 32 bit Excel. It is very similar to what Farhan is describing the following thread:

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

Ribbon loading also fails at:

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

with "Invalid index. (Exception from HRESULT: 0x8002000B (DISP_E_BADINDEX))"

I've used ProcMon to verify that it's a key consistency issue, the CLSID key for the ribbon gets written but can't be read moments later. Some of users all suddenly reported the issue last Wednesday, others didn't. 

There are complexities w/ running 32 bit apps in 64 bit windows with the virtualized 32 bit WOW registry that I'm aware of but not fully versed in. I tried recompiling "ExcelDna.Integration" using "x86" as the target instead of "Any Cpu" but that didn't help.

The other thing I tried was to replace the lines:

// Register the ProgId as a COM Add-In in Excel.

            Registry.SetValue(@"HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\" + progId, "LoadBehavior", 0, RegistryValueKind.DWord);

            Registry.SetValue(@"HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\" + progId, "FriendlyName", friendlyName, RegistryValueKind.String);

            Registry.SetValue(@"HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\" + progId, "Description", description, RegistryValueKind.String);

With:

            RegistryKey rk = Registry.CurrentUser.CreateSubKey(@"\Software\Microsoft\Office\Excel\Addins\" + progId, RegistryKeyPermissionCheck.ReadWriteSubTree);

            rk.SetValue("LoadBehavior", 0, RegistryValueKind.DWord);

            rk.SetValue("FriendlyName", friendlyName, RegistryValueKind.String);

            rk.SetValue("Description", description, RegistryValueKind.String);

And in the other places in "ExcelDNA.Integration" where the registry is written, motivated by the model of more invariant registry interaction that I gleand from:

http://stackoverflow.com/questions/9491958/registry-getvalue-always-return-null

http://stackoverflow.com/questions/4950371/cannot-write-to-the-registry-under-hkey-local-machine-software

I'm not going to be able to release those changes users until after the workday is done, but I will report back.

-Randall

[Govert van Drimmelen]

Hi Randy,

Thanks for posting about your experience.

I doubt whether this is a 32-bit/64-bit issue. As far as I know the virtualization under 64-bit just works right in our setting, since we'd be running under a 64-bit process when registering.

And I think I would have heard long ago if there were a general issue with the current approach.

So I'd be very interested to know if you see anything interesting with the code change you show.

Excel-DNA tries to register under the machine hive (HKLM), but if that fails it falls back to trying to register under the user's hive (HKCU). In the past we always registered under the user's hive, but some UAC security situations made that fail (the write works, but Excel ignores those entries when running 'As Administrator'. So now we try to write to HKLM, and if that fails (which means we're not running in an elevated 'as Admin' token) then we fall back to the HKCU.

At least that's the intention.

You say the entry "...gets written but can't be read moments later". This sounds a lot like security software interfering with the process, and watching for changes which are automatically being reverted.

There have been problems in the past related to anti-virus and other security software, including the Microsoft EMET tool.

Maybe you could have a look for something like that, which could be interfering.

Another approach might be to check what happens when running under reduced privileges (by removing write-access to HKLM) which will force Excel-DNA to write to HKCU instead. Maybe whatever is blocking or interfering with the HKLM write will not be unhappy with entries written to HKCU.

-Govert

[Randy Qian]

Hi Govert,

I haven't completely gotten to the bottom of this but I did find something that works for the subset of my users having the issue:

-Under "ExcelComAddInHelper's" "LoadComAddIn", I replaced

                using (new ProgIdRegistration(progId, clsId))

with

                using (new ProgIdUacRegistration(progId, clsId))

Users launching Excel under normal privileges are able to load the custom ribbon now. I don't believe they are able to launch the ribbon with admin privileges though, I will get back to you on this.

-I suspect this is irrelevant to the issue being discussed but I'll include it. I modified the registry writing sections of "ComAddInRegistration" "ProgIdRegistration" and "ClsIdRegistration" with code analogous to:

            RegistryKey rk = Registry.CurrentUser.CreateSubKey(@"Software\Microsoft\Office\Excel\Addins\" + progId, RegistryKeyPermissionCheck.ReadWriteSubTree);

            rk.SetValue("LoadBehavior", 0, RegistryValueKind.DWord);

            rk.SetValue("FriendlyName", friendlyName, RegistryValueKind.String);

            rk.SetValue("Description", description, RegistryValueKind.String);

Changes to "ProgIdRegistration" shouldn't be relevant since it's not being referenced anymore. I didn't modify the UAC version of these functions. It is just worth noting that the replaced code continues to work.

Also "RTDRegistration's" "TryRTD" (unrelated to ribbon loading I think) I replaced

                using (new ClsIdRegistration(clsId, progIdRegistered))

                using (new ClsIdUacRegistration(clsId, progIdRegistered))

-Randy

[Young Zhang]

Hi Guys,

I'm having a similar issue, with the ribbon failing to load for certain users. Interestingly enough, the add-in itself is loaded and works fine, and the users can do work using hot-keys, but the ribbon is obviously not there.

Like Randy, our failures are also in the ExcelComAddInHelper.LoadComAddIn() method, but unlike Randy, for us it fails immediately after:

using (new SingletonClassFactoryRegistration(addIn, clsId))
using (new ProgIdRegistration(progId, clsId))
using (new ComAddInRegistration(progId, friendlyName, description))
{

in the line:

excelComAddIns = appType.InvokeMember("COMAddIns", BindingFlags.GetProperty, null, app, null, ci);

The above line generates the exception:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x800A03EC

I've put lots of Trace statements in our ExcelDna.xll and read the output with DebugView, and the registry entries seem to be properly written. I've even added statements to read what was written to compare. It correctly writes to:

HKEY_CURRENT_USER\Software\Classes\Dna.83632e8bd44258e78b676d50595d36bb.0\CLSID
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\Dna.83632e8bd44258e78b676d50595d36bb.0, valueName=LoadBehavior
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\Dna.83632e8bd44258e78b676d50595d36bb.0, valueName=FriendlyName
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\Dna.83632e8bd44258e78b676d50595d36bb.0, valueName=Description

I will try Randy's ProgIdUacRegistration trick and let you guys know.

Young

[Govert van Drimmelen]

Hi Randy,

What version of Excel are you using?

The ProgIdUacRegistration and ClsIdUacRegistration versions first try to register under the machine hive, HKLM, and then falls back to the user hive (HKCU) only if that fails.

So presumably you are in a situation where you are able to write COM entries to the user hive, but those entries are ignored by Windows. I understand that to be the mode which is enabled for users running under an elevated token.

I would like to know a bit more about the environment, because this has not been a common problem.

(Most of the ribbon-related issues seem to be related to disabled add-ins that I suspect is due to unhandled exceptions.)

-Govert

[Randy Qian]

Hi Govert,

I'm using Excel 2010 Professional 2010, version 14.0.7128.5000. Let me know if you want any other details.

One thing that is strange is that only some of the PCs in my office are affected. Maybe this means there are inconsistent elevations assigned to each user's account by our system administrator. It may also be because they're not using the same collection of Excel updates since the IT services we use only white-lists windows patches. They don't handle any of the Excel patches which means that each user is responsible for keeping Excel updated.

That said, the issue happened without my intervention, it had been over a week since I released a new version of the xll. Also, none of the other ribbons that other services register encountered this issue.

-Randy

[Paul Harrington]

I would not be at all surprised if this is the problem described in https://exceldna.codeplex.com/workitem/9366 

If the Trust Center settings require addins to be signed then the (signed) ExcelDNA xll will be loaded but the CTP does not get created. If one drops the Trust Center settings then all our experiments ran just fine. I have not had time over the last several months to look into this any further but I may be able to do something over the next month or so.

pjjH