Registry key deletion issue with latest Excel Office 365 under AppV

[Tony Shaw]

Hi Govert,

Thanks for ExcelDna, still loving it after 10 years using it. But we have a problem ...

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.

Thanks.

Tony

 

[Govert van Drimmelen]

Hi Tony,

 

I hope you’ve logged a support call with Microsoft too, and if not I urge you to do so.

The last time I dealt with their support (not for Office stuff, though) they were very professional and helpful.

There might be some documentation or notification of the relevant Office changes that I am not aware of.

 

The problem that was addressed in v 1.1.0 must be similar, though it presented slightly differently.

Everything I know about this can be found in the issue here https://github.com/Excel-DNA/ExcelDna/issues/317 (where I’ve now added your problem too)

and then in the comments in the code here https://github.com/Excel-DNA/ExcelDna/blob/63bedd0c00b8bf53e3708cee7b35cfde5b7c8551/Source/ExcelDna.Integration/ComRegistration.cs#L222

 

Some aspects that seems different to your case, though I do suspect the Office changes are similar:

• I only tested in the Click-To-Run pseudo App-V environment. Are you running in a App-V context? I don’t know how these differ.
• Are there App-V configuration settings that might be relevant?
• This only affected users running “As Administrator” in elevated mode in the original issue. How does this translate to your context?

 

It would be good to set up an environment that reproduces the issue, though that sounds like a bit of a project.

 

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.

 

-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/a67abbd9-ecfa-4353-95ad-63b372129254o%40googlegroups.com.

[Cedric]

Hi Govert,

I would like to thank you too for ExcelDNA which is very helpful and working very well, but one of our client faces the exact same issue described by Tony. It was working fine until they deployed a new version of Office (16.0.12...).

I spent some time understanding the issue and the client uses Click-To-Run (updates managed by their organisation)  and the affected users are not running  As Administrator in elevated mode as in the original issue. We have limited access to their IT. The client's PCs are managed remotely by a different organisation. We can however access the clients computers where the Add-In is installed (AppData\Roaming).

I understand that it is very difficult to reproduce the problem not having access to a PC with the exact same setup. I am wondering if it could be useful to collect more information by running a modified version of ExcelDNA which would log more information.

According to the log:

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

ComAddIn [Error] The Ribbon/COM Add-In helper required by add-in XX 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

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

It seems happening in CanWriteUserHive method. I suspect it happens either creating the test key or deleting the test key. This is something we can figure out by adding more traces.

Do you see any other information that could be relevant such as the user class root?

Thanks,

Cedric.

[Govert van Drimmelen]

Hi Cedric,

Thanks for the further reporting on these problems you're finding in recent Office updates in some environments.

It seems there are some problems with the registry virtualization under the Click-to-Run environment.

In my previous attempts to address this I was running into various undocumented registry values, so things are indeed a bit weird in this context.

Unfortunately I have no way to test or debug this at the moment 

 

Have you been able to report the issue to Microsoft?

Maybe they can shed some light on the recent changes.

For a future Excel-DNA version it might make sense look at other approaches to the dynamic COM registration again.

-Govert

[Cedric]

Hi Govert,

Unfortunately I cannot report the issue to Microsoft because the issue happens at the client side and we have very little information. The idea would be to add more traces to figure out why it does not work.

In order to get more info I added more traces in the 1.2 preview version but for whatever reason I never see the change when I install the nuget package. Should I do something special to use the package I created using the scripts (build.bat and package.cmd)?

Thanks,

Cedric.

[Cedric]

Govert,

I finally found out after many and many tries how to make it working. I had to compile it for the x86 platform.

I am going to try the modified version at the client side and I will let you know my findings.

Cedric.

[Govert van Drimmelen]

Thanks Cedric,

 

Please let me know what you find.

There is another approach to doing the COM stuff which I might try to explore in this context too.

Would you be able to help test this a bit later in the month?

If so, maybe you can contact me directly.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/834f179d-54b7-4392-a4c2-c3bffc3e2784n%40googlegroups.com.

[Cedric]

Hi Govert,

I found a way to bypass this issue. I compiled a version where I commented the content of the method: CanWriteUserHive. The Add-In seems to work fine without the check. The Add-In was able to create the test registry key but thrown an error trying to delete it (registry marked for deletion).  I suspect that it is linked to App-V using remote/none persistent profiles.

The issue may come from the location the test is performed. Should we try in another location? Software\Microsoft\Office\Excel\Addins for instance?

Obviously it is a ugly work around but at least it works again at the client side.

It is in the benefit of the client to have this issue sort it out long term wise and so I am quite confident that we could do further tests with their assistance. And so we can make more tests whenever it would suit you..

Should I contact you directly via email?

Cedric.