Modification Package not doing what I want

Awesome!  Glad to help and thanks for being so thorough - very helpful.  Good luck with the rest of your development, Robesin.

Hi Jeff,

Youre explanation is clear. I did some other tests myself that seems to confirm your observation that the GeoPipeline exe is doing something weird.

I made a little script in Winbatch, compiled that in two different versions. The only thing it does is setting a HKCU registrykey. And with upgrading that works fine.

Test1 is without user.dat and test2 with user.dat.

So I think we can now say it works as expected. Thanks a lot for your time in this.

I attached a file with the tests and source code. It is a simple Winbatch script which I changed and than compiled to the test?.exe.

Here's the screencap (in procmon.exe) of 18.3 querying and getting '1'.

Hey Robesin,

> Upgrading seems only to work for the files but not for the user registry. I suppose it should determine the registrykey settings from 18.2 and respect them for 18.3 if not set different in 18.3 off course.

Yes agree.

I tried your latest V04 version, and it seems to me like the value of IsEulaAccepted is '1' after upgrading from 18.2 to 18.3, but the D-Geo application is setting it back to '0' at runtime.

1. Installed 18.2 - Launched & Accepted EULA.

     i. Open powershell.exe

     ii. Add-AppxPackage C:\t\V04\Deltares-GeoPipeline_18.2.0.0_x64__m1y3p73dxj1ne.msix -ForceApplicationShutdown

2. Verify that IsEulaAccepted is '1'

    i. Enable Devmode

    ii. Open powershell.exe

    iii. Invoke-CommandInDesktopPackage -PreventBreakaway -PackageFamilyName Deltares-GeoPipeline_m1y3p73dxj1ne -AppId abcd -Command regedit.exe

    iv. Navigate to Computer\HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences

    v. I see IsEulaAccepted is '1'

3. Installed 18.3

     i. Open powershell.exe

     ii. Add-AppxPackage C:\t\V04\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne.msix -ForceApplicationShutdown

4. Verify that IsEulaAccepted is still '1'

    ii. Open powershell.exe

    iii. Invoke-CommandInDesktopPackage -PreventBreakaway -PackageFamilyName Deltares-GeoPipeline_m1y3p73dxj1ne -AppId abcd -Command regedit.exe

    iv. Navigate to Computer\HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences

    v. I see IsEulaAccepted is still '1'

5. Launch D-Geo & verify that IsEulaAccepted is still '1'

      i. I used procmon to verify that D-Geo is getting '1'

2:14:40.8339332 PM DGeoPipeline.exe 10760 RegQueryValue \REGISTRY\WC\Siloa6f2f44c-9d06-02e3-97d4-f3733e69c2e5user_sid\Software\Deltares\D-Geo Pipeline\Preferences\IsEulaAccepted SUCCESS Type: REG_DWORD, Length: 4, Data: 1

6. Close D-Geo & see in procmon that D-Geo sets IsEulaAccepted to '0'

2:15:09.2006347 PM DGeoPipeline.exe 10760 RegSetValue \REGISTRY\WC\Siloa6f2f44c-9d06-02e3-97d4-f3733e69c2e5user_sid\Software\Deltares\D-Geo Pipeline\Preferences\IsEulaAccepted SUCCESS Type: REG_DWORD, Length: 4, Data: 0

7. Verify that IsEulaAccepted is '0'

    ii. Open powershell.exe

    iii. Invoke-CommandInDesktopPackage -PreventBreakaway -PackageFamilyName Deltares-GeoPipeline_m1y3p73dxj1ne -AppId abcd -Command regedit.exe

    iv. Navigate to Computer\HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences

    v. I see IsEulaAccepted is '0'

I can't really deduce much else from this though.  I think this is the stack trace where D-Geo is setting the eula to '0', but I don't have symbols or source code for D-Geo to interpret it further.

18 KernelBase.dll RegSetValueExA + 0x10d 0x7690bc1d C:\Windows\SysWOW64\KernelBase.dll
19 DGeoPipeline.exe DGeoPipeline.exe + 0x3686b 0x43686b C:\Program Files\WindowsApps\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne\VFS\ProgramFilesX86\Deltares\DGeoPipeline\DGeoPipeline.exe
20 DGeoPipeline.exe DGeoPipeline.exe + 0x3671d 0x43671d C:\Program Files\WindowsApps\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne\VFS\ProgramFilesX86\Deltares\DGeoPipeline\DGeoPipeline.exe
21 DGeoPipeline.exe DGeoPipeline.exe + 0x4175c2 0x8175c2 C:\Program Files\WindowsApps\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne\VFS\ProgramFilesX86\Deltares\DGeoPipeline\DGeoPipeline.exe

Hopefully you can make something of this.

Thanks,

-jw

Hi Jeff,

I removed the user.dat from the MSIX packages with the packaging tool. Checked by unzipping the MSIX and confirm that there is no user.dat file in it. It took a while but we have a very busy schedule at the moment. Then I tested the following.

- Install the 18.2 MSIX

- Start the application and Check the EULA to not show it again, Go to the Tools. Program Options, Modules, check "Show at start of Program", OK

- shutdown the app and start it again. Settings are retained, EULA is not shown and Modules dialog is shown. so far so good.

- Now I run the 18.3 MSIX asking to Update, go ahead

- Start the app and it shows 18.3 is starting.

- The EULA is shown. This shouldn't happen since it is exact the same registry key as for 18.2

HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences\[IsEulaAccepted]

- Go to the Tools. Program Options, Modules, "Show at start of Program" is NOT checked anymore. This should be checked as it uses exact the same key as in 18.2

HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences\[ModulesDlgAtStartUp]

Upgrading seems only to work for the files but not for the user registry. I suppose it should determine the registrykey settings from 18.2 and respect them for 18.3 if not set different in 18.3 off course.

To me this seems a bug but I will leave that decision to you. I attached the used MSIX files.

Hey Robesin.  Thanks for re-running the steps.

I still see the User.dat file in your package.  Can you try removing it with the MPT (Msix Package Tool), and try this test again.  I believe there's a bug on our end where having a User.dat file makes writing to HKCU (at runtime) fail.

If you can confirm this, then I'll file the bug and get the fix going.

Thanks!

Edit:  I think the MPT tool has a feature called "Package Editor" that can be used to remove the User.dat from the package.  (It seems it's not enough to just uncheck the "First-Run" option in the MPT.)  Apologies for all the back and forth.

Hi Jeff,

Sorry it took a while but I had other things to attend to. I rebuild the packages of 18.2 and 18.3 without capturing any first startup.
I verified that in the MSIX files are no keys for the program under HKCU

Then I followed the next steps:

Step 1 to check 18.2 behavior
- Install MSIX 18.2 and let it launch

- Check the box to hide the EULA at next start, Set Tools,Options, Modules, Close the program

- Start the program things look ok, settings are retained.
- Uninstall 18.2 version

Step 2 to check 18.3 behavior
- Install MSIX 18.3 and let it launch

- Check the box to hide the EULA at next start, Set Tools,Options, Modules, Close the program

- Start the program things look ok, settings are retained.
- Uninstall 18.3 version

Step 3
- Install MSIX 18.2 and let it launch

- Check the box to hide the EULA at next start, Set Tools,Options, Modules, Close the program

- Start the program things look ok, settings are retained.
- Install the MSIX 18.3 (UPDATE) and let it launch, now existing settings in HKCU from 18.2 are not retained
- The EULA shows up again even though it is the same HKCU key as in the 18.2 version.
HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences[IsEulaAccepted]

- I can check the box again to hide the EULA at next start, and Set Tools,Options, Modules, Close the program (which shouldn't be necessary because of 18.2)

- Then start the program things look ok, settings are retained again.

This is not OK since exact the same key is also present in 18.2 and shouldn't be reset by the upgrade to 18.3. So it seems something goes wrong there. It should let the HKCU keys from 18.2 live and reuse.

I added the MSIX files I used for this. Common files from the prior post need to be installed to use these files.

Hi Robesin - I just got another report about an app that is hitting an ACCESS DENIED when trying to write to HKCU at app-runtime when the app has a User.dat file in it.

Can you try removing the User.dat file from your package and see if that fixes your problem?   (If this is actually the problem, we will file a bug and fix this.)

Thanks!