Packaged app receives Windows system error on start up after update

[Sage-Kreiter]

Describe the bug After changing nothing about packaging other than upgrading from Conveyor 11.4 -> 12.0, our app no longer starts on an older Windows 10 version.

To Reproduce Steps to reproduce the behavior:

This may be a tough one to reproduce, but I did test a couple of times to be sure it was a difference in Conveyor version. Here's what I did:

1. Package app with Conveyor 11.4 & deploy
2. Install on Windows 10 PC
3. Run app (runs fine)
4. Upgrade to conveyor 12.0
5. Package app & deploy
6. Update app on same PC
7. Run app (fails)

I also tried reinstalling the app and still no luck

Expected behavior I would expect it would just work since it worked before

Screenshots

Desktop (please complete the following information): Windows 10 - 19045.3208

Additional context I realize this system error is probably below your packaging software, but it seems to be the upgrade to 12.0 that started this problem.

A little more insight that may help (or may even be a separate issue), after the upgrade to Conveyor 12.0, our APPDATA environment variable seemed to have changed specifically on Windows 10 as well. On newer versions of Windows 10, the app will still run fine but now app data path has moved to the MSIX Package path rather than our original app data path. This actually seems more accurate since that's where Windows 11 puts it, but seems weird that it would suddenly change under our feet

[mikehearn]

Hmm, there aren't any changes we're aware of in 12 that could cause this, but maybe there's some subtle problem with this old version of Windows 10. Does your app actually contain this DLL?

[mikehearn]

On investigation, we did upgrade the set of MSVCRT DLLs pulled in when you use this feature:

https://conveyor.hydraulic.dev/12.0/stdlib/#microsoft-visual-c-redistributables

Are you including this stdlib config in your app?

[Sage-Kreiter]

We aren't using that feature. We have a JVM app that does include a couple of our own DLLs for native code (C++). Could any changes have caused a problem with that. Keep in mind I can run Conveyor 11.4 with the same exact build and configuration as when I run 12.0, but it will fail to run on 12

[mikehearn]

Could you do a diff of the files in the packages? e.g.

unzip  old.msix -d old
unzip new.msix -d new
tree old >old.txt
tree new >new.txt
diff -ur old.txt new.txt

Alternatively if you'd prefer, you can open a support ticket and attach the different MSIXs and we'll do it.

[leo-hydraulic]

It would be very helpful to have the logs. If you could run the following:

conveyor make windows-app && conveyor --show-log=report

for each version of Conveyor, we will be able to inspect the differences.

[leo-hydraulic]

With regards to the APPDATA change: the behavior has always meant to match Win 11, of always pointing it into the package path. It was surprising to us that Conveyor 11 wasn't redirecting APPDATA.

I investigated the issue, and turns out this is a (yet another) bug in Windows. What changed between Conveyor 11 and 12 is that we changed our solution to the Unix sockets bug so that it doesn't require the "unvirtualizedResources" capability (as Microsoft was rejecting entries to the MS store with that capability). With virtualization fully functional, APPDATA gets correctly redirected in Conveyor 12.

With one mystery solved, this still doesn't explain the absence of VCRUNTIME140_1.DLL. If you don't use our msvc include, my best guess is that this file comes with the JVM. But that wouldn't explain the change in behavior between Conveyor 11 and 12. We really need further info to debug this.

[Sage-Kreiter]

I'll get that info later today.

Would be good to add that info about the APPDATA change to release notes or somewhere in docs since it is probably breaking for other apps as well. For our app, we will either need to define the variable to the old path for Windows 10 or copy our appdata file on our next update to the new location

[leo-hydraulic]

The easiest way to keep the old behavior is to set the compatibility level down to 11. Otherwise, the directory will be virtualized and you might not be able to access the files correctly.

[leo-hydraulic]

If you want to restore the old behavior while keeping the compatibility level higher, use: app.windows.manifests.msix.virtualization.excluded-directories += LocalAppData/Temp

[Sage-Kreiter]

Awesome thanks!

[leo-hydraulic]

I'd be curious to know if setting compatibility level down to 11 has any impact on the issue of VCRUNTIME140_1.DLL.

[leo-hydraulic]

Hello, @Sage-Kreiter, was there any further development on this issue?

[Sage-Kreiter]

Sorry, @leo-hydraulic, have been pretty busy over here. Will try to get to it today and get you some more info!

[Sage-Kreiter]

Setting compatability level to 11 produced the same vc runtime error. I'll work on getting the log

[mikehearn]

Hi Sage, we think we found the cause for this and will roll a fix into the next Conveyor release. There's no need to get logs.

[Sage-Kreiter]

I'll give it a test after the next update. Thank you!

[mikehearn]

Conveyor 13 fixes this, thanks for the report!