Office Software Protection Platform Removal

Dec 27, 2012  I have Office Professional Plus 2010 installed and activated with a MAK key. Similar to Windows, there is a licensing check after starting any Office application, and the Office Software Protection Platform Service is started. However, unlike the service that does this job in Windows 7, the. Hi TomislavRex, The Office Software Protection Platform.

  • Microsoft Software Protection Platform, the technologies will introduce improvements in how Microsoft software activates, is validated online and behaves when tampering or hacking is detected. As Microsoft Software Protection Platform is using more CPU usage, it might be detecting some unusual activities.
  • Sep 14, 2016  Microsoft Software Protection Platform, the technologies will introduce improvements in how Microsoft software activates, is validated online and behaves when tampering or hacking is detected. As Microsoft Software Protection Platform is using more CPU usage, it might be detecting some unusual activities.

This blog will cover techniques on how to identify and resolve Office installation failures. The techniques described can be applied to the installation of Office 2003-2010, and Office patches.

ENABLE VERBOSE LOGGING

The first thing to do when troubleshooting Office install failures is to ensure that MSI verbose logging is enabled. In Office 2007/2010 there is a setup.exe log file that gets created by default, but it does not give the amount of detail that is usually required to diagnose an installation failure. With verbose MSI logging enabled we will get a verbose log file for each component that Office 2007/2010 installs. We will have a verbose log for the install of the Word component, one for Excel, and so on.

To enable verbose logging you will want to set the following registry keys.

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsInstaller]
'Debug'=dword:00000007
'Logging'='voicewarmup'

If you would prefer to automate the addition/removal of these keys rather than adding them manually via regedit you can use the fixit programs from the following KB article:

http://support.microsoft.com/kb/958052
*note* This fix it will also enable verbose logging for the windows updates site but troubleshooting windows update will not be covered in this blog article.

We should also enable verbose logging for the setup.exe log as well. This is done by adding the following line to the config.xml that is in the .ww folder of the product you are attempting to install. (This does not apply to versions of Office that are earlier than Office 2007)

<Logging Type='verbose” Path='%temp%' Template='Microsoft Office Standard Setup(*).txt' />

For more information on the configuration of the config.xml see here.

PERFORM THE INSTALLATION ATTEMPT

If you are running your installation manually on the machine as a logged in user by double clicking on setup.exe then the log files will get generated in the %temp% directory of the user performing the installation.

The easiest way to get there:
Winxp-2003 = Click on start, then goto run, and type in %temp% and hit enter.
Windows Vista-Win7 = Click on start, and the type in %temp% in the search field and hit enter.

If you are running your installation via a deployment mechanism that utilizes the system account during the install, then the log files will get generated in %windir%temp.

Now that you have enabled verbose logging and know where to look for the logs, go ahead and reattempt your installation. It it failed previously, expect it to fail again but this time we are ready to capture log files that will be detailed enough to help us diagnose the failure point.

ANALYZING THE LOGS

After your install attempt you will find that you have somewhere between 1 and 20 logs from the installation attempt in your temp directory.

Here is a screenshot of the verbose logs from an install attempt from my machine.

When looking through the MSI logs we will typically want to look for a value 3 entry in the logs. Windows installer returns codes during the install which will indicate if a particular function was successful or not.

Value 1 = Success
Value 2 = Cancel
Value 3 = Error

In a good install, you would typically not see any value 3 entries in the logs.
So there are a lot of logs here to look at. I would recommend that we start with the setupexe log. This log will usually have a value 3 in it when there is a failure, but will not always be clear enough to diagnose the issue. If it doesn’t have a value 3 look for the first instance of Rolling back package. Rolling back package indicates that the Office installation had failed and now is attempting to “roll back” the installation. You should be able to identify the failure immediately above that point. Once you find the value 3 or the Rolling back package in the setup.exe log you should be able to identify which component is failing, and from there look for the particular MSI log that corresponds with that component.

There will often be more than one value 3, or rolling back package. You should focus on the first one you find.

Below you will find a couple real life examples of office installation failures and how we were able to identify the failure point.

ANALYZE LOGS EXAMPLE 1 – Proplus 2010 install
In this example, I will search the setup log for a value 3. It is not uncommon to not find a value 3 in the setup log. In this case I didn’t get a value 3 in the setup.exe log, so next I searched the setup.exe log for Rolling back package.

Here is what I found:

Error: Failed to install product: C:MSOCacheAll Users{90140000-0011-0000-0000-0000000FF1CE}-CProPlusWW.msi ErrorCode: 1603(0x643).

Log level changed from: Standard to: Verbose
Rolling back chain
08/30/2010 14:12:56 Rolling back package: ProPlusWW

This does not tell me why it failed, but it does tell me that the failure occurred during the install of the ProPlusWW.msi. Now that I know that I want to find the verbose MSI log that correlates with ProPlusWW.msi.

*note*
In cases where you know the failure is in the ProPlusWW.msi log but you don’t want to save time in finding which MSI log is for Proplus, it will usually be the largest log file.

If you don’t know which log is the correct log for the ProPlusWW.msi component, open each log one at a time and scroll to the bottom. It will indicate there what component it just attempted to install/rollback.

For example, from the bottom of the MSIb0bc7.LOG:

MSI (s) (50:CC) [14:24:12:332]: Note: 1: 1724
MSI (s) (50:CC) [14:24:12:332]: Product: Microsoft Office Outlook MUI (English) 2010 -- Removal completed successfully.

So this is the verbose MSI log for the Office Outlook MUI component and was from the rollback. (The install failure would have occurred earlier than this)
Eventually I found the ProPlus log (it was the biggest one) and the log does indicates it is the proplus log here:

******* Product: C:MSOCacheAll Users{90140000-0011-0000-0000-0000000FF1CE}-CProPlusWW.msi

I searched the log for a “value 3” and this time didn’t find one, but did see this at the bottom of the log when it ended abruptly:

MSI (s) (B0:14) [14:12:56:537]: Internal Exception during install operation: 0xc0000017 at 0x7C812AFB.
MSI (s) (B0:14) [14:12:56:537]: WER report disabled for silent install.
MSI (s) (B0:14) [14:12:56:537]: Internal MSI error. Installer terminated prematurely.

Out of memory. Shut down other applications before retrying.
MSI (s) (B0:14) [14:12:56:537]: MainEngineThread is returning 1603

Now I have something to go off of. So I take this error and search the net for articles that may help with this error.

I end up finding this article which lists my error almost verbatim, mentions a known issue with Windows installer 4.5, and an available hotfix.

Turns out that this particular machine is running WI 4.5. After installing the hotfix and rebooting, the install is successful.

ANALYZE LOGS EXAMPLE 2 - Access 2010 standalone install

In this next example, again I didn’t find a value 3 in the setupexe log, so next I searched the setup.exe log for Rolling back package.

Here is what I found:

Error: Failed to install product: C:MSOCacheAll Users{91140000-0015-0000-0000-0000000FF1CE}-CAccessRWW.msi ErrorCode: 1601(0x641).

Log level changed from: Standard to: Verbose
Rolling back chain
12/14/2010 12:06:05 Rolling back package: AccessRWW

Again, this does not tell me why it failed, but it does tell me that the failure occurred during the install of the AccessRWW.msi. Now that I know that I want to find the verbose MSI log that correlates with the AccessRWW.msi.

Looking through the log files I find the one for the AccessRWW.msi:

******* Product: C:MSOCacheAll Users{91140000-0015-0000-0000-0000000FF1CE}-CAccessRWW.msi

I search it for value 3 and found:

CAInitSPPTokenStore.x86: OMSICA : Initializing CustomAction CAInitSPPTokenStore.x86
CAInitSPPTokenStore.x86: Error: Failed to initialize the SPP Token store. HResult: 0x80070057.
CAInitSPPTokenStore.x86:
MSI (s) (2C:D0) [10:12:03:911]: User policy value 'DisableRollback' is 0
MSI (s) (2C:D0) [10:12:03:911]: Machine policy value 'DisableRollback' is 0
Action ended 10:12:03: InstallExecute. Return value 3.

This was resolved by ensuring that the network service is running, and that the following reg keys were present after ensuring the network service was running.

HKEY_USERSS-1-5-20
AND
HKEY_USERSS-1-5-19

ANALYZE LOGS EXAMPLE 3 - ProPlus 2010

In this next example, I did find a value 3 in the setupexe log.

Office software protection platform folder

MSI(ERROR): 'Error 1304. Error writing to file: C:WINDOWSwinsxsPoliciesx86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff8.0.50727.4053.policy. Verify that you have access to that directory.'
Log level changed from: Standard to: Verbose
Not showing message because suppress modal has been set. Title: 'Setup', Message: 'Error 1304. Error writing to file: C:WINDOWSwinsxsPoliciesx86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff8.0.50727.4053.policy. Verify that you have access to that directory.'
Message returned: 2
MSI(USER): 'Are you certain you want to cancel?'
MSI(INFO): 'Action ended 14:03:01: InstallExecute. Return value 3.'

When you do see a value 3 in the setup.exe log it will sometimes give you enough information to resolve the issue without needing to look at the verbose MSI log. In this case the verbose MSI log simply repeated what we found in the setup.exe log as seen below.

MSI (s) (20:DC) [14:02:56:138]: Product: Microsoft Office Professional Plus 2010 -- Error 1304. Error writing to file: C:WINDOWSwinsxsPoliciesx86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff8.0.50727.4053.policy. Verify that you have access to that directory.

Error 1304. Error writing to file: C:WINDOWSwinsxsPoliciesx86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff8.0.50727.4053.policy. Verify that you have access to that directory.
Are you certain you want to cancel?
MSI (s) (20:DC) [14:03:01:646]: User policy value 'DisableRollback' is 0
MSI (s) (20:DC) [14:03:01:646]: Machine policy value 'DisableRollback' is 0
Action ended 14:03:01: InstallExecute. Return value 3.

In this case we should consider updating .net framework, and verifying the permissions in c:windowswinsxs

-BELOW ARE A FEW KNOWN ERRORS FROM VERBOSE LOGS AND POSSIBLE RESOLUTIONS TO TRY-

*NOTE*
Some of these suggestions discuss working with the registry.
Important- Serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows

ERROR 1935

Error 1935. An error occurred during the installation of assembly component {89EDD3A9-944B-3257-8484-D6EB6A00DDF5}. HRESULT: 0x80070003. assembly interface: IAssemblyCache, function: CreateAssemblyCacheItem, assembly name: Microsoft.VC90.ATL,version='9.0.30729.4148',type='win32',processorArchitecture='amd64',publicKeyToken='1fc8b3b9a1e18e3b'

Protection

MSI (s) (1C:9C) [10:14:26:628]: User policy value 'DisableRollback' is 0
MSI (s) (1C:9C) [10:14:26:628]: Machine policy value 'DisableRollback' is 0
Action ended 10:14:26: InstallExecute. Return value 3.

Possible solution(s)

-This most commonly occurs due to issues while upgrading Office. First thing to try is to remove the previous version of Office prior to installing new version. You can remove the previous version of Office automatically using the appropriate fix it from KB290301. After removing the previous version of Office, then attempt to install the newer version of Office.

-The fix it from the following article. http://support.microsoft.com/kb/946414

ERROR 1913

Error 1913: Setup cannot update file C:/windows/win.ini.
Verify that the file exists in your system and that you have sufficient
permissions to update it

Possible solution(s)

There is a known issue with Trend Micro that could be causing this issue and preventing the Office install.
If using Trend Micro, consider uninstalling it, rebooting and trying the install again.

ERROR 1714

Error 1714. Setup cannot remove the older version of Microsoft Office Product_Name 2007. Contact Microsoft Product Support Services (PSS) for assistance. For information about how to contact PSS, seeC:DOCUME~1<username>LOCALS~1TempSetup00000d64PSS10R.CHM.

Possible solution(s)

-Remove the previous versions of Office first if you are attempting to perform an upgrade. (Office can be removed with the Fix Its from KB290301)
-Perform a side-by-side installation rather than upgrading. (Customize button)

ERROR 1719

Error 1719. Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact support personnel for assistance

Possible solution(s)

-Reg keys could be corrupt or incorrect at

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSIServer

Export from a known good machine that uses the same OS and msiexec version.
Backup and then delete existing msiserver key on the bad machine under:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesmsiserver
Import the reg file from the known good machine.
Reboot, and reattempt install

-http://support.microsoft.com/kb/324516
-http://support.microsoft.com/default.aspx?scid=kb;en-us;315346&Product=winxp#kb4

ERROR 1406

'Error 1406.Setup cannot write the value to the registry key CLSID{13DE4A42-8D21-4C8E-BF9C-8F69CB068FCA}. Verify that you have sufficient permissions to access the registry or contact Microsoft Product Support Services (PSS) for assistance. For information about how to contact PSS, seeC:UsersADMINI~1AppDataLocalTempSetup00000e64PSS10R.CHM.'

Log level changed from: Standard to: Verbose
MSI(INFO): 'Action ended 20:24:59: InstallExecute. Return value 3.'

Possible solution(s)
This error indicates incorrect registry permissions. In the example above we would find incorrect reg perms on
HKCRCLSID{13DE4A42-8D21-4C8E-BF9C-8F69CB068FCA}

ERROR 1920

Error 1920. Service 'Office Software Protection Platform' (osppsvc) failed to start. Verify that you have sufficient privileges to start system services.

Log level changed from: Standard to: Verbose
MSI(INFO): 'Action ended 14:15:40: InstallExecute. Return value 3.'

Possible solution(s)
This error indicates possible incorrect permissions on the OfficeSoftwareProtectionPlatform folder, or incorrect permissions on HKCRAPPID

1. To resolve this issue, give the Network Service account full control on the 'OfficeSoftwareProtectionPlatform' folder.
http://support.microsoft.com/kb/2401987

2. To resolve this issue, compare the rights on HKCRAPPID from a good machine, with the problem machine. Try granting “RESTRICTED” the following permissions: Query Value, Enumerate Subkeys, Notify, Read Control

ERROR - IHxRegisterSession::CreateTransaction() returned 8004036e.

IHxRegisterSession::CreateTransaction() returned 8004036e.
BeginTransaction() ERROR: Attempt failed because another transaction was running.
Trying to Rollback current transaction ({2318682E-D486-40D6-8530-80CEEA1A16B5})
IHxRegisterSession::ContinueTransaction() returned 80004005.
BeginTransaction() ERROR: Could not restart current transaction.
BeginTransaction() ERROR: Could not Rollback current transaction. HelpFile registration will abort.
Registration session {2318682E-D486-40D6-8530-80CEEA1A16B5} was *not* created.
Action ended 14:30:54: InstallFinalize. Return value 3.

Possible solution(s)

-http://support.microsoft.com/kb/927153

Office Software Protection Platform Folder

ERROR: FAILED TO REGISTER PLUGIN. HRESULT: 0x80070005

MSI (s) (08:6C) [12:32:40:502]: Invoking remote custom action. DLL: C:WINDOWSInstallerMSI4D4.tmp, Entrypoint: CAInstallSppPlugin
CAInstallPlugin.x86: OMSICA : Initializing CustomAction CAInstallPlugin.x86
CAInstallPlugin.x86: Registering PlugIn 'C:Program FilesCommon FilesMicrosoft SharedOfficeSoftwareProtectionPlatformOSPPOBJS.DLL' 'C:Program FilesCommon FilesMicrosoft SharedOfficeSoftwareProtectionPlatformosppobjs-spp-plugin-manifest-signed.xrm-ms'
CAInstallPlugin.x86: Error: Failed to register plugin. HResult: 0x80070005.
CAInstallPlugin.x86:
MSI (s) (08:58) [12:32:42:830]: User policy value 'DisableRollback' is 0
MSI (s) (08:58) [12:32:42:830]: Machine policy value 'DisableRollback' is 0
Action ended 12:32:42: InstallExecute. Return value 3.

Possible solution(s)

Policy set on the problem machine (local or through GPO) that is misconfigured.

Opened Gpedit.MSC
Computer configuration/Windows Settings/Security Settings/local policies/user rights assignment
Ensure that everyone has rights on Bypass traverse Checking. (Everyone would be listed by default)

ERROR - Error 0x80070005: CAQuietExec Failed

Office Software Protection Platform Removal Software

CAQuietExec: 'wevtutil.exe' im 'C:Program FilesMicrosoft OfficeOffice14BCSEvents.man'
CAQuietExec: The publishers and channels are installed successfully. However, we can't enable one or more publishers and channels. Access is denied.
CAQuietExec: Error 0x80070005: Command line returned an error.
CAQuietExec: Error 0x80070005: CAQuietExec Failed
CustomAction RegisterEventManifest returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (88:04) [15:15:03:285]: User policy value 'DisableRollback' is 0
MSI (s) (88:04) [15:15:03:285]: Machine policy value 'DisableRollback' is 0
Action ended 15:15:03: InstallExecute. Return value 3.

Possible solution(s)

This issue can occur because permissions have been incorrectly set on the folder: C:WindowsSystem32winevtLogs
Grant “everyone” full rights to that folder, and reattempt the install. If this is successful you can remove the everyone group afterwards.

ERROR - Error 0x800706b5: CAQuietExec Failed

CAQuietExec: 'wevtutil.exe' im 'C:Program FilesMicrosoft OfficeOffice14BCSEvents.man'
CAQuietExec: The publishers and channels are installed successfully. However, we can't enable one or more publishers and channels. The interface is unknown.
CAQuietExec: Error 0x800706b5: Command line returned an error.
CAQuietExec: Error 0x800706b5: CAQuietExec Failed
CustomAction RegisterEventManifest returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (6C:84) [10:10:59:733]: User policy value 'DisableRollback' is 0
MSI (s) (6C:84) [10:10:59:733]: Machine policy value 'DisableRollback' is 0
Action ended 10:10:59: InstallExecute. Return value 3.

Possible solution(s)

This issue can occur if the Windows Event Log service is not running.
Click on start, search and type in services.msc and hit enter.
Scroll down to the Windows Event Log service, and ensure it is set to automatic. If it is not running right click on it and choose start.
If you get an error like the following:

Error 4201: The instance name passed was not recognized as valid by a WMI data provider.

Then please check the permissions on 'c:windowssystem32logfileswmiRTbackup'

Office Software Protection Platform Removal Tool

If the system account doesn’t have full control, grant the system account full control and reboot.
After reboot check and see if the Windows Event Log service is started in services.msc. If it now started correctly attempt your Office 2010 install again.

This is a living blog and will be updated with more known problems/solutions over time.