[wix-users] Bundle upgrade fails: Cannot read language ID

Mon Dec 20 16:03:10 PST 2021

Question, I noticed the fix was ported to v3. We're using 3.14.0.5722
(because of arm64 support). Should I still see the issue or is it only
ported for the stable 3.x builds?

Thanks,
Jacques

On Mon, Dec 20, 2021 at 2:01 PM Jacques Eloff <repstosd at gmail.com> wrote:

> Awesome, I managed to hack my machine to run as local system and I can
> repro this now successfully it seems. Thank you Bob!!!
>
> On Mon, Dec 20, 2021 at 12:01 PM Bob Arnson <bob at firegiant.com> wrote:
>
>> Nope, I’m not suggesting any of that. I was just commenting on Sean’s
>> comment, because of https://github.com/wixtoolset/issues/issues/5479.
>>
>>
>>
>> *From:* Jacques Eloff <repstosd at gmail.com>
>> *Sent:* Monday, 20 December, 2021 14:41
>> *To:* WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
>> *Cc:* Bob Arnson <bob at firegiant.com>
>> *Subject:* Re: [wix-users] Bundle upgrade fails: Cannot read language ID
>>
>>
>>
>> Thanks Sean, Bob
>>
>> In this case it was running under the update agent, so I'm guessing
>> either local SYSTEM or trusted installer since this is wuauserv. I know
>> there's restrictions on querying the language property. You're suggesting
>> this is due to the context under which the bundle is invoked?
>>
>> The docs do state that "These properties cannot be retrieved for product
>> instances that are installed under a per-user-unmanaged context for user
>> accounts other than current user account." So, even though this is a
>> per-machine MSI, because it ran under a local service, it's context becomes
>> user-unmanaged and then the API calls fail? Because once it fails, it fails
>> for every other MSI, even though only 1 MSI in the chain contains language
>> data in the bundle manifest.
>>
>> The corruption was my first thought too because of the random error
>> codes, though I'm seeing failures across 20H2, 21H1, and 21H2. I've set up
>> multiple repro VMs and when I install the baseline, the MSI either upgrades
>> or the bundle detects the downgrade  (when I install a newer version before
>> triggering the upgrade) and skips the MSI as expected. AllUsers is set to 1.
>>
>> Thanks,
>>
>> Jacques
>>
>>
>>
>> On Mon, Dec 20, 2021 at 10:13 AM Bob Arnson via wix-users <
>> wix-users at lists.wixtoolset.org> wrote:
>>
>> Or the bundle is running from a LocalSystem service, which is how MSI
>> parents a per-machine package.
>>
>> -----Original Message-----
>> From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
>> Sean Hall via wix-users
>> Sent: Monday, 20 December, 2021 12:17
>> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
>> Cc: Sean Hall <r.sean.hall at gmail.com>
>> Subject: Re: [wix-users] Bundle upgrade fails: Cannot read language ID
>>
>> > The first package it detects, it reports as being a per-user scope,
>> > but I
>> suspect that's just because of how the fPerMachine flag was initialized.
>>
>> No, if it reported it as per-user scope then that means
>> MsiGetProductInfoEx was able to find that product for
>> MSIINSTALLCONTEXT_USERUNMANAGED. If that's not what you expected, then it
>> seems the MSI APIs are broken on that machine or memory is getting
>> corrupted.
>>
>> On Mon, Dec 20, 2021 at 10:39 AM Jacques Eloff via wix-users <
>> wix-users at lists.wixtoolset.org> wrote:
>>
>> > Hi
>> >
>> > I've been looking at a failure when a bundle tries to upgrade an MSI
>> > (where the MSI have the language column set). All the MSIs are
>> > per-machine installs.
>> >
>> > From the logs, it appears to fail in msiengine.cpp in the snippet
>> > below
>> >
>> > // Ignore related product where we can't read the language.
>> >                 if (FAILED(hr))
>> >                 {
>> >                     LogErrorId(hr,
>> > MSG_FAILED_READ_RELATED_PACKAGE_LANGUAGE, wzProductCode,
>> > sczInstalledLanguage, NULL);
>> >
>> >                     hr = S_OK;
>> >                     continue;
>> >                 }
>> >
>> > From the logs I observe some odd behavior.
>> >
>> > The first package it detects, it reports as being a per-user scope,
>> > but I suspect that's just because of how the fPerMachine flag was
>> initialized.
>> > All subsequent packages are then reporting failures, whether they have
>> > language IDs in their upgrade tables or not.
>> >
>> > [2EF0:29B8][2021-12-16T23:33:59]i103: Detected related package:
>> > {9376EAFC-5ABE-4A09-B1D7-6F1DD4904105}, scope: PerUser, version:
>> > 48.3.31210.0, language: 0 operation: MajorUpgrade
>> > [2EF0:29B8][2021-12-16T23:33:59]i108: Detected compatible package:
>> > Microsoft.NET.Sdk.Android.Manifest_6.0.100.31.0.101_preview.9.16_x64.m
>> > si,
>> > provider: Microsoft.NET.Sdk.Android,6.0.100,x64, installed:
>> > {CA87338A-7E35-413F-87C2-4E5C6E88A62D}, version: 124.25.16443, chained:
>> > {879C90F1-F656-4B45-AE49-87AF5A6BA28C}
>> > [2EF0:29B8][2021-12-16T23:33:59]e152: Detected related package:
>> > {CA87338A-7E35-413F-87C2-4E5C6E88A62D}, but failed to read language: ,
>> > error: 0x8ff2a8
>> >
>> > Here's the kicker though. 4 consecutive runs of the budle produced 4
>> > different error codes, none of which are document under
>> > MsiGetProductInfoExW
>> >
>> > 0x8ff2a8
>> > 0x53f5f4
>> > 0x19f1e4
>> > 0xa2f24c
>> >
>> > The end result is that a potential downgrade is not detected, the
>> > engine executes an MSI that then triggers its launch condition blocker
>> > causing the bundle to fail.
>> >
>> > Anyone seen this before? I've not been able to reproduce this yet.
>> >
>> > Thanks,
>> > Jacques
>> >
>> > ____________________________________________________________________
>> > WiX Toolset Users Mailing List provided by FireGiant
>> > http://www.firegiant.com/
>> >
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>>