Windows installer logs are usually kept in the temp folder, you can get to this by going to run or an explorer bar and type the location as%temp%.The default folder for this is: C:UsersAppDataLocalTempTo enable Windows Installer logging yourself, open the registry with Regedit.exe and create the following path and keys: HKEYLOCALMACHINESoftwarePoliciesMicrosoftWindowsInstallerRegSZ: LoggingValue: voicewarmupxThe letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter's actual function is as follows for MSI version 1.1:v - Verbose outputo - Out-of-disk-space messagesi - Status messagesc - Initial UI parameterse - All error messagesw - Non-fatal warningsa - Start up of actionsr - Action-specific recordsm - Out-of-memory or fatal exitinformationu - User requestsp - Terminal properties+ -Append to existing file! - Flush each line to the logx - Extra debugging information. The 'x' flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.' ' - Wildcard, log all information except for the v and the x option. To include the v and the x option, specify '/lvx'.Note This should be used only for troubleshooting purposes and should not be left on because it will have adverse effects on system performance and disk space.
Each time you use the Add/Remove Programs tool in Control Panel, a new Msi.log file is created.Please note that the above is just for MSI files or setups that take advantage of the Windows Installer. Some others will also create log files either in the temp folder, their application directory or the root of the hard drive. There is no one answer fits all. You can also have the installer write an installation log wherever you like, as needed, without modifying the registry. Run the installer msiexec from the command line with the /L option. For example, msiexec /i C:UsersmyusernameDownloadssomepackage.msi /L.v install.txtThis will run the install script and write all logging info (verbose) to the file install.txtThe options for the /L flag are: i: Logs status messages.w: Logs nonfatal warnings.e: Logs all error messages.a: Logs startup of actions.r: Logs action-specific records.u: Logs user requests.c: Logs initial user interface parameters.m: Logs out-of-memory.p: Logs terminal properties.v: Logs verbose output.
The reason we can't set the log file location inside WIX is because we need to tell MSIEXEC where to write the log file to before the windows installer engine actually starts executing the MSI. To fix this, one thing that you can do is to add a custom action and copy the log. These tips aren’t specific to WiX, that’s just the technology I’m familiar with. The first thing you should try is to add the log switch when you run your installer. To do this, open a command prompt in the directory where your MSI file is located and run it with the following parameters: msiexec yourinstaller.msi /L.v install.log.
To use v, specify /L.v.+: Appends to existing file.!: Flushes each line to the log.: Logs all information except for the v option. This is a wildcard.Source:Although the Microsoft support page references Windows XP, I have confirmed that this works for Windows 7.
![]()
Burn provides Variables to the paths to all log files, including it'sown log file. For example, the wixstdba code uses the Variable to provide alink on the failure page.
Your BA could do other things.Note: the log filenames from a Bundle are designed to be prettyself-explanatory and are stored in a safe location in%TEMP% that persistsacross reboots. You may be trying to do something more.2a. Just makes Windows Installer really slow and the 'x' is reallyonly interesting for debugging patch issues. The user can set 'x' via thecommand-line to Burn but I don't think a BA can set it.
I haven't tried.2b. Burn should respect the 'x' if it is in the logging policy so loggingpolicy may work.On Fri, Jun 15, 2012 at 11:40 AM, Don Walker wrote: I've found a number of topics about log file location and some topics about logging detail levels by searching the mail list and the bug tracker. I still don't know how to get logging working the way I want so here we go again. The Windows Installer properties that interact with logging are MsiLogFileLocation and MsiLogging. They can be used to configure logging the way I want for Msi files run directly from Windows Installer. The main problem I have with using these properties is that they are only supported in Windows Installer 4.0 and up.
This would require upgrading all of my Windows XP customers to Windows Installer 4.5. A detailed discussion of the configuration issues follows. The question that applies to the entire discussion is: Is there any way to do this without Windows Installer 4.5 or newer?
1. Log file location - It is important for support purposes that log files from failed installs be saved to known safe locations.
The TEMP directory is not a safe location. The standard msi log file name is meaningless. The IT guys I deal with may be calling me for support several days after they encountered the problem.
I've implemented custom actions that copy the Msi log file to a known safe (and clearly named) location if the install fails or is cancelled. This works both when the msi is run directly or when it is run as part of a bundle. The log file that I don't have any solution for is the Burn bundle log. Is there any way to copy the bundle log when a bundle fails? Changing the location would work as well. 2. Since I'm currently a beginner with Windows Installer I have my log level detail set to 'voicewarmupx!'
![]()
By setting the MsiLogging property. This works when I run the msi directly. When I run it as part of a bundle Burn is overriding my detail setting with its own.
I would like to see one of the following: a) being able to set the log level detail from the bootstrapper or b) being able to stop Burn from overriding my MsiLogging setting Comments and suggestions will be appreciated. Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. WiX-users mailing list [email protected], Rob Mensching - LLCThread view. I've found a number of topics about log file location and some topics about logging detail levels by searching the mail list and the bug tracker.
I still don't know how to get logging working the way I want so here we go again.The Windows Installer properties that interact with logging are MsiLogFileLocation and MsiLogging. They can be used to configure logging the way I want for Msi files run directly from Windows Installer. The main problem I have with using these properties is that they are only supported in Windows Installer 4.0 and up. This would require upgrading all of my Windows XP customers to Windows Installer 4.5. A detailed discussion of the configuration issues follows. The question that applies to the entire discussion is:Is there any way to do this without Windows Installer 4.5 or newer?1. Log file location - It is important for support purposes that log files from failed installs be saved to known safe locations.
The TEMP directory is not a safe location. The standard msi log file name is meaningless. The IT guys I deal with may be calling me for support several days after they encountered the problem. I've implemented custom actions that copy the Msi log file to a known safe (and clearly named) location if the install fails or is cancelled. This works both when the msi is run directly or when it is run as part of a bundle.
The log file that I don't have any solution for is the Burn bundle log.Is there any way to copy the bundle log when a bundle fails? Changing the location would work as well.2. Since I'm currently a beginner with Windows Installer I have my log level detail set to 'voicewarmupx!'
By setting the MsiLogging property. This works when I run the msi directly.
When I run it as part of a bundle Burn is overriding my detail setting with its own. I would like to see one of the following:a) being able to set the log level detail from the bootstrapper orb) being able to stop Burn from overriding my MsiLogging settingComments and suggestions will be appreciated. Burn provides Variables to the paths to all log files, including it'sown log file.
For example, the wixstdba code uses the Variable to provide alink on the failure page. Your BA could do other things.Note: the log filenames from a Bundle are designed to be prettyself-explanatory and are stored in a safe location in%TEMP% that persistsacross reboots. You may be trying to do something more.2a. Just makes Windows Installer really slow and the 'x' is reallyonly interesting for debugging patch issues.
The user can set 'x' via thecommand-line to Burn but I don't think a BA can set it. I haven't tried.2b.
Burn should respect the 'x' if it is in the logging policy so loggingpolicy may work.On Fri, Jun 15, 2012 at 11:40 AM, Don Walker wrote: I've found a number of topics about log file location and some topics about logging detail levels by searching the mail list and the bug tracker. I still don't know how to get logging working the way I want so here we go again. The Windows Installer properties that interact with logging are MsiLogFileLocation and MsiLogging. They can be used to configure logging the way I want for Msi files run directly from Windows Installer. The main problem I have with using these properties is that they are only supported in Windows Installer 4.0 and up.
This would require upgrading all of my Windows XP customers to Windows Installer 4.5. A detailed discussion of the configuration issues follows. The question that applies to the entire discussion is: Is there any way to do this without Windows Installer 4.5 or newer? 1. Log file location - It is important for support purposes that log files from failed installs be saved to known safe locations. The TEMP directory is not a safe location. The standard msi log file name is meaningless.
The IT guys I deal with may be calling me for support several days after they encountered the problem. I've implemented custom actions that copy the Msi log file to a known safe (and clearly named) location if the install fails or is cancelled.
This works both when the msi is run directly or when it is run as part of a bundle. The log file that I don't have any solution for is the Burn bundle log. Is there any way to copy the bundle log when a bundle fails?
Changing the location would work as well. 2. Since I'm currently a beginner with Windows Installer I have my log level detail set to 'voicewarmupx!' By setting the MsiLogging property. This works when I run the msi directly.
When I run it as part of a bundle Burn is overriding my detail setting with its own. I would like to see one of the following: a) being able to set the log level detail from the bootstrapper or b) being able to stop Burn from overriding my MsiLogging setting Comments and suggestions will be appreciated. Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. WiX-users mailing list [email protected], Rob Mensching - LLC. In reply to Rob's points:1. I knew about the Burn log file Variables and link on the failure page.Since I'm new to both Windows Installer and WiX, I was hoping to avoid theneed to write my own bootstrapper just to control logging.
I may beinstalling to XP machines without.Net installed so I wouldn't even be ableto write a managed bootstrapper. While I still occasionally program in C,it is no longer my top choice for this sort of thing. Is there anypossibility that this functionality could be added to the standardbootstrapper?
If not, is wix36-sourcessrcextBalExtensionwixstdba theplace to start for writing my own?You're right about the Bundle log file name being self-explanatory. Theproblem with TEMP is that someone may run Disk Cleanup or remove log filesfiles using some other maintenance tools.2a. The tips about '!' And 'x' are helpful. I'll remove both of them.2b. Since the installs are being done on customer machines by their own ITpeople, requiring a certain logging policy would be considered intrusiveunless there was a serious emergency. The best I can hope for is a loggingsolution that will work with most logging policy settings, including thedefault.-View this message in context:Sent from the wix-users mailing list archive at Nabble.com.
The mba (Managed Bootstrapper Application) can install the.NETFramework.before. your managed BA comes up.
That's actually howthe WiXtoolset works. Install it on a machine with out.NET Framework and it willfirst install.NET Framework then launch the custom BA.However, I must say, I don't understand the scenario. Why are you soworried about losing the installation log files if someone runs DiskCleanup Wizard? Presumably if something goes wrong during the install, onewould get the logs right away2a. If you remove those, then you get what Burn provides by default. Thatis why we picked that. True, all the way the round and that is why we support the loggingpolicy.On Fri, Jun 15, 2012 at 12:50 PM, Don Walker wrote: In reply to Rob's points: 1.
I knew about the Burn log file Variables and link on the failure page. Since I'm new to both Windows Installer and WiX, I was hoping to avoid the need to write my own bootstrapper just to control logging. I may be installing to XP machines without.Net installed so I wouldn't even be able to write a managed bootstrapper. While I still occasionally program in C, it is no longer my top choice for this sort of thing. Is there any possibility that this functionality could be added to the standard bootstrapper?
If not, is wix36-sourcessrcextBalExtensionwixstdba the place to start for writing my own? You're right about the Bundle log file name being self-explanatory. The problem with TEMP is that someone may run Disk Cleanup or remove log files files using some other maintenance tools.
2a. The tips about '!' And 'x' are helpful. I'll remove both of them. 2b.
Since the installs are being done on customer machines by their own IT people, requiring a certain logging policy would be considered intrusive unless there was a serious emergency. The best I can hope for is a logging solution that will work with most logging policy settings, including the default.
View this message in context: Sent from the wix-users mailing list archive at Nabble.com. Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the latest in malware threats. WiX-users mailing list [email protected], Rob Mensching - LLC.
I was aware that 'The mba (Managed Bootstrapper Application) can install the.NETFramework.before. your managed BA comes up.
That's actually howthe WiXtoolset works. Install it on a machine with out.NET Framework and it willfirst install.NET Framework then launch the custom BA. ' There isresistance in to installing.Net as we have a large number of customers onXP using products that don't require.Net. I need some good arguments torequire.Net just to be able to perform the install.
I'm thinking along thelines of:1. Developers of WiX installers will more productive if we allow the use of.Net. I'm getting the impression that WiX is improving support for.Net andthat it may get harder to do things the old C way as the tools anddocumentation start to lean to the.Net way. Is this impression correct?Of course, if we delay the moved to WiX long enough, then this won't be anissue:-I need to provide more information regarding your comment 'However, I mustsay, I don't understand the scenario. Why are you so worried about losingthe installation log files if someone runs Disk Cleanup Wizard? Presumablyif something goes wrong during the install, one would get the logs rightaway'. The problem is that I don't get the logs right away.
In ourcustomer's environments, install failures are rarely critical as they oftenoccur on test machines or there is a previous version of the product whichis still functioning. If an install fails, the IT guy logs a support calland may grab a screen shot. There can be a delay of anywhere from a day toseveral weeks before I find out about the problem. Being able to retrievethe logs is very helpful.
Currently I have access to both the InstallShieldlog file (which InstallShield hides in a safe location) and my own customlog files, which supplement the InstallShield log file.-View this message in context:Sent from the wix-users mailing list archive at Nabble.com. If your product does not need the.NET Framework then by all means donot install it just to write a managed BA. You can just as easily (assumingyou are already writing native code ) write a native BA, just likewixstdba.1. I don't necessarily agree.
We added support for creating managed BA'sbecause it seems that every year fewer and fewer developers are capable ofwriting native code. Providing the ability to write managed BA is verydifferent than recommending it. While it is admittedly far easier to create really snazzylooking UI via WPF vs.
GDI, I hope the experience of creating a native BAis just as straight forward as creating a managed BA. I'm a firm believerthat the WiX toolset should not require your customers to install the.NETFramework. That's (one reason) why Burn is all native code and that all ofthe standard Custom Actions are written in native code.3.
The Visual Studio team kept it's logs in%TEMP% for years and the issuesyou hit never seemed to be a significant problem for them. I'm reticent tohide log files on a user's machine where the user would not know to cleanthem up. I guess I'd rather Burn not participate in WinRot if at allpossible. If that really is a big concern for you, the Burn engine should provide allthe information you need to successfully squirrel your logs away in somesecret place to grow cobwebs and the like. On Tue, Jun 19, 2012 at 12:33 PM, Don Walker wrote: I was aware that 'The mba (Managed Bootstrapper Application) can install the.NET Framework.before. your managed BA comes up. That's actually howthe WiX toolset works.
Install it on a machine with out.NET Framework and it will first install.NET Framework then launch the custom BA. ' There is resistance in to installing.Net as we have a large number of customers on XP using products that don't require.Net.
I need some good arguments to require.Net just to be able to perform the install. I'm thinking along the lines of: 1. Developers of WiX installers will more productive if we allow the use of.Net. I'm getting the impression that WiX is improving support for.Net and that it may get harder to do things the old C way as the tools and documentation start to lean to the.Net way. Is this impression correct? Of course, if we delay the moved to WiX long enough, then this won't be an issue:- I need to provide more information regarding your comment 'However, I must say, I don't understand the scenario.
Why are you so worried about losing the installation log files if someone runs Disk Cleanup Wizard? Presumably if something goes wrong during the install, one would get the logs right away'.
The problem is that I don't get the logs right away. In our customer's environments, install failures are rarely critical as they often occur on test machines or there is a previous version of the product which is still functioning. If an install fails, the IT guy logs a support call and may grab a screen shot. There can be a delay of anywhere from a day to several weeks before I find out about the problem. Being able to retrieve the logs is very helpful.
Currently I have access to both the InstallShield log file (which InstallShield hides in a safe location) and my own custom log files, which supplement the InstallShield log file. View this message in context: Sent from the wix-users mailing list archive at Nabble.com. Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. WiX-users mailing list [email protected], Rob Mensching - LLC.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |