Add-in can not be registered when is launched as administrator using Excel 365 version 16.0.12827.20200

[elarmando]

Hello everyone, I would appreciate a lot your support with this problem.

I've been facing this error when I run the CustomTaskPane example (link to example).

This only happens when I run excel (or visual studio) as administrator. My current excel version is this one:

This is a recent version so I tried to replicate the problem using office professional plus 2016 16.0.4266.1003, but in that version works good.

I'm also concerned about this issue issue but this time the add-in is not disabled by excel.

Thanks a lot.

[govert]

Can you confirm what version of Excel-DNA you are using?

[elarmando]

The problem can be replicated using version 1.0.0

[govert]

@elarmando OK - I'll have to set some way of testing and debugging this. Do you have a ribbon component in your add-in, and does it work in the elevated process? The ribbon loading is a bit different to the control registration for a CTP.

[elarmando]

Yes, I have one and It is not shown either. Thanks a lot for the quick reply, Govert.

[govert]

It this an environment where some Group Policy setting might be in place? There are various Excel, Office and other behind-the-scenes security settings that might be involved.

This is an example: https://groups.google.com/d/topic/exceldna/UaXeax0vHAI/discussion

[elarmando]

Hi, Govert,

The first time I saw the error I was in the company where I work, so I did the same test in my personal computer to avoid some kind of security. The error still appears. According to the link you provided, I checked the registry to find some kind of policy but I didn't find something. I also added the folder of the xll as a trust location, but didn't help.

I hope this information is useful, thank you.

[andysinclair]

Hi,

I have just had this issue reported by one of the users of my Add-in. It works fine in non-admin mode, however if you run Excel (or Visual Studio) in Administrator Mode you don't see the ribbon nor the Add-in. I enabled verbose logging and can see the following error:

[ERR] The Ribbon/COM add-in helper required by add-in ExcelPriceFeed could not be registered.
This may be due to the helper add-in being disabled by Excel.
To repair, open Disabled items in the Options->Add-Ins page and re-enable target add-in, then restart Excel.

Error details: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException: Class not registered

   --- 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 ExcelDna.Integration.ExcelComAddInHelper.LoadComAddIn(ExcelComAddIn addIn) : TargetInvocationException - Exception has been thrown by the target of an invocation.

Not sure how to investigate/fix this, any ideas?

[govert]

@andysinclair I can reproduce the error you report too, but I haven't been able to debug it or understand whether this is behaviour that has changed in Excel. Is this something that used to work in the same setting for your add-ins (running in an elevated process)?

[andysinclair]

Hi @govert Thanks for the quick reply. I’m afraid this is the first time I have experienced this issue so I can’t say if it ever used to work. I’ll continue to investigate and report back here if I discover anything.

[govert]

@elarmando Is this a scenario that worked before with your add-in? I'm trying to figure out whether the changes relate to an Office or Windows update.

[elarmando]

Hi, @govert , It used to work two weeks ago. I suspect it was an office update.

[govert]

@elarmando @andysinclair I don't really understand the cause, but I have a plan and will try to push a workaround in the next few days.

[elarmando]

Thanks a lot, @govert :)

[andysinclair]

Thanks @govert and do let us know if you need any help testing.

[govert]

@elarmando @andysinclair I've pushed an updated version of Excel-DNA to NuGet as version 1.1.0-beta3. This version has a (small !?) fix that seems to work around this issue.

I would appreciate if you could give it a try, and provide any feedback. I have only checked on my own machine, and not under 64-bit Excel at all.

I don't understand the problem or why the workaround works (just talking to the registry in a slightly different way). However, I can see it relates to how the registry gets virtualised by the Office Click-To-Run infrastructure. This is generally poorly documented, so it's a bit hit and miss.

[elarmando]

Thanks a lot, @govert , I'll test it and let you know if everything works as expected.

[elarmando]

Hi, @govert , I did some test using both excel, for 32 and 64 bits. It is working as expected. A colleague will run an automatic test suite this night just to see if there is any regresion error. I'll let you know our results. I appreciate a lot your help to fix this error so quickly. Thank you

[andysinclair]

Hi @govert I have also tested it and it is working well. I have tested Admin mode Visual Studio and the 32 bit version on another machine, so far so good. I have also sent it to a customer for testing. I will report back here if I notice any issues. Thanks for your help with this.

[elarmando]

Hi, @govert , the fix is done, Thank you so much. Should I close this issue?

[raymondjstone]

Maybe not of help with the issue solved but is this not what 'active setup' is for? I use that to register the addin for new users as they log in when the software it is using is a per machine install.

[govert]

@raymondjstone You're right - Active Setup seems to be the standard way of ensuring per-user installs can be done for all users. With Excel-DNA I've tried to also make it possible to just deploy the add-in file without any extra installers. This works quite well, but the current issue is a surprising one where there were problems when the process is running elevated. That seems to be resolved now.

[govert]

Here is a new report post-v1.1.0 for a related issue: https://groups.google.com/g/exceldna/c/TSOPygt334Y

Not sure if the App-V is a sufficiently different environment, or whether this affects only elevated contexts. But the issue sure seems related:

Some of our users are seeing a problem loading up our ExcelDna add-in. They have been running Excel Office 365 in a virtual manor using AppV successfully for some time. Last week they upgraded to the latest Office and that's when the problem started. They are using DNA version 34. Here's the DNA error log:

ExcelDna.Integration Verbose: 4 : Loading Ribbon/COM Add-In
ExcelDna.Integration Verbose: 4 : RegistrationUtil.CanWriteMachineHive - UnauthorizedAccessException - False
ExcelDna.Integration Error: 4 : RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - Illegal operation attempted on a registry key that has been marked for deletion.

ExcelDna.Integration Error: 4 : RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled
ExcelDna.Integration Error: 4 : The Ribbon/COM Add-In helper required by add-in XXX could not be registered.
This may be due to restricted permissions on the HKCU\Software\Classes key : UnauthorizedAccessException - RegistrationUtil - Unable to write to Machine or Users hives of registry

Some other posts to this group discuss this issue I believe. We thought upgrading to DNA version 1.1.0 would fix it. But the problem is still there after the upgrade. Would be grateful for any insights or suggestions.

[rosssaunders]

Hi,

I seem to be have a very similar issue when using DNA 1.1.0 and running Excel 2016 under Click-To-Run. It's in a corporate environment so I'm not sure the exact details of the setup of AppV and whether is a pseudo or real context.

For some background, the add-in exposes several COM objects as well as a custom Ribbon and everything works great under Excel 2010. We are currently migrating to Excel 2016 and are hitting the following (from the logs)

DEBUG ExcelDna.Logging.Logger - ExcelComClassType.RegisterServer ABC.Dept.ComObject - ABC.Dept.ComObject (b5fa9611-931a-4b23-888a-a4f550e4412b) DEBUG ExcelDna.Logging.Logger - DEBUG ExcelDna.Logging.Logger - Loading Ribbon/COM Add-In DEBUG ExcelDna.Logging.Logger - DEBUG ExcelDna.Logging.Logger - RegistrationUtil.CanWriteMachineHive - UnauthorizedAccessException - False ERROR ExcelDna.Logging.Logger - RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - The specified registry key does not exist. ERROR ExcelDna.Logging.Logger - ERROR ExcelDna.Logging.Logger - RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled ERROR ABC.Dept.ExcelAddin - Failed to dynamically register the COM server System.UnauthorizedAccessException: RegistrationUtil - Unable to write to Machine or Users hives of registry at ExcelDna.ComInterop.ComRegistration.RegistrationUtil.get_ClassesRootKey() at ExcelDna.ComInterop.ExcelComClassType.RegisterServer() at ExcelDna.ComInterop.ComServer.DllRegisterServer() at ABC.Dept.ExcelAddin.AutoOpen()

Excel is being run under a standard user (non admin) account and has permissions to write to the "HKEY_CURRENT_USER\Software\Classes" hive, however, by looking into the registry, I can see that this is being virtualized to here "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\USER" which a standard user account does not appear to have the security permissions to write to. I would have hoped that the virtualization layer of AppV would still write to the USERS virtual hive, however, this does not appear to be the case. (Unfortunately due to corporate policy I cannot run Procmon to see what is going on under the hood.)

I saw in the other conversation your comment: "It might be possible to change the parts of your add-in that are loaded using the on-demand COM registration (probably a Ribbon extension) into being pre-registered. That would mean you need to pre-register the add-in on the machine, outside the App-V sandbox. It would take some experimenting to see how this works.". We have VSTO addins that work fine and I'd assume it is because the installation is happening outside of the AppV sandbox.

Do you have any further thoughts on how to start going about pre-registering the COM components using ExcelDNA and where I should start looking?

Thanks v. much in advance for any assistance,

Thanks,

Ross

[govert]

@rosssaunders I can't remember all the details, but I think that the registry write is to HKLM...\ClickToRun\REGISTRY\USER is normal, and we expect the user to have permissions to write to that key. But I'd have to get back into the details again - not so easy every time, as you might imagine.

It would be a big help for me to have access to a VM that reproduces the problem. Do you have some help that could try to get a VM on Azure or somewhere set up to a configuration that breaks similarly?

For exploring the pre-registration, we'd basically have to figure out how well the different COM aspects in Excel-DNA work through the regsvr32 registration. By "COM components" do you mean the ComServer support for VBA? I think that will work OK, and the ribbon has some trick I've forgotten, but can work too. So it should be possible,

But I am really interested in understanding how your environment is configured to cause this problem. I'm not getting similar reports otherwise, and I know of some other users moving to Excel 2016 this year. So something in your locked-down policy is breaking it, and maybe fixing it is as easy as changing one setting in the group policy.

[rosssaunders]

@govert Thanks v. much for the quick response.

Regarding the VM to reproduce, I'll start asking internally and try and find the team responsible for the Office deployments and configuration. It's a large financial institution so as you would imagine, this might take some time. In the meantime, I happy to investigate any suggestions or questions you have.

I do have other clients (at a different company) running Excel 2016 and ExcelDNA based add-ins without any issues so it does appear to be specific to this environment or the way Excel is deployed using Click-To-Run / App-V. Hopefully it is just a group policy that can be changed.

I have also managed to work around the issue by doing the following. (might be helpful for anyone else blocked at the moment with this issue). I did have to re-compile ExcelDNA, so if there is a better way, please let me know.

Enable VBA ComServer support

Ran regsvr32 on the XLL and removed the call in my code to "ComServer.DllRegisterServer();" in AutoOpen.

To enable the Ribbon

Removed the following lines in ExcelComAddInHelper.LoadComAddIn (lines 129-131) to stop ExcelDNA from attempting to register the Custom Ribbon in the registry.

using (new ProgIdRegistration(progId, clsId))
using (new ClsIdRegistration(clsId, progId))
using (new ComAddInRegistration(progId, friendlyName, description))

and rebuilt the ExcelDNA nuget package.

Registered the Custom Ribbon with Excel as a COM Addin via the registry

[HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\ABC.Corp.CustomExcelRibbon]
"Description"="CorpExcelAddIn"
"FriendlyName"="CorpExcelAddIn"
"LoadBehavior"=dword:00000000

ensuring the LoadBehaviour is set to 0 (don't load) as we'll load it ourselves in the AutoOpen once the ExcelDNA framework has started.

Added the following code to AutoOpen

object app = ExcelDnaUtil.Application;
Type appType = app.GetType();

var appl = app as Microsoft.Office.Interop.Excel.Application;
foreach(COMAddIn ca in appl.COMAddIns)
{
   if(ca.Description.Equals("CorpExcelAddIn", StringComparison.InvariantCultureIgnoreCase))
   {
      ca.Connect = true;
   }
}

[RobertDaCosta]

Hi Govert. Long term fan. We use DNA extensively to deliver C# functionality to many trader sheets.

We are moving to a Windows 10 (64-bit) Virtual platform and have come across this error. ComAddIn [Error] RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - Illegal operation attempted on a registry key that has been marked for deletion. ComAddIn [Error] RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled Initialization [Error] DnaLibrary AutoOpen Error : TargetInvocationException - Exception has been thrown by the target of an invocation.

I've also followed the bypass approach mentioned by Cedric in the article you mentioned https://groups.google.com/g/exceldna/c/TSOPygt334Y and have managed to get a working version.

It would be super helpful getting a solution to this. Let me know if I can provide any info that might help.

[rosssaunders]

@govert Thanks v. much for the quick response.

Regarding the VM to reproduce, I'll start asking internally and try and find the team responsible for the Office deployments and configuration. It's a large financial institution so as you would imagine, this might take some time. In the meantime, I happy to investigate any suggestions or questions you have.

I do have other clients (at a different company) running Excel 2016 and ExcelDNA based add-ins without any issues so it does appear to be specific to this environment or the way Excel is deployed using Click-To-Run / App-V. Hopefully it is just a group policy that can be changed.

I have also managed to work around the issue by doing the following. (might be helpful for anyone else blocked at the moment with this issue). I did have to re-compile ExcelDNA, so if there is a better way, please let me know.

Enable VBA ComServer support

Ran regsvr32 on the XLL and removed the call in my code to "ComServer.DllRegisterServer();" in AutoOpen.

To enable the Ribbon

Removed the following lines in ExcelComAddInHelper.LoadComAddIn (lines 129-131) to stop ExcelDNA from attempting to register the Custom Ribbon in the registry.

using (new ProgIdRegistration(progId, clsId))
using (new ClsIdRegistration(clsId, progId))
using (new ComAddInRegistration(progId, friendlyName, description))

and rebuilt the ExcelDNA nuget package.

Registered the Custom Ribbon with Excel as a COM Addin via the registry

[HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\ABC.Corp.CustomExcelRibbon]
"Description"="CorpExcelAddIn"
"FriendlyName"="CorpExcelAddIn"
"LoadBehavior"=dword:00000000

ensuring the LoadBehaviour is set to 0 (don't load) as we'll load it ourselves in the AutoOpen once the ExcelDNA framework has started.

Added the following code to AutoOpen

object app = ExcelDnaUtil.Application;
Type appType = app.GetType();

var appl = app as Microsoft.Office.Interop.Excel.Application;
foreach(COMAddIn ca in appl.COMAddIns)
{
   if(ca.Description.Equals("CorpExcelAddIn", StringComparison.InvariantCultureIgnoreCase))
   {
      ca.Connect = true;
   }
}

Hi,

Update on this issue. It appears it is entirely due to McAfee antivirus kicking in and blocking ExcelDNA from registering the COM components.

This is from the McAfee event logs

USER1 ran C:\Windows\SysWOW64\regsvr32.exe, which tried to access HKLM\SOFTWARE\CLASSES_EXCELDNA.PERMISSIONSTEST.MACHINE, violating the rule "Modifying file extension associations", and was blocked. For information about how to respond to this event, see KB85494.

I wonder if there is a different way of testing the registry permissions that doesn't trigger McAfee?

I will attempt to find some time to test different approaches to testing the registry.

Regards,

Ross

[govert]

Thank you very much for the update.

I have in mind looking at two improvements, though can’t promise anything yet:

• Add a setting in Excel-DNA to either ignore the error when deleting the registry key, or completely skip the runtime registration (i.e. the code commented out in the code snippet below). I hope this give a way to work around the issue without making a custom Excel-DNA build, by optionally pre-registering in the registry, and then not trying to do any registration at runtime.
• A better fix might be to revisit the Windows ActivationContext API again. I had tried this in the past without being satisfied with the options. But I think it is the better approach and worth revisiting.

I suspect the McAfee block is still not the whole story, by the relatively few complaints I’ve received.

Is this still in the locked-down VM environment?

[RobertDaCosta]

@rosssaunders , do you see this issue on every run? The issue I described above is intermittent (and to be honest infrequent). We also have McAfee running on these VMs.

[rosssaunders]

@RobertDaCosta I'd say about 9 times out of 10 I see the issue. The intermittent nature of this is what caused me to stop looking at GPO / ClickToRun / AppV and look elsewhere.

Try having a look at the Application event log on your PC. There might be something interesting in there.