Dec 03 2019 12:05 PM
Dec 03 2019 12:05 PM
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
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!
Dec 06 2019 09:54 AM
Dec 12 2019 09:22 AM
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?
Dec 13 2019 07:14 AMSolution