[WiX-users] Burn and Msi logging revisited

[Don Walker]

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.

[Rob Mensching]

1. Burn provides Variables to the paths to all log files, including it's
own log file. For example, the wixstdba code uses the Variable to provide a
link on the failure page. Your BA could do other things.

Note: the log filenames from a Bundle are designed to be pretty
self-explanatory and are stored in a safe location in%TEMP% that persists
across reboots. You may be trying to do something more.

2a. The "!" just makes Windows Installer really slow and the "x" is really
only interesting for debugging patch issues. The user can set "x" via the
command-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 logging
policy may work.

Post by Don Walker
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
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
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. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

...

[Don Walker]

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-sources\src\ext\BalExtension\wixstdba 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: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7578878.html
Sent from the wix-users mailing list archive at Nabble.com.

[Rob Mensching]

1. 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.

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

2a. If you remove those, then you get what Burn provides by default. That
is why we picked that. <smile/>

2b. True, all the way the round and that is why we support the logging
policy.

Post by Don Walker
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-sources\src\ext\BalExtension\wixstdba 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.
--
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7578878.html
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. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

...

[Don Walker]

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. Agree?
2. 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: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7578939.html
Sent from the wix-users mailing list archive at Nabble.com.

[Rob Mensching]

0. If your product does not need the .NET Framework then by all means do
not install it just to write a managed BA. You can just as easily (assuming
you are already writing native code <smile/>) write a native BA, just like
wixstdba.
1. I don't necessarily agree. We added support for creating managed BA's
because it seems that every year fewer and fewer developers are capable of
writing native code. Providing the ability to write managed BA is very
different than recommending it. <smile>

2. I hope not. While it is admittedly far easier to create really snazzy
looking UI via WPF vs. GDI, I hope the experience of creating a native BA
is just as straight forward as creating a managed BA. I'm a firm believer
that the WiX toolset should not require your customers to install the .NET
Framework. That's (one reason) why Burn is all native code and that all of
the standard Custom Actions are written in native code.

3. The Visual Studio team kept it's logs in %TEMP% for years and the issues
you hit never seemed to be a significant problem for them. I'm reticent to
hide log files on a user's machine where the user would not know to clean
them up. I guess I'd rather Burn not participate in WinRot if at all
possible. <smile/>

If that really is a big concern for you, the Burn engine should provide all
the information you need to successfully squirrel your logs away in some
secret place to grow cobwebs and the like. <wink/>

Post by Don Walker
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
1. Developers of WiX installers will more productive if we allow the use of
.Net. Agree?
2. 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.
--
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7578939.html
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. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

...

[Don Walker]

Rob, your response inspired me to modify wixstdba to add the logging feature
I wanted. I was able to do this and removed the need for custom actions in
my MSI's and forcing all my XP users to upgrade to Windows Installer 4.5.
I've posted the code change to wixstdba below for comments and criticism.
While getting wixstdba to build I noticed that the .vcxproj file only
contained a Debug configuration. Since VS generates a Release configuration
by default it would appear some effort was expended to remove it.

Is there a problem with building wixstdba with a normal Release
configuration?

Does this mean that WiX releases contain a Debug build of wixstdba?

My code changes involved adding the following to OnShutdown juist before the
return statement:

if (FAILED(m_hrFinal))
VtmCopyLogfiles();

The new code is:

// VtmCopyOneLogFile
// Copy the log file described by the variable logVariableName to
vtmLogFileDir
void VtmCopyOneLogFile(__in LPCWSTR logVariableName, LPCWSTR
vtmLogFileDir)
{
HRESULT hr = S_OK;
LPWSTR sczLogFile = NULL;
LPWSTR copyLogFile = NULL;
LPWSTR pwzFullPath = NULL;
int fullPathLen = 0;
LPWSTR wzFileName = NULL;

if (logVariableName && *logVariableName)
{
hr = BalGetStringVariable(logVariableName, &sczLogFile);
BalExitOnFailure1(hr, "Failed to get log file variable '%ls'.",
logVariableName);
// Get the file name part (wzFileName) from sczLogFile
// DW Jun 22/12 - not sure if this is the best way but
GetFullPathNameW is used elsewhere in WiX.
hr = StrAlloc(&pwzFullPath, MAX_PATH);
BalExitOnFailure(hr, "Failed to allocate space for full path.");
fullPathLen = ::GetFullPathNameW(sczLogFile, MAX_PATH, pwzFullPath,
&wzFileName);
if (fullPathLen == 0 || fullPathLen >= MAX_PATH)
{
// Set a return code - this isn't technically correct for the
fullPathLen == 0 case but will do
// until it is clear there is a need to distiguish these failures
which are unlikely to occur.
hr = HRESULT_FROM_WIN32(ERROR_INSUFFICIENT_BUFFER);
BalExitOnFailure1(hr, "FAILED to extract file name from %ls",
sczLogFile);
}
hr = StrAllocFormatted(&copyLogFile, L"%ls%ls", vtmLogFileDir,
wzFileName);
BalExitOnFailure(hr, "Failed to format copy file path.");
if (CopyFileW(sczLogFile, copyLogFile, FALSE))
BalLog(BOOTSTRAPPER_LOG_LEVEL_STANDARD, "Copied: %ls",
sczLogFile);
else
BalLog(BOOTSTRAPPER_LOG_LEVEL_STANDARD, "FAILED to copy: %ls",
sczLogFile);
}
LExit:
ReleaseStr(copyLogFile);
ReleaseStr(pwzFullPath);
ReleaseStr(sczLogFile);
return;
}

// VtmCopyLogfiles
// Copy the bundle and package log files to "C:\mypath\common\setups\"
void VtmCopyLogfiles()
{
HRESULT hr = S_OK;
LPCWSTR vtmLogFileDir = L"C:\\mypath\\common\\setups\\";
LPWSTR bundleLogVariableName = NULL;

BalLog(BOOTSTRAPPER_LOG_LEVEL_STANDARD, "ATTENTION: Start Copying log
files to mypath. Result Code: 0x%08x", m_hrFinal);
hr = DirEnsureExists(vtmLogFileDir, NULL);
BalExitOnFailure1(hr, "FAILED to create log file directory: '%ls'.",
vtmLogFileDir);
BAL_INFO_PACKAGE* pInfoPackages = m_Bundle.packages.rgPackages;
int infoPackagesCount = m_Bundle.packages.cPackages;
VtmCopyOneLogFile(m_Bundle.sczLogVariable, vtmLogFileDir); // Copy the
bundle log the first time.
for (int i = 0; i < infoPackagesCount; i++)
{
// Create the standard variable name for the package log file. This
code will work only if the
// variable names have NOT been customized using the LogPathVariable
attribute for the package.
hr = StrAllocFormatted(&bundleLogVariableName, L"WixBundleLog_%ls",
pInfoPackages[i].sczId);
BalExitOnFailure(hr, "Failed to format bundle log variable name.");
VtmCopyOneLogFile(bundleLogVariableName, vtmLogFileDir);
}
// Update the copy of the bundle log. We copied it above to increase
the chances that we'll have a
// copy of the log already if something goes wrong during the copying
of the package log files. We
// update it here to make it as complete as possible. It will still be
missing the tail end of the
// full bundle log, including the dump of the bundle variables.
VtmCopyOneLogFile(m_Bundle.sczLogVariable, vtmLogFileDir);
LExit:
BalLog(BOOTSTRAPPER_LOG_LEVEL_STANDARD, "ATTENTION: End Copying log
files to mypath.");
ReleaseStr(bundleLogVariableName);
}



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7579212.html
Sent from the wix-users mailing list archive at Nabble.com.

[Don Walker]

FWIW I created a Release config for wixstdba by copying the Debug config and
then making obvious changes like removing _DEBUG and DEBUG symbols and
turning on optimization. It appears to work fine with the limited testing I
did.

--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7579292.html
Sent from the wix-users mailing list archive at Nabble.com.