Forum Discussion
Application does not launch post installation
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.
MicrosoftHey Chetan,
We are investigating your issue; we will get back to you soon.
MicrosoftHi 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- JeffWhiteside
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