9 replies to this topic

[kenzo22]

Hello guys, I met a strange problem these days, I have been developing a Basic MSI project. My exe installer can successfully install my application, however, after the installtion, if I choosee repair from the "control panel", it will pop up error windows"Unknown source 9", see attached images, and this repair will not produce log, weird...I have also checked the event viewer, it only says "Product: My product -- Configuration failed", its event ID:11729, I can find no support information from Microsoft... The strange thing is when I lauch the installer and choose repair, everything is ok, does anybody met this issue before, I am really confused

Attached Images

• 

Edited by kenzo22, 05 August 2010 - 08:36.

[Stefan Krueger]

The message suggests that it's caused by a DLL custom action. Are you calling a DLL, and is it in the required location at the time?
You can sue the registry key to generate a log file, see http://www.msifaq.com/a/1022.htm

[kenzo22]

Hi Stefan, yes, some of my custom actions are calling DLL to do the work. I am wondering what's the difference between "repair in control panel" and "choose repair when I launch the installer", why the later repair success while "repair in control panel" fail? I have defined MSI command line Arguments in Release View "/l*v "%temp%\MyInstaller.txt"", so regularly the installtion process will produce this log file(choose repair in the installer will produce this log file), "repair in control panel" doesn't produce this file, however, it does produce a file named "MSI23959.LOG", I think we can refer to this log file.

[Stefan Krueger]

Maybe your DLL depends on a temporary file (if your setup is a self extracting exe and you didn't chace the files permanently)

[kenzo22]

Stefan, my setup is indeed a self extracting exe, you mentioned temporary file, can you suggest me how to check whether this is the root cause, I have searched a lot in the verbose log file and found many "The file represented by File table key 'blablabla' has no eligible binary patches", does this matter?

[Glytzhkof]

Just want to check whether the call you are making requires admin rights? If so, is it a properly scheduled deferred mode custom action?

[kenzo22]

Yes, two of my custom actions(httpcfg and netsh) are used for reserving ports, so they require admin rights. I have defined them "Deffered execution in system context". For the httpcfg one, scheduled it "After WriteRegistryValues", for the netsh one scheduled it "After PublishsFeatures", what's your opinion?

[Stefan Krueger]

[kenzo22]

I have defined the "cache path" in release view as "[LocalAppDataFolder]Downloaded Installations\Myproduct", and also I have created a custom action to remove cache package with the conditon "REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE". So the files extracted from exe(an MST file and an MSI file) will be removed only on uninstall.

[kenzo22]

I finally find the root cause of this problem, I think this mistake is brought by InstallShield, see the post here http://community.fle...p?t-133996.html , when I add few new custom actions, InstallShield moves the custom action DLLWrapCleanup around, I found two of my custom actions are scheduled behind DLLWrapCleanup(I believe that's not my original schedule), when I schedule the CA DLLWrapCleanup as the last CA, the problem resolved... thanks all you guys for supporting.