This repository was archived by the owner on Aug 4, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 4, 2025. It is now read-only.
Windows Installer log file preservation #201
Description
From what I can tell, Omaha enables msiexec log file output - for example to the following temporary path:
"C:\Program Files (x86)\Google\GoogleUpdate\Install\{B5F9BEF5-1D04-4FF5-AD92-4D1E21D76F51}\xyz.msi.log"
However, the containing folder is then deleted along with the log file during cleanup, AFAIK.
Is there a switch I'm missing to have this log file preserved. That's what I would like in order to diagnose problematic installs.
If not, what is the point in generating the msi log file which does tend to slow thing down?
Thanks a lot.
Reacted by Muhamad Mansur Bin Abdul Talib and mohammadkarimy271
Reacted by mohammadkarimy271
Activity
sorinj commentedon Nov 27, 2019
The log file is still accessible before Omaha cleans up the directory. I believe the intention was to collect a log file, and retrieve it for analysis before Omaha exited and eventually uninstalled itself.
turquoiseowl commentedon Nov 27, 2019
Hmmm, I guess you'd need to be quick to get the log file between it being closed and cleaned up.
After a bit more investigation, it transpires there are numerous ways to instruct Windows Installer how to log: https://docs.microsoft.com/en-us/windows/win32/msi/normal-logging
The current explicit
/logparameter has the effect of overriding any of the other indirect methods the developer might choose, e.g. via the Windows machine profile, or indeed a property in the MSI itself.Furthermore, the
/logswitch would appear to be incorrect, and should be something like/L*vx: https://docs.microsoft.com/en-us/windows/win32/msi/command-line-optionsI'm removing the switch entirely from my repo so as to fall back on the other mechanisms.
Thanks.
sorinj commentedon Nov 28, 2019
What scenario are you trying to debug using the msi log? Generally speaking, Omaha will clean up its install directory when it instantiates an InstallManager object: https://github.com/google/omaha/blob/master/omaha/goopdate/install_manager.cc#L75
I expect that the directory will be deleted as well when Omaha uninstalls.
In the case of an interactive install, Omaha will keep its UI up, therefore, the log file could be retrieved before the UI is dismissed. In the case of an update, then the log file will be there until the next update attempt. I may be missing some other execution flow though.
Re: the MSI
/logcommand line argument, it looks like /log is supported in the version 3.0 of MSIShould we be doing something else?
turquoiseowl commentedon Nov 28, 2019
I'm running some automated functional tests as part of a build and release pipeline. They simulate the full lifecycle of the app: install, run some tests, then uninstall. At the moment I'm getting occasional install issues and need the msi log file to diagnose what went on.
Yes, sorry, I missed those later command-line options so scrub what I said about the /log switch.
I would still suggest it is not ideal that Omaha overrides any environmental settings for msi logging and then ensures the log file it specifies is deleted.
Cheers.
sorinj commentedon Dec 1, 2019
Understood. Would something such as a registry option to disable the MSI logging work for you?
turquoiseowl commentedon Dec 3, 2019
Yes, that would be great.
sexysue1972 commentedon Feb 15, 2022
sexysue1972 commentedon Feb 15, 2022
View my script on TradingView
sexysue1972 commentedon Feb 15, 2022
#367
Rock141 commentedon Oct 1, 2022
Fix support
mohammadkarimy271 commentedon Jul 13, 2023
maryamhoseni097.sdam@gmail.com
mohammadkarimy271