Feb 19 2019 10:33 AM
Feb 19 2019 10:33 AM
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
Feb 21 2019 11:18 AM - edited Feb 21 2019 11:19 AM
Hey Chetan,
We are investigating your issue; we will get back to you soon.
Feb 21 2019 05:28 PM
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
Feb 22 2019 09:46 AM
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
Feb 22 2019 11:16 AM
SolutionHi 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,
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.
Feb 24 2019 10:17 PM
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
Feb 22 2019 11:16 AM
SolutionHi 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,
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.