Edited by kenzo22, 05 August 2010 - 08:36.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Unknown source error
Started by
kenzo22
, Aug 05 2010 02:11
9 replies to this topic
Posted 05 August 2010 - 02:11
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
Posted 05 August 2010 - 10:29
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
You can sue the registry key to generate a log file, see http://www.msifaq.com/a/1022.htm
Stefan Krüger
InstallSite.org twitter facebook
Posted 06 August 2010 - 03:54
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.
Posted 08 August 2010 - 17:21
Maybe your DLL depends on a temporary file (if your setup is a self extracting exe and you didn't chace the files permanently)
Stefan Krüger
InstallSite.org twitter facebook
Posted 09 August 2010 - 07:17
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?
Posted 09 August 2010 - 20:31
Just want to check whether the call you are making requires admin rights? If so, is it a properly scheduled deferred mode custom action?
Regards
-Stein Åsmul
-Stein Åsmul
Posted 10 August 2010 - 03:22
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?
Posted 10 August 2010 - 15:54
QUOTE |
my setup is indeed a self extracting exe |
Where does it extract the setup files? And are they deleted after the setup finished, or are they available permanently?
QUOTE |
many "The file represented by File table key 'blablabla' has no eligible binary patches", does this matter? |
No, that's unrelated.
Stefan Krüger
InstallSite.org twitter facebook
Posted 11 August 2010 - 03:41
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.
Posted 16 August 2010 - 05:11
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.