Forum Discussion

Anonymous

Feb 19, 2019

Solved

Application does not launch post installation

Hello Team, We are currently packaging "KeePass" application (https://keepass.info/download.html) to MSIX format. The app appears to be of simple complexity, few files in Program Files (x86)\Appfold...

KeePass_2.41_NotSigned.zip4.9 MB

JeffWhiteside
Feb 22, 2019
Hi Chetan, I'm not sure about why the '_' underscore affects anything (it shouldn't). Launching via the the Start Menu ("Tile Launch") is the way to have the app be 'containerized' when it's launched (this is failing today). Launching via double-clicking the .exe file does not launch the app in the container (this is working today). Maybe removing the '_' is subverting the container during launch.

I'm looking at the trace you attached in the package above - and I see an attempt to load Application.ini.

9:41:20.6583378 AM KeePass.exe 8936 CreateFile C:\Program Files\WindowsApps\KeePass_2.41.0.0_x64__a5f717c3cttz4\VFS\ProgramFilesX86\KeePass2x\Application.ini REPARSE Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Created

Since you mentioned KeePass is open source, I took a look. It looks like the CommonInit() function is doing this check,

        public static bool CommonInit()

        {

            m_bDesignMode = false; // Again, for the ones not calling Main

            m_rndGlobal = CryptoRandom.NewWeakRandom();

            InitEnvSecurity();

            MonoWorkarounds.Initialize();

            // try { NativeMethods.SetProcessDPIAware(); }

            // catch(Exception) { }

            // Do not run as AppX, because of compatibility problems

            // (unless we're a special compatibility build)

            if(WinUtil.IsAppX && !IsBuildType(

                "CDE75CF0D4CA04D577A5A2E6BF5D19BFD5DDBBCF89D340FBBB0E4592C04496F1"))

                return false;

https://github.com/dlech/KeePass2.x/blob/6b1160ff4d1b042bf7e59bb8c2e9f0a189a35c4d/KeePass/Program.cs

This comment "Do not run as AppX, because of compatibility problems" and the WinUtil.IsAppX are suspicious. Seems like like there's code in KeePass.exe to specifically stop it running in the msix container.

Anonymous

Feb 22, 2019

Hello Jeff,

Many thanks for looking into this issue. I am an Application Packaging engineer and not the developer of the application. KeePass is a open source Password Manager application (.Net). We had a request to delivery the application via Intune and the reason we thought of delivering it as a MSIX package. I am not really sure on the app code part for this application.

Having the app in "C:\Program Files\WindowsApps\" folder, if I just remove the "_" in the folder name right after the app version number, i.e. renaming the folder to "KeePass_2.41.0.0x64__a5f717c3cttz4", when I execute the application exe from "C:\Program Files\WindowsApps\KeePass_2.41.0.0x64__a5f717c3cttz4\VFS\ProgramFilesX86\KeePass2x\KeePass.exe", the app launches and even with a longer folder name, it works.

I ran Procmon when the app launched, I don't see Application.ini file read/write actions, no trace of this file in Procom. I did more testing today and looked into Procmon trace, didn't really find anything I can relate. The app creates runtime files in the user appdata folder, when it executes fine, I see the files getting created runtime.

Thanks,
Chetan Gs

JeffWhiteside

Microsoft

Feb 22, 2019

Hi Chetan, I'm not sure about why the '_' underscore affects anything (it shouldn't). Launching via the the Start Menu ("Tile Launch") is the way to have the app be 'containerized' when it's launched (this is failing today). Launching via double-clicking the .exe file does not launch the app in the container (this is working today). Maybe removing the '_' is subverting the container during launch.

I'm looking at the trace you attached in the package above - and I see an attempt to load Application.ini.

9:41:20.6583378 AM KeePass.exe 8936 CreateFile C:\Program Files\WindowsApps\KeePass_2.41.0.0_x64__a5f717c3cttz4\VFS\ProgramFilesX86\KeePass2x\Application.ini REPARSE Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Created

Since you mentioned KeePass is open source, I took a look. It looks like the CommonInit() function is doing this check,

public static bool CommonInit()

{

m_bDesignMode = false; // Again, for the ones not calling Main

m_rndGlobal = CryptoRandom.NewWeakRandom();

InitEnvSecurity();

MonoWorkarounds.Initialize();

// try { NativeMethods.SetProcessDPIAware(); }

// catch(Exception) { }

// Do not run as AppX, because of compatibility problems

// (unless we're a special compatibility build)

if(WinUtil.IsAppX && !IsBuildType(

"CDE75CF0D4CA04D577A5A2E6BF5D19BFD5DDBBCF89D340FBBB0E4592C04496F1"))

return false;

https://github.com/dlech/KeePass2.x/blob/6b1160ff4d1b042bf7e59bb8c2e9f0a189a35c4d/KeePass/Program.cs

This comment "Do not run as AppX, because of compatibility problems" and the WinUtil.IsAppX are suspicious. Seems like like there's code in KeePass.exe to specifically stop it running in the msix container.

Anonymous
Feb 24, 2019
Hi Jeff,

Thanks, this is a good find. I guess there might be a reason for them to block the app working in containerization. As you mentioned, probably removing "_" in the folder naming is doing something which makes the app launch outside of the containerization.

Thanks again for all the support and help.

Cheers,
Chetan Gs