|
briannesbitt
Guest
|
Hey guys,
I'll start by saying our PowerPoint add-in is used by thousands of users across many clients without any issues. We, however, have one client that is getting an "Unable to create specified ActiveX control." exception on a handful of machines (maybe 5% of installs) among their install base.
On a clean install it seems to work. The issue is some of these users had a previous per-user install, then another per-user install and now finally a per-machine version deployed. While we provided instructions on how to uninstall etc, I am unaware if they were completed (I suspect they weren't and maybe just installed on top of each other). On a failing machine if you login as the admin user the add-in runs ok (per-machine). If you login as the user, it fails with the exception on taskpane creation.
The only current fix right now is to rebuild the user profile which fixes the issue. This leads me to believe its a registry problem with the various install/uninstalls. Hoping for a quicker fix than a user profile rebuild, where in the registry would I look for the various keys that might be creating the problem?
Here is the complete exception:
System.Runtime.InteropServices.COMException (0x80004005): Unable to create specified ActiveX control.
at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData& msgData)
at AddinExpress.MSO.ICTPFactory.CreateCTP(String CTPAxID, String CTPTitle, Object CTPParentWindow)
at AddinExpress.MSO.ADXAddinModule.AddCustomTaskPanes(Object parent, String outlookFolderName, Boolean showError)
Most of them are on Windows 7 x64, Office 2013 x32.
Thanks! |
|
|
briannesbitt
Guest
|
|
Just a quick addition. I am not sure if this will help in this case, but I saw this issue once (about 1.5 years ago!). When I did a search I found this SO post (https://stackoverflow.com/questions/16454430/addinexpress-install-error-addcustomtaskpanes) and tried renaming the taskpane and redeploying and that worked. It was an internal test machine so it was easy for us to try it on. We have not seen this issue since and renaming the taskpane in the code is no longer a viable solution. |
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hello Brian,
The name of the UserControl class is part of the ProgId used to as part of the COM registration required for you user control to be used as an ActiveX control (required by the Custom Task Pane technology).
I suppose the ProgId still exists in the registry on these machines. Say, for a task pane created by a test add-in I get this ProgID: HKEY_CLASSES_ROOT\MyAddin149.UserControl1. The ProgId entry contains the CLSID value. Search for that ID in the registry. The CLSID key (such as HKEY_CLASSES_ROOT\CLSID\{D1F7B40F-55C0-379E-BFFF-045ADB323F17}) contains the InProcServer32 subkey; it contains the CodeBase value. This value points to the location of the assembly providing the task pane. If this location differs from the location in which your current add-in is installed, you need to uninstall the per-user version of your add-in or delete the CLSID key. You may also need to delete the ProgId key.
All these manipulations should be performed with your add-in(s) uninstalled. There is a possibility that all these problems will go away if you uninstall the per-user variant of your add-in and restart he host application.
By changing the name of the user control, you create a different ProgId. This ProgId won't interfere with the ProgId used by the per-user variant of your add-in. Still, getting the registry clean is a more systematic approach in my opinion.
Andrei Smolin
Add-in Express Team Leader |
|
|
briannesbitt
Guest
|
Thanks Andrei. That is exactly what I needed to know.
So just to follow up and close this off... I was onsite late last week and got access to the computer in question. Turns out they did not uninstall the per-user version before installing the per-machine version. They also have the computers locked down so as a user you can't run regedit.exe as the user for example, which makes it tough. Because the newer version was installed the control panel uninstall shows 2 versions of our add-in installed with the older version having a default icon. When you try and uninstall Windows just thinks it not installed and throws up an error. Running PowerPoint and trying to remove the add-in from the options menus gives a permission error as well because of the locked setup.
The final solution was to login as an administrator and find the users registry via regedit and opening the root guid keys for the users. Once we found the correct registry tree you could then just delete the key for our per-user addin install under the "[USER_GUID_ROOT_KEY]\SOFTWARE\Microsoft\Office\PowerPoint\Addins" folder in the registry. Now when you logged back in under the user account there was no conflict anymore and it just ran the per-machine installed version and all of the taskpanes worked!
For what its worth I also noticed that the add-in was mapped to "mscoree.dll" in the PowerPoint Options -> Add-ins dialog for some reason. After making the changes above it was mapped to "adxloader.dll" as we expected. |
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hello Brian,
My congratulations!
Thank you for providing a detailed description! I'm sure someone will find it useful some day.
briannesbitt writes:
For what its worth I also noticed that the add-in was mapped to "mscoree.dll" in the PowerPoint Options -> Add-ins dialog for some reason.
This often occurs if adxloader.dll/adxloader64.dll aren't deployed.
Andrei Smolin
Add-in Express Team Leader |
|
Forums
Topics
Search
Help
Login
Register