New WSA versions fail to start

[fsmirne]

Hey all,

I haven't been able to run any recent version, including v2307.40000.3.0 after patching them.
I can install them just fine if I install the Msixbuldle file directly, but when I patch it with MagiskOnWSALocal, the install starts, but when the google play app tried to start, it just spins for a couple of minutes and eventually quits. I looked through the logcat files but I haven't been able to determine what could be causing it. I'm now using version 2304.40000.7.0 with Magisk and it's working correctly. Is anybody else having this issue?
I'm curious if it's just me.
Thanks!

[fsmirne]

BTW, I have applied the fix from https://github.com/LSPosed/MagiskOnWSALocal/pull/620/files when building the new builds. I'm able to build everything correctly and the install process finished successfully. It just quits without starting the Play Store app and Magisk. Also, when I look at the Windows Subsystem for Android Settings app, it shows no installed apps on my system so for some reason those apps aren't being installed on the first run.

[Almighty188]

As the author of the fix mentioned in another thread, did this problem only start with 2306.40000.x.x? If so, your problem is the %LOCALAPPDATA%\Packages\MicrosoftCorporationII.WindowsSubsystemForAndroid_8wekyb3d8bbwe\LocalCache\userdata.vhdx changed formats. Here is what you can do. Get WSATools from Microsoft Store and backup all the apps using WSATools while you are still in v2304.40000.7.0.
Make a copy of userdata.vhdx in the path above and delete the original userdaa.vhdx. Then build as usual and it should start.
Then use WSATools to Restore all the apps you had backed up. WSATools runs on the Windows side.

[fsmirne]

Hey @Almighty188,

Thanks for your help. I completely uninstalled WSA and started fresh between all tries. When I install the unpatched versions, everything starts normally. If I try the patched versions, they exhibit the problem with spinning for a couple minutes and quitting without an error message.

I even tried to run a compare on the logcat from the patched and unpatched versions and I couldn't find anything that jumped at me.

If everything works for everyone else, it might be some configuration on my machine that's preventing the patched versions from starting properly. I haven't figured it out yet...

[Almighty188]

Hey @fsmirne - You are very welcome. I had the same problem and I believe the issue is because v2306 switched from EROFS to EXT4 for the filesystem which is the older userdata.vhdx which works for versions before 2306 no longer works and you have to start without any apps which was why I said to use WSATools to backup all the apps and app data first and then when it works, restore the apps and appdata.

[fsmirne]

@Almighty188 - Even though I was starting fresh, without any apps, I did try to use WSA Tools to back up my userdata.vhdx file but it didn't work. I then went into the LocalCache folder and found out that my userdata.vhdx file is now named userdata.2.vhdx.. I'm now running on an unpatched version 2307.40000.3.0 and everything works fine.

Here's what my LocalCache folder looks like with the unpatched version:

I think I'm on a new version with different vhdx structure and the patch doesn't work on this version. I need to investigate more and see when this change started happening, but I can't use any of the last few versions.

FYI, if I rename userdata.2.vhdx to userdata.vhdx, I can restore my WSA Tools backup. It looks like it's looking for a hardcoded name in that folder and doesn't recognize userdata.2.vhdx. Even when I rename the file, then restore it, apps don't start when I try to run them. They exhibit the same issue with spinning and quitting after a couple of minutes.

More investigation is needed here. I'm not sure if I'm the only one who got the new file names, but there may be the starting point of off of this. In any case, thanks again for your help!

[Almighty188]

The patch is there so if it's v2306 and newer, it will do it a certain way and if it's below v2306, it will do it another way. Yes, the file has to be named userdata.vhdx exactly for it to work. How did you do the uninstall? Are you doing it using #645 (comment)

Also, I forgot to ask but are you using scripts/run.sh to build and if not, which version of Google Apps are you using? As he newer versions are Android 13 and only works with MindTheGapps and not OpenGApps, the later could also be the reason why it's failing.

[fsmirne]

I'm using the latest version in the master branch with the changes from https://github.com/LSPosed/MagiskOnWSALocal/pull/620/files
I'm building everything on my Ubuntu WSL. Building works perfectly. Running doesn't. When I uninstall WSA, I do it exactly like #645 . This is not an issue and I can always install fresh without any apps or history.

I need to understand why my files are named metadata.2.vhdx and userdata.2.vhdx when I install the unpatched 2307.40000.3.0. I believe this is one of the reasons things are not working with the patched versions.

[Almighty188]

Yeah, the files are supposed to be named metadata.vhdx and userdata.vhdx, not sure how yours is naming it with the .2 added in the middle. What I was asking was are you using the run.sh script or are you using the build.sh script as the Google Apps used to have two choices, one is MindtheApps which should be the one used, the other being OpenGApps which no longer works. When you the uninstall as mentioned in #645, does the %LOCALAPPDATA%\Packages\MicrosoftCorporationII.WindowsSubsystemForAndroid_8wekyb3d8bbwe\LocalCache\ folder actually get completely emptied out since you are right, it's weird when you don't even have metadata.vhdx and userdata.vhdx so it would have to use a different name.

Perhaps you can report this as a issue and see what they say.

[fsmirne]

Yes. The folder as well and the parent folders are all deleted. I always used MindTheGapps when given a choice. I'm in the process of installing all older versions and seeing what version if the first one to break. I will report back.

[fsmirne]

Ok. All versions up to 2305.40000.6.0 work just fine. Starting with version 2306.40000.1.0 I get the spinning bug.
Here's what my folder structure looks like in version 2305.40000.6.0:

So for me, something broke when they switched from erofs to ext4. For some reason the script doesn't patch my files properly and I run into the issue

[Almighty188]

I forgot to ask, but what version is your Ubuntu and did you update erofs-utils which needs to be at v1.4 or newer to work as this was a problem described here #535 and basically I updated Ubuntu from 20.04 to 22.04.

[Almighty188]

You might also want to use this: https://github.com/YT-Advanced/MagiskOnWSALocal/blob/patch-1/scripts/build.sh
and replace the build.sh you have even though it is the patched build.sh, just in case there is a error when you manually did the editing.

[fsmirne]

Ubuntu version is the following:

build.sh is the exact same as the patch since I did not edit it manually but pulled the patch straight from github.
The problem is not with building it, but running it. The build process works flawlessly and I always get the correct .7z files in the output directory.

It's really puzzling that this only seems to affect me and nobody else. I'd imagine more people would have the same issue... It's gotta be something specific with my machine and versions newer than 2306

[Almighty188]

Github does not have support for v2306 yet without manually editing the scripts/build.sh as can be seen here:
https://github.com/LSPosed/MagiskOnWSALocal/blob/main/scripts/build.sh
The only patched build.sh is the one from https://github.com/YT-Advanced/MagiskOnWSALocal/blob/patch-1/scripts/build.sh but that one is not from https://github.com/LSPosed/MagiskOnWSALocal but regardless, try posting about the problem in the issues and the developers probably knows how to diagnose things like this better than I would.

[fsmirne]

I know the main branch doesn't have the working build.sh file. I have pulled the patch before testing things today. As I said, building works correctly for all versions.

I appreciate the time you spent trying to diagnose this with me. I will open an issue and hopefully somebody will also encounter the issue.

Thanks again!

[Almighty188]

No problem, in the output folder of the builds, how are the metadata and userdata files named there? Is it just metadata.vhdx and userdata.vhdx or does it also have the 2 added to the filename for the versions with the problem.

[fsmirne]

This is the screenshot of my 2307.40000.3.0 output:

I compress it to 7z but you can see they are named without the .2 in there.

[Almighty188]

Yep, so it must be something that Run.bat which calls Install.ps1 is doing and hopefully the project maintainers will be able to figure what went wrong and what is causing the files to be named differently when it is in the destination folder.

[fsmirne]

Just for completeness, in case somebody sees this thread in the future, the original non patched version 2307.40000.3.0 has the .2 names on those files and it works 100% correct. I don't think the name is the issue to be honest but because of the name change, the patch process may break. However, I haven't confirmed that this is the case

[Almighty188]

I have never used the non-patched version(s) other than installing directly from Microsoft Store but my patched version of 2307.40000.3.0 does not have the .2 names as I just build it this morning but ofcourse my files are from one of the 2306 version(s) and I updated WSA.

[mio-19]

I can confirm this. 2307 have .2 names but if it is upgraded from 2306 it keeps original names

[YT-Advanced]

Can you test these prebuilt patches:
https://github.com/YT-Advanced/WSA-Script