Thursday, December 06, 2012 12:34 AMHello,
Microsoft provides the following KB articles to determine the service pack for Office products.
http://support.microsoft.com/kb/2121559 (Office 2010)
http://support.microsoft.com/kb/928116 (Office 2007)
http://support.microsoft.com/kb/821549 (Office 2003)
Method 2 in each of the articles specifies how to determine the version using the properties of the executable file. This information is misleading.
For example: Consider Excel 2010. Per KB2121559, below are the file versions.
2010 Office product name File name Original version Service Pack 1 (SP1)
Microsoft Excel 2010 EXCEL.exe 14.0.4756.1000 14.0.6024.1000
Whenever security patches are released, the versions of the core files are bumped up. Upon applying patch for MS12-030 (http://support.microsoft.com/kb/2597166) on Office 2010, version of EXCEL.exe is updated to 14.0.6117.5003 on both Microsoft Excel 2010 (SP0/Original) and Microsoft Excel 2010 SP1.
So now we have a Microsoft Excel 2010 SP0 installation where Excel.exe is at version 14.0.6117.5003 (> 14.0.6024.1000) which per the KB indicates that it is at SP1. This is incorrect since SP1 has not been applied, only the security patch for MS12-030 was applied.
This problem is across the board for all Office applications including Compatibility packs. Security patches for most Office products update the core Office files (excel.exe, winword.exe, powerpnt.exe) to the same version for different service packs.
Is there a better way to programatically determine the service pack of a particular Office application since the version information does not seem to be accurate?
Friday, December 07, 2012 2:36 AMModerator
Thanks for posting in the MSDN Forum.
I will involve some experts into your issue to see whether they can help you out. There might be some time delay, appreciate for you patience. Have a good day,
Tom Xu [MSFT]
MSDN Community Support | Feedback to us
Develop and promote your apps in Windows Store
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Friday, December 07, 2012 8:18 AMModerator
My suggestion is to test registry key.
Take Office 2010 as example, SP1 corresponds to kb2460049, it writes to registry:
Depends on bitness of Office 2010, it could be under alternative path: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
In future, if there's SP2, we just add one more test path.
Forrest Guo | MSDN Community Support | Feedback to manager