ProcMon with a tight filter?
On 6/15/2014 8:56 PM, Heath Stewart wrote:
I'm investigating some test failures and haven't yet narrowed down the
cause - hoping someone might know something.
Basically, during tests like Burn_InstallPatchBundle when the base
bundle (BundleF) is uninstalled, it shows in the log that it will
uninstall a patch bundle (BundleJ).
[2874:2160][2014-06-15T17:08:04]i207: Planned related bundle:
{3e414871-0575-4edd-8684-637637c6f689}, type: Patch, default
requested: Absent, ba requested: Absent, execute: Uninstall, rollback:
Install, dependency: Unregister
The log shows it will pass -uninstall to the arguments as well:
[07B4:2BC4][2014-06-15T17:08:04]i301: Applying execute package:
{3e414871-0575-4edd-8684-637637c6f689}, action: Uninstall, path:
C:\ProgramData\Package
Cache\{3e414871-0575-4edd-8684-637637c6f689}\BundleJ.exe, arguments:
'"C:\ProgramData\Package
Cache\{3e414871-0575-4edd-8684-637637c6f689}\BundleJ.exe" -uninstall
-quiet -burn.related.patch
-burn.ignoredependencies={db3e1d4d-ea07-421e-a90b-7a405c373d39};Microsoft.WiX.Burn_InstallPatchBundle.A,v1.0
-burn.ancestors={db3e1d4d-ea07-421e-a90b-7a405c373d39}'
Yet BundleJ doesn't get that command line!
[1BFC:1E68][2014-06-15T17:08:04]i001: Burn v3.9.615.0, Windows v6.3
(Build 9600: Service Pack 0), path: C:\ProgramData\Package
Cache\{3e414871-0575-4edd-8684-637637c6f689}\BundleJ.exe, cmdline:
'-burn.unelevated BurnPipe.{63AB9F9E-2D7A-4EBE-A019-575B4337021A}
{C9C42B10-C920-44FB-BD32-3859210C0FB3} 5688
-burn.ancestors={db3e1d4d-ea07-421e-a90b-7a405c373d39} -burn.embedded
BurnPipe.{D9611913-FF2C-4443-A5BE-1E933C77D920}
{272A2F7F-4746-41DF-9BD4-352E79C753DD} 1972'
I'm going through the code looking for various things, like some of
the Str*Formatted changes in case the args aren't passed and my recent
changes (i.e. yesterday) but nothing seems to explain it. I'll keep
looking, but hoping someone might recognize some symptom. The current,
action, and dependency states for the related bundle all look right so
I don't think this is a ref-counting issue, but it's not impossible.
The most obvious problem seems to be that the right command line isn't
passed.
It's affecting a good number of the tests. Hard to roll back the
non-test settings to see if it was broken before. I'll try copying the
test binaries out and rolling back the full build to see if this is a
recent regression or not, but wanted to put this out there ASAP in
hopes to find and fix the problem by tomorrow's RC build. Definitely
needs to be fixed before 3.9 ships. A lot of bundles depend on related
bundles.
Link to logs below if someone is interested.
*Heath Stewart*
Software Design Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths
Heath has a file to share with you on OneDrive. To view it, click the
link below.
Burn_InstallPatchBundle.zip
<https://onedrive.live.com/redir.aspx?cid=9415f61cbb1a8030&resid=9415F61CBB1A8030%2144438&parId=9415F61CBB1A8030%218580&authkey=%21AAhvJhYSQ9Grw3w&ithint=file%2c.zip>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
--
sig://boB
http://joyofsetup.com/
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
