CreateObject getVersion Outlook registry key

[NcarterCompass]

Afternoon,

Program uses CreateObject to create a new email form using Outlook. Part of this involves a getVersion check in the registry to a key that has a value of a file path under C:\Program Files\WindowsApps\

that then goes to a folder for Outlook which contains the current build version of the program on the system. After an update, the build version updated and generated a new folder which contains dll files and a separate OUTLOOK.exe file used for this automation process. The thinking is that the registry key's value was not updated to then match this change. The program attempting to create a new email then hits a dead-end as the folder for the previous build is no longer there, it was removed as part of the Office update process. This leads to the program instantly terminating and in the Event Viewer showing a KERNELBASE.dll and .NET framework errors.

Repetitive online repairs of Office do NOT affect this key and the issue persists. Conclusion for a resolution is to manually correct the registry to point to the correct folder that matches the current build of Outlook.

Example:  forced error to show where it is looking- C:\Program Files\WindowsApps\Microsoft.Office.Desktop.Outlook_16051.11629.20214.0_x86__8wekyb3d8bbwe\Office16\Outlook.exe

forced error to demonstrate where the registry value looks

folder the registry SHOULD be pointed to

Folder/file path it SHOULD be looking at instead.

The work-around found was to copy the current build folder, re-name it to the previous build noted in the error so it matches and no longer dead-ends, restoring the function, but an error still occurs after the fact due to there still being a mis-match existing.

There are redundant keys that reference the same file path - hoping someone can tell me for certain which specific key the command checks to find the version/file path so it can be manually corrected.

Thank you kindly for your advice in advance!

[#2]

Any input on this? It's difficult to comb through multiple registry entries that are similar to identify which specific one is being used to direct to the appropriate file path.

Thank you for your time.

[#3]

I've posted a similar entry on social.technet and on the community site.

To simplify -

My immediate question is when the CreateObject command is used that has a getVersion to check the registry for info on the currently installed version of Outlook - which should lead to a value on the registry key that has a file path - 

I need to know the exact registry key the getVersion part actually checks. Everything else is irrelevant until I know the specific key being used to get to Outlook.

People seem to know how to get from A to Z, but not the in-between in this case. I've got half a dozen people experiencing the same problem at the moment - if I knew which key is being used I could easily replicate the problem on my own device.

So far the game plan is to export the entire registry, look for keys with a particular file path and change them until I discover by trial/error which key breaks the process since it doesn't appear to be documented anywhere I've looked online.

Is it in CLSID? Interface? TypeLib? Even in Classes_root? Actually in Local_machine?

[#4 · Accepted solution]

Got it.

Big thanks to Diane on the community site. Key referenced

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\outlook.exe

If I alter the path, the automation breaks and causes the errors in the Event Viewer. Users affected likely still have a path tied to the store app version of Outlook, even if it was previously removed off the system, the registry did not get changed to reflect a pathway to the C2R local version of Outlook. Correct the values to the following and the problem is resolved:
(Default) C:\Program Files\Microsoft Office\Root\Office 16\OUTLOOK.EXE

Path C:\Program Files\Microsoft Office\Root\Office 16\