/build/static/layout/Breadcrumb_cap_w.png

Why is Windows Installer accessing the source

Hi folks,

I've the following problem. Some packages authored with wise package studio 5.6, have the problem that they wan't to access the source msi when self healing the HKCU Component. If already checked the following items:

+That The MSIs all validate fine - which they do.
+All HKCU Keys are in the Top Level Feature which only contains the HKCU Component all other components features are located below that Feature, so the featurelevel repair should only re-install the HKCU Keys, which Windows Installer retrieves from the cached MSI.
+The cached MSI is there and ok.
+MSI Spy only lists the HKCU component as missing when I run it under a new users account, which is the desired effect. Re-installing the missing component via MSI Spy doesn't trigger Windows Installer to ask for the source.
+All non versionable files have a hashcode entry in the MSIFileHash table.
+The windows installer event entry: Event ID: 1001
Description: Detection of product "{4ED0C75A-8BC5-4520-B9C7-76968FD5677F}", feature "blablabla" failed during request for component "" - displays NO component ID. So obviously windows installer has no clue what has is missing.

Is there any way to use the windows installer logging policy to debug this issue (voicewarmup), I mean what entries in this log should I look out for?

0 Comments   [ + ] Show comments

Answers (14)

Posted by: AngelD 16 years ago
Red Belt
0
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
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
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.
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
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.
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
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?
Posted by: AngelD 16 years ago
Red Belt
0
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.
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
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.
Posted by: AngelD 16 years ago
Red Belt
0
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?
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
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.
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
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.
Posted by: nheim 16 years ago
10th Degree Black Belt
0
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
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
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).
Posted by: nheim 16 years ago
10th Degree Black Belt
0
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
Posted by: nheim 16 years ago
10th Degree Black Belt
0
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
Posted by: PackadeJack 16 years ago
Senior Yellow Belt
0
Thx for the code.

Well I guess so, MSI validation reported no errors and I can see no entries marked red.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ