Software Deployment

Sure!
Enable verbose logging and trigger the repair.
In the log file (%temp%) folder of the user who triggered the repair check the component state.

Have a look at John's blog for more information regarding "Understanding the Windows Installer Logs"
http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!213.entry

Ok so the following entry means the "Current User" component is missing and the containing feature will get a feature level repair.
MSI (s) (58:E4) [16:00:24:121]: Feature: HKCU; Installed: Local; Request: Null; Action: Null
MSI (s) (58:E4) [16:00:24:168]: Component: CurrentUser; Installed: Local; Request: Null; Action: Local

so far so good

What I am curios about is the following entry:

MSI (s) (58:E4) [16:00:24:121]: Feature: Feature8; Installed: Local; Request: Reinstall; Action: Reinstall

This is the entrypoint feature that gets triggered by the shortcut. And a few lines below that:

MSI (s) (58:E4) [16:00:25:777]: Executing op: ChangeMedia(,MediaPrompt=Please insert the disk: [ProductName] LABEL,MediaCabinet=Cabs.w1.cab,BytesPerTick=32768,CopierType=2,ModuleFileName=1\FileNET IDM Desktop 4.msi,,,,,IsFirstPhysicalMedia=1)
MSI (s) (58:E4) [16:00:25:777]: Executing op: FileCopy(SourceName=IDMCfg.exe,SourceCabKey=IDMCfg.exe,DestName=IDMCfg.exe,Attributes=1024,FileSize=1034040,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=401.2006.243.832,Language=1033,InstallMode=61210624,,,,,,,)
MSI (s) (58:E4) [16:00:25:777]: File: C:\Program Files\Filenet\IDM\IDMCfg.exe; Overwrite; Won't patch; Existing file is corrupt (invalid checksum)
MSI (s) (58:E4) [16:00:25:777]: Resolving source.

Windows installer thinks that the checksum is incorrect and tries to reinstall the file. Strangely though this will hapen with all entrypoint not matter which one gets triggered. Has anyone ever had this issue with Wise Package Studio? I thought that Windows Installer only verifys checksums on unversionable files. There is no checksum for IDMCfg.exe in the MSIFileHash Table and the entries in the file table (Version, Size) are correct I checked that manually.

But why does this only happen when I try to launch the program as another user. Presumably Windows Installer will check the MSIs keypaths first and then afterwards verify the checksums, otherwise this would have also happened under the user account the MSI was installed initially.

???

P.S. I am currently downloading MsiFiler.exe and will try to recreate the MSIFileHash and Version Information in the File table.

I've now created an administrative image and recreated the file version entries and the MSIFileHash table using MsiFiler.exe and tried a reinstall on a clean machine (I am using VMWare), with same effect. Windows Installer still wants to Reinstall the .exe File in the entry point feature.

Ok, so I've tracked down the problem. The problem that Windows Installer needs the source for repair operations that normally would not require access to the source (HKCU Reg Keys, ini Entries) seems to be bound to the fact that this is only caused by a shortcut who is also advertising an extension, can anyone tell my why this could be?

Sorry but I'm not able to follow you.
Are you saying due to a component holding the IDMCfg.exe file, advertised shortcut for it and Extension table entries you get this repair issue?

You need to provide more details on your package; feature/component structure and more related verbose log entries that are related.

As the event viewer didn't provide the ComponentId for the component that triggered the self-check or repair it seams there may be some table relations regarding the "missing" component id in the MSI that is not fully correct. Have you validated your package?

I'm only able to gues with the information you've provided so far.

If you give me your private email then I'll send you a zipped msi of WinZip 8.1 that has the same problem. Everything works fine until I invoke an entry point via an extension although the .msi validates fine. May I am just to blind to see the cause.

Allthough WinZip 8.1 is very old it was quite easy to capture when I did it years ago so I don't really think the error lies in this MSI.
I'm abit curious why you get an empty reference for the component during self-check.

Are you testing this on a clean machine?

Yes its a clean VMWare Image, but that I had that same issue years ago. I even was in another company back then. The only thing that stayed the same was the Wise Package Studio Version 5.6. So we have different sources, different VMWare Images but the same error. When I manually create a WinZip Package then everything is working fine (by creating a blank msi and creating the features, components, etc. myself and test it on the same machine!), so I guess the error lies within Package Studio doing something wrong after running Setup Capture. WinZip is not the problem either, as said I worked around the problem by creating the package myself without using Setup Capture but of course the are other, bigger software products where this would be way to much work. The point is that I cannot determine what the difference between MY version and the version Setup Capture created is, that is causing the problem. Of course I also tried to recapture the installation ending up with same results, before I delved deeper into the msi trying to find the origins of this issue. As soon as the MSI is entered using an extension entrypoint the entrypoint feature will get a ReInstall and the eventlog entry shows up where the componentID is null or "". I already posted my problem years ago but that was as mentioned before in another company and I forgot my password and cannot access my old email for I registered with my office email.

And yes the MSI validates fine. The only warning I got is that the icon for WinZip help is in an unsupported way as the icon path leads to the help file and not to a .exe or .ico file. But I've got the same error on the working manually created MSI and it's working fine. Also when I take the help shortcut in the broken MSI the msi repairs and opens up without asking for the source so this cannot be the root cause.

Hi Jack,
the problem apparently lies in the versioning and/or hashing of this file.
So please do the following checks:
See, if this file has correct version information (i doubt it).
Remove the version info in the File table and generate an entry in the MsiFileHash table.
Test and see what happens.
I had issues like that on several vendor MSI's in the past.
Regards, Nick

Hi nheim!

As I posted earlier, I've already tried to regenerate the version and hashing informations with the MsiFiler tool provided in the MS Platform SDK, with same results and the first thing I did was to check the version information which was correct. I got a copy of Wise Package Studio 7.0 SP3 today and will try to repackage WinZip again and see if I'll still run into the same problems.

You've mentioned that I should delete the version information and add an entry in the hashingtable instead, but how can I manually create the filehash for a single file? MsiFiler will recreate all hashing information as well as the version information and won't let me deciede what to add where (because the .exe has version information it will not add a hash).

Hi Jack,
use this script from Kim, here: http://www.appdeploy.com/messageboards/fb.asp?m=27809
to generate the hashes. Then remove the version info for the particular file the File table and create an entry in the MsiFileHash table.
That should do the trick.
Regards, Nick

Hi Jack,
Another question: Are all the feature and components associated correct with the each other?
Check for bogus entries in this tables.
Regards, Nick

Thx for the code.

Well I guess so, MSI validation reported no errors and I can see no entries marked red.