Packaged WinUI app crashes on start-up when deployed to test PC #2407
Replies: 2 comments 4 replies
-
|
My issue was caused by trying to write files to What's odd is that on some Windows installation it works and on others it does not… <!-- That logs to something like: C:\Users\micro\AppData\Local\Packages\59798Slions.TaskbarPro_md9twrekhzh1t\LocalCache\Local\logs.txt -->
<target name="File" xsi:type="File" fileName="${specialfolder:folder=LocalApplicationData:cached=true}/logs.txt" />Just make sure your packaged app does not try to write to files relative to your executable location. As to why the unhandled exception event is not called and why |
Beta Was this translation helpful? Give feedback.
-
I wonder if Test Mode may have something to do with that. Both machines where writing to Moreover when running your app from Visual Studio writing to |
Beta Was this translation helpful? Give feedback.
-
|
BCDEDIT's testsigning and debug won't affect the pkgdir's un-writeability.
That'll work, because a package's installed location varies, depending... VS F5 registers a package with pkgdir= The longer explanation... Ultimately all MSIX deployment operations start with a call to PackageManager PackageManager.AddPackage*() creates a pkgdir as the package's full name ( PackageManager.AddPackage*(...targetVolume=packagevolume...) creates a pkgdir as the package's full name under the specified package volume. Deployment owns all package volumes so Windows is responsible for lifetime, access, etc. A new Windows image starts with the default package volume but you can add more (via PackageManager, Add-AppxPackageVolume cmdlet, etc). In Settings when you change where new apps are saved to that's altering the default package volume for the machine. Under the covers Settings is using PackageManager's PackageVolume APIs to create a directory if you pick something other than C:. NOTE: Settings creates package volumes with a specific path but that's just Settings, the PackageVolume APIs let you specify a path ( Visual Studio F5 uses PackageManager.RegisterPackage*(...DeploymentOption_DevelopmentMode...) to register a project's output directory as the package directory. Upside is the package files are already there from building the project so no need to copy files elsewhere (makes for faster F5 experience). It's also NOT locked down so you could write to it if you chose. Of course that'll only work when running under VS... NOTE: The DevelopmentMode option has caveats, as it's designed for development not general use. See the docs for more details. Packages can be installed with an External Location via NOTE: PackageVolumes aren't writeable but that's necessary to bring benefits. Aside from higher integrity due to their no-write access, deployment's minimizing disk usage via shared-disk-space-for-identical-file-content is made possible by PackageVolumes. That's the only location providing the guarantees to safely share disk space by duplicate files. "Inbox"/System packages that are built by and are a part of Windows (e.g. Settings) are owned by Windows and locked down (e.g. like ntdll.dll) but are in their own locations (usually somewhere under Packages installed with StageInPlace are another variation. Here you've specified a path where the pkgdir lives. So like the External Location you are responsible for its lifetime and access, but unlike ExternalLocation there's just the 1 path containing all (content+footprint) files. StageInPlace is similar in effect to Inbox/system packages in that it's a path merely referenced by deployment but owned by someone else, though the mechanisms how system packages work differs from StageInPlace. So to summarize:
|
Beta Was this translation helpful? Give feedback.
-
|
Packaged apps are installed to a location that's very locked down (e.g.
|
Beta Was this translation helpful? Give feedback.
-
True, even after admin elevation I could not modify a config file in there. At least on that machine that was causing problem. |
Beta Was this translation helpful? Give feedback.
-
Hence the very in very locked down :-) See above for more details. |
Beta Was this translation helpful? Give feedback.
-
That app works great on both my development machines.
However it failed Windows Store submission because it crashed on start-up during certification.
Sure enough it crashes on start-up when installed on a third PC with something similar to that:
https://stackoverflow.com/questions/45200620/faulting-module-name-kernelbase-dll
Event logs reports:
Faulting module name: KERNELBASE.dllI've added logs and registered to that
Application.UnhandledExceptionevent however I'm not getting any logs meaning it looks like it crashes before the constructor of my Application class implementation.Is there an actual entry point I could use outside the Application class?
Updated to 1.1.0-preview1, same issue.
I've also determined that the application starts properly since some of my code is running. I can see the blank window with size and title bar text and icon set as expected but then it crashes badly later on and NLog does not even get a chance to write its logs somehow.
Even forcing flush with NLog target set to a file did not work. For some reason the log file is not created on the test PC even though it works fine on my development machine. Fortunately with NLog set to send logs over UDP using NLogViewer target I can get the logs using Sentinel.
Looks more and more like my issue has little to do with Windows App SDK after all. Still how comes I'm not getting unhandled exception event? Though the app works on that third PC when running from Visual Studio but still does not run when installed from an installer.
Related issues:
Beta Was this translation helpful? Give feedback.
All reactions