SOLVED

Application does not launch post installation

Deleted
Not applicable

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)\Appfolder and couple of registry entries for a file association. We successfully packaged this application to MSIX format and deployed it to a test machine.

 

Post deploying the MSIX package to a Win 10 machine (1809), the application does not launch. The application window doesn't appear and no process visible in the Task Manager for this application, we did run Procmon tool, we couldn't narrow down the issue.

 

The MSIX package installs the app to "C:\Program Files\WindowsApps\KeePass_2.41.0.0_x64__a5f717c3cttz4" directory, when we try to launch the application directly from this folder, it didn't work. During troubleshooting, we noticed that, if we remove the "_" after the version number in the folder name, i.e. "C:\Program Files\WindowsApps\KeePass_2.41.0.0_x64__a5f717c3cttz4" to "C:\Program Files\WindowsApps\KeePass_2.41.0.0x64a5f717c3cttz4".

 

Have any of you seen a similar issue with an app, if so, is there a workaround/fix ?

I have attached the MSIX package(Not signed) and the logs (both MSIX and Procmon).

 

Thanks

5 Replies

Hey Chetan,

 

We are investigating your issue; we will get back to you soon.

Hi Chetan,

 

I debugged through your app's launch path.  It appears that you have app code that is behaving differently when it's running as an .msix package.  Do you have any checks in your code that test whether or not you're in an .msix package?  e.g. something like IsMsixPackage()

 

When I move the app outside of the C:\Program Files\WindowsApps folder, it works fine, but when it's in that folder, it seems to be looking for an Application.ini (you can see this in the procmon trace) file that doesn't exist.  Your app fails to find the .ini file, then seems to exit gracefully - it doesn't look like a crash, or a failure in the Windows launch path.

 

Does this ring any bells?

 

Goodluck!

-jw

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

best response
Solution

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.

 

 

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

1 best response

Accepted Solutions
best response
Solution

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.

 

 

View solution in original post