Windows Installer log file preservation

[turquoiseowl]

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.

[sorinj]

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]

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 /log parameter 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 /log switch would appear to be incorrect, and should be something like /L*vx : https://docs.microsoft.com/en-us/windows/win32/msi/command-line-options

I'm removing the switch entirely from my repo so as to fall back on the other mechanisms.

Thanks.

[sorinj]

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 /log command line argument, it looks like /log is supported in the version 3.0 of MSI
Should we be doing something else?

[turquoiseowl]

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]

Understood. Would something such as a registry option to disable the MSI logging work for you?

[turquoiseowl]

Yes, that would be great.

[sexysue1972]

@#suesdefault

[sexysue1972]

View my script on TradingView

[sexysue1972]

#367

[Rock141]

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.

Fix support

[mohammadkarimy271]

maryamhoseni097.sdam@gmail.com
mohammadkarimy271