N
NathanCompass
Guest
Posted this elsewhere, but have yet to see a single response. Really could use some insight or suggestions, anything really.
Issue:
Program uses CreateObject to create a new email form using locally installed 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 the appropriate 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 after the Office update. The program attempting to create a new email/message form 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 registry key and the issue persists.
Conclusion for a resolution is to manually correct the registry key value to point to the correct folder that matches the current build of Outlook.
Example: forced an error to show where the registry 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.
C:\Program Files\WindowsApps\Microsoft.Office.Desktop.Outlook_16051.12130.20344.0_x86__8wekyb3d8bbwe\Office 16\Outlook.exe
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 between the registry/actual outlook build version.
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.
Trying to avoid having to go through each and every key, change the value, see if the process breaks and just trial/error the whole thing. Asked in a couple other places already and just a side-note, does not have anything to do with the store app for Office.
Thanks for your time and any advice.
Continue reading...
Issue:
Program uses CreateObject to create a new email form using locally installed 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 the appropriate 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 after the Office update. The program attempting to create a new email/message form 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 registry key and the issue persists.
Conclusion for a resolution is to manually correct the registry key value to point to the correct folder that matches the current build of Outlook.
Example: forced an error to show where the registry 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.
C:\Program Files\WindowsApps\Microsoft.Office.Desktop.Outlook_16051.12130.20344.0_x86__8wekyb3d8bbwe\Office 16\Outlook.exe
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 between the registry/actual outlook build version.
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.
Trying to avoid having to go through each and every key, change the value, see if the process breaks and just trial/error the whole thing. Asked in a couple other places already and just a side-note, does not have anything to do with the store app for Office.
Thanks for your time and any advice.
Continue reading...