|Windows Installer Processes Your Windows 8 Appx Packages… SHHHHHHH!|
|Written by Darwin Sanoy|
|Friday, September 21, 2012 8:45am|
If you visit the MSI SDK page, there is no “What’s New” section beyond version 5 which was released with Windows 7, so obviously there is nothing new in Windows Installer for Windows 8, right? Nothing new for .MSI packages that is. It has recently come to light in our labs that Windows Installer is secretly doing double duty to process the new Appx packages which are responsible for installing Windows 8 Metro WinRT Store Apps. Why do I say “secretly”?I say secretly because Windows Installer does not log any of it’s Appx activities when verbose MSI logging is set to maximum in the registry. Nothing is logged in the event log by the Windows Installer event source (MsiInstaller) either. From this I gather that the historic Windows Installer group policies and logging should be thought of as “Windows Installer for .MSI”
Since I was unable to get a honest confession from MSIEXEC through it’s built-in logging policy, I enabled debug messages and attempted to watch it’s debug messages – all I got was crickets – not a single log line.
To be clear, there is no .MSI file in the mix here – .appx files do not contain them (that I’ve seen so far). MSIEXEC.EXE appears to be directly processing the appx installation directives from the file called AppXManifest.xml that is included in every appx package.
Procmon reveals the dual-life of MSIEXEC.EXE as it moonlights doing Appx installs.
The following logging data was taken from a Windows 8 Store install of the Wikipedia app:
The above figure shows five Appx specific DLLs loaded in the msiexec process that I was observing.
The above shows msiexec.exe writing the application files to one of the Win8 Metro WinRT Store App storage locations. Although I did not include all the records here, it is evident that it copied all the application files. As a part of the new Windows 8 application provisioning model, the locations where apps are stored are all secured against regular user profiles – including administrator. Notice in the first screen shot that this is the msiexec service running (the “/V” on the command line gives it away) – as usual it runs with SYSTEM permissions.
As the intent of this article is to highlight the involvement of MSIEXEC.exe, it does not show the many other processes involved in the store transaction. Some of the other processes include:
WWAHost.exe – the service which coordinates the store transaction, including downloading content from the store.
WSHost.exe – the process that runs on the user desktop when they browse the store.
To be fair, msiexec.exe writes to %PROGRAMDATA%\Microsoft\Windows\AppRepository\edb.log, but it is in an unreadable binary format.
I am going to be digging much deeper into these processes over the coming months – if you’re interested, be sure to subscribe to our updates !