Yes, yet another question about the auto-repair functionality. Yes, I have already searched for information about this in these forums and InstallSite's. Nothing's worked, so I thought I'd post my specifics and see what people might know.
My problem occurs after running a major upgrade of my product. Call it Version X to Version Y. The first time the user goes to launch the application from a shortcut, WI starts its auto repair sequence, then successfully launches the app. Subsequent launches work fine.
The Event Viewer mentions two items: 1) Detection of product '', feature '', component '' failed. The resource C:\Windows\Fonts\Stencil.ttf' does not exist 2) Detection of product '', feature '' failed during request for component ''
Well that's easy, you say, just go check for stencil.ttf as well as the key path for component C. They're both there. The stencil is marked to install to FontsFolder, as per the Windows Installer help file. Component C's keyfile is the main exe for our program, and it is definitely present before launch. It also has a couple registry keys under HKLM\Software... that are also present before launching.
Rebooting after upgrading but before launch does not help.
I've found information about the MSXML4 Major Upgrade bug, and previously fixed it - this isn't that. I've tried upgrading, re-adding the MSXML4 files manually, then launching, and I still get repair behavior.
I've also found info about how Per-User reg keys can cause this issue. There are no per-user reg keys in my install.
The event log information is indicating that component contains an advertised entry point (advertised shortcut, COM CLSID in the Class table, file extension in the Extension table) that was invoked. When this is invoked, Windows Installer checks all component keypaths in the related feature . When it tried to verify the keypath for component , it did not find the file C:\Windows\Fonts\Stencil.ttf and kicked off the auto repair to install this file.
Is the font file present before launching the application after the upgrade?
This issue could be caused due to the major upgrade not reinstalling the font file because it doesn't believe it needs to be installed with the new product, and is subsequently uninstalled with the old product. This is the most common cause of auto repair after major upgrades (this behavior is related to the same issue encountered with MSXML 4 and Win32 SxS assemblies or .NET assemblies installed to the GAC).
