Run as admin writes to HKCU - Add-in Express .NET forum

Tim Kempster

Posts: 13
Joined: 2025-09-24

Dear Forum,

I recently deployed an project built for InstallAllUsers=True with the registration step "adxregistrator.exe /install="OutlookPrint.dll" /privileges=admin"

The client has been trying to install by running setup.exe as administrator but they don't see the add-in. I have discovered that when they elevate the process it also switches the account to an admin account. This then wrote the adxregistrator.log file to a different %TEMP% file but I've now retrieved that and I paste it below. To my horror the outlook Add-In registry keys are being placed under HKCR and so this is the reason the user does not see the add-in under their own login. I'm very confused because I thought that because the project is InstallAllUsers=True and the adxregistrator.exe is being run with /privileges=admin it would write instead to HKLM and registration would work for all users on the machine.

Am I missing somthing?

Add-in Express Registrator Log File: 12/19/2025 12:16:10

Installation directory: C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\
Registrator version: 10.2.4714.0
Operating System: Microsoft Windows 10 Professional (build 22631), 64-bit
Process Owner: Administrator
Command Line: "C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\adxregistrator.exe" /install="OutlookPrint.dll" /privileges=admin
Run 'As Administrator': Yes
Process Elevated: Yes
Integrity Level: High
UAC (User Account Control): On
--------------------------------------------------------------
12:16:10 0552 Starting the add-in registration process.
12:16:10 0552 Loading mscoree.dll
12:16:10 0552 Success.
12:16:10 0552 .NET Framework installation directory:
12:16:10 0552 The latest version of .NET Framework: 'v4.0.30319'
12:16:10 0552 Loading CLR: v4.0.30319.
12:16:10 0552 Calling CLRCreateInstance method.
12:16:10 0552 Success.
12:16:10 0552 Calling GetRuntime method.
12:16:10 0552 Success.
12:16:10 0552 Checking if the hosting API of .NET Framework v4.0 beta is installed.
12:16:10 0552 The hosting API is up to date.
12:16:10 0552 Calling GetInterface method for the CorRuntimeHost interface.
12:16:10 0552 Success.
12:16:10 0552 Starting CLR...
12:16:10 0552 Success.
12:16:10 0552 Getting the CLR version.
12:16:10 0552 The CLR v4.0.30319 has been initialized successfully.
12:16:10 0552 Creating a new domain setup.
12:16:10 0552 Success.
12:16:10 0552 Getting the add-in directory.
12:16:10 0552 Success. The directory is 'C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\'
12:16:10 0552 The 'shadow copy' is disabled.
12:16:10 0552 Creating a new application domain.
12:16:10 0552 Success.
12:16:10 0552 Getting the base directory for the domain.
12:16:10 0552 Success. The directory is 'C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\'.
12:16:10 0552 Searching for the Add-in Express core library.
12:16:10 0552 Success. The 'AddinExpress.MSO.2005.dll' file is found.
12:16:10 0552 Creating an instance of the 'AddinExpress.Deployment.ADXRegistrator' class.
12:16:10 0552 Assembly identity is 'AddinExpress.MSO.2005'.
12:16:10 0552 Success.
12:16:10 0552 Unwrapping the instance of the 'AddinExpress.Deployment.ADXRegistrator' class.
12:16:10 0552 Success.
12:16:10 0552 Calling the managed registration procedure (DISPID = 1610743823).
12:16:11 1132 32 bits. The 'HKCU\Software\Microsoft\Office\Outlook\AddIns\OutlookPrint.AddinModule' registry key was created successfully for the 'OutlookPrint.AddinModule' class: LoadBehavior=3
12:16:11 1132 32 bits. The 'HKCR\CLSID\{25609aa0-c6d0-44bc-ae2e-7c1ad212572a}\InprocServer32' registry key was created successfully for the 'OutlookPrint.AddinModule' class: C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\adxloader.dll
12:16:11 1132 64 bits. The 'HKCU\Software\Microsoft\Office\Outlook\AddIns\OutlookPrint.AddinModule' registry key was created successfully for the 'OutlookPrint.AddinModule' class: LoadBehavior=3
12:16:11 1132 64 bits. The 'HKCR\CLSID\{25609aa0-c6d0-44bc-ae2e-7c1ad212572a}\InprocServer32' registry key was created successfully for the 'OutlookPrint.AddinModule' class: C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\adxloader64.dll
12:16:11 0552 Registration success.
12:16:11 0552 The add-in registration process is completed with HRESULT = 0.

Andreas Waning

Posts: 3
Joined: 2024-11-06

Hello Tim, have you found a solution to the problem? I have exactly the same problem. I'm slowly getting the feeling that Addin Express no longer provides support. Gruß Andreas

Tim Kempster

Posts: 13
Joined: 2025-09-24

Thanks Andreas for your post. It's really annoying. The odd thing is I have a Word based add-in and the installer does write to HKLM. Here is an extract:

14:55:24 1148 64 bits. The 'HKLM\Software\Microsoft\Office\Word\AddIns\TraySelectorOne.AddinModule' registry key was created successfully for the 'TraySelectorOne.AddinModule' class: LoadBehavior=3

This made me think I was doing something wrong with my Outlook Installer which is why I posted but as yet nothing from support which is a bit annoying but it is the holidays. In the past they've come back quickly.

However this still doesn't solve the problem of 32 bit Word because there's the WINWOW issue with the registry.

Possible solutions (I've not tried):

1. Put the required HKLM in the MSI Installer (again doesn't help with the WINWOW 32 bit problem).
2. Use a commercial builder like AdvancedInstaller which I think gives you more options but it's expensive to buy.
3. Create a new .exe which write the required keys to HKLM and is run as a custom action from the MSI Installer.
4. Use Wix but I think the same problem will exist because it is the registrator.exe which write the keys.
5. Find out if there is a way to call registrator.exe to write the HKLM keys (hence this post).

I'll try and chase up support support@add-in-express.com to see if they can help!

Andrei Smolin

Add-in Express team

Posts: 19190
Joined: 2006-05-11

Hello Tim & Andreas,

I'm sorry for the delay; it took me some time to reproduce the issue.

HKCR stands for HKEY_CLASSES_ROOT; this is a "virtual" registry key combining COM registrations from HKCU and HKLM.
This is perfectly okay for a COM class to be written in HKCR.

As to add-in keys - {HKLM or HKCU}\Software\Microsoft\Office\{an Office application}\AddIns\{an add-in} - such keys must be created as follows:
- per-user add-ins - in HKCU
- per-machine add-ins - in HKLM

Your log indicates creating add-in keys in HKCU while the command starting adxregistrator.exe suggests starting a per-machine add-in.

I reproduce the issue in this scenario:
- I have a per-machine add-in,
- I create a setup project for it, (if installed, the adxregistrator.log indicates writing to HKLM and HKCR)
- I open the designer of the add-in module and change the RegisterForAllUsers property of the add-in module, I set it to false
- I don't change the setup project, I just rebuild it.
- the resulting installer writes to HKCU and HKCR, exactly as shown in the log above.

Summing up. Changing RegisterForAllUsers requires you to use a different setup project; per-user and per-machine setup projects are very different.

Regards from Poland (GMT+2),

Andrei Smolin
Add-in Express Team Leader

Tim Kempster

Posts: 13
Joined: 2025-09-24

Thanks for your reply.

"- I open the designer of the add-in module and change the RegisterForAllUsers property of the add-in module, I set it to false"

This step I didn't understand. How do I see this in visual studio?

It seems like this needs to be set and then when you make a setup project it makes it write the add-in key to HKLM is that correct?

Also lastly, even if we achieve this will it also write to the WinWOW hive in HKLM so that 32 bit installs of Office also load the add-in?

Tim Kempster

Posts: 13
Joined: 2025-09-24

I found the setting RegisterForAllUsers on the add-in. It is obtained via

1. Right click AddinModule.cs and select View Desginer from the context menu
2. Click on the surface of the designer and the properties window is populate
3. Scroll down to RegisterForAllUsers and set to True (for the HKLM all users setting).

I have done this and rebuilt my installer and indeed the HKLM entries are made see below:

11:47:59 1156 64 bits. The 'HKLM\Software\Microsoft\Office\Outlook\AddIns\OutlookPrint.AddinModule' registry key was created successfully for the 'OutlookPrint.AddinModule' class: LoadBehavior=3

However the question now still remains if the user installs on a 64 bit machine running 32 bit Office will this work because the installer won't see the WINWOW hive?

Any help most appreciated my user is going a bit nuts!

Andrei Smolin

Add-in Express team

Posts: 19190
Joined: 2006-05-11

Tim Kempster writes:
11:47:59 1156 64 bits. The 'HKLM\Software\Microsoft\Office\Outlook\AddIns\OutlookPrint.AddinModule' registry key was created successfully for the 'OutlookPrint.AddinModule' class: LoadBehavior=3

However the question now still remains if the user installs on a 64 bit machine running 32 bit Office will this work because the installer won't see the WINWOW hive?

Although you show the 64-bit registration, your log should show that the add-in key is created twice: for the 32-bit registry and for the 64-bit registry. Is this the case? If so, the add-in will be loaded by Office of whatever bitness the user has.

Regards from Poland (GMT+2),

Andrei Smolin
Add-in Express Team Leader

Tim Kempster

Posts: 13
Joined: 2025-09-24

Thanks for your reply.

"- I open the designer of the add-in module and change the RegisterForAllUsers property of the add-in module, I set it to false"

This step I didn't understand. How do I see this in visual studio?

It seems like this needs to be set and then when you make a setup project it makes it write the add-in key to HKLM is that correct?

Also lastly, even if we achieve this will it also write to the WinWOW hive in HKLM so that 32 bit installs of Office also load the add-in?

Tim Kempster

Posts: 13
Joined: 2025-09-24

Although you show the 64-bit registration, your log should show that the add-in key is created twice: for the 32-bit registry and for the 64-bit registry. Is this the case? If so, the add-in will be loaded by Office of whatever bitness the user has.

You are correct. Here is the full log file and it does indeed say 32bits so I assume that will hit the winwow hive. Thanks.

11:47:58 0540 Calling the managed registration procedure (DISPID = 1610743823).
11:47:59 1156 32 bits. The 'HKLM\Software\Microsoft\Office\Outlook\AddIns\OutlookPrint.AddinModule' registry key was created successfully for the 'OutlookPrint.AddinModule' class: LoadBehavior=3
11:47:59 1156 32 bits. The 'HKCR\CLSID\{25609aa0-c6d0-44bc-ae2e-7c1ad212572a}\InprocServer32' registry key was created successfully for the 'OutlookPrint.AddinModule' class: C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\adxloader.dll
11:47:59 1156 64 bits. The 'HKLM\Software\Microsoft\Office\Outlook\AddIns\OutlookPrint.AddinModule' registry key was created successfully for the 'OutlookPrint.AddinModule' class: LoadBehavior=3
11:47:59 1156 64 bits. The 'HKCR\CLSID\{25609aa0-c6d0-44bc-ae2e-7c1ad212572a}\InprocServer32' registry key was created successfully for the 'OutlookPrint.AddinModule' class: C:\Program Files (x86)\Thinking-Machine Limited\Outlook Print\adxloader64.dll
11:47:59 0540 Registration success.
11:47:59 0540 The add-in registration process is completed with HRESULT = 0.

Tim Kempster

Posts: 13
Joined: 2025-09-24

I found the setting RegisterForAllUsers on the add-in. It is obtained via

1. Right click AddinModule.cs and select View Desginer from the context menu
2. Click on the surface of the designer and the properties window is populate
3. Scroll down to RegisterForAllUsers and set to True (for the HKLM all users setting).

I have done this and rebuilt my installer and indeed the HKLM entries are made see below:

11:47:59 1156 64 bits. The 'HKLM\Software\Microsoft\Office\Outlook\AddIns\OutlookPrint.AddinModule' registry key was created successfully for the 'OutlookPrint.AddinModule' class: LoadBehavior=3

However the question now still remains if the user installs on a 64 bit machine running 32 bit Office will this work because the installer won't see the WINWOW hive?

Any help most appreciated my user is going a bit nuts!