Forwarder Fails to Launch - "The software was closed because an error occurred." about nton HOT 16 CLOSED

Considering this issue is 99.9% of the time caused by bad or outdated or incomplete sigpatches, and that 16.0.2 just came out, it's more likely to be a sigpatches issue than anything.

Also, which version did you test this on? The PyPI/latest release, or the latest commit on the repo? Ideally if you could test both that would be great. I don't have a switch ready to test anything on at the moment.

from nton.

Latest commit. I can't even use the PyPI release as we discussed since it doesn't find my prod.keys files (I guess I can probably go compare and see what change fixed that and apply it myself).

Sig patches have not changed between 16.0.0, 16.0.1, and 16.0.2. Only 16.0.0 introduced a new key, 16.0.1 only changed the bad word list, and 16.0.2 added one word to the JP bad word list and made a small change to the SSL module,

Either way I made new sigpatches last night myself from my own 16.0.2 dump and the the AMS 1.5.2 package3 binary (as I noted in the issue) and also the auto built HB Menu forwarder from the latest build works for me, so clearly my sigpatches are fine. I even tried reverting to the previous ExeFS ROM to confirm that it was not the cause and it still crashes as described.

Are you able to run a build for me and I will test it tonight?

from nton.

Latest commit. I can't even use the PyPI release as we discussed since it doesn't find my prod.keys files (I guess I can probably go compare and see what change fixed that and apply it myself).

You could just place prod.keys wherever your terminal/cmd currently is, e.g., if your terminal has cd to Desktop, put it in the Desktop.

Sig patches have not changed between 16.0.0, 16.0.1, and 16.0.2.

That is quite strange then. This leads me to believe there could be some issue with either the new ExeFS ROM and/or the underlying nx-hbloader code.

the auto built HB Menu forwarder from the latest build works for me

Are you referring to the one under NTON releases in the Assets section? This makes it even more clear that it could be the new ExeFS ROM as that forwarder would have been built on the older ExeFS ROM.

I even tried reverting to the previous ExeFS ROM to confirm that it was not the cause and it still crashes as described

Yet by your own words, it's as if it's not the cause. Perhaps some change between the last release and now caused a problem? You can see in the GitHub commit history what changes were made here: v1.2.0...master

Perhaps you could try slowly going down the changes until it works again? You can use git checkout HEAD^1 to repeatedly remove the latest commit, and test builds until it works again. (with git checkout master to get back to the latest commit).

from nton.

Also, you said in another issue:

no matter what I do, the resulting NSP does not launch for me, but your prebuilt ones do so I'm not sure what I could be doing wrong.

This sounds to me like you could be providing the NRO path from your C:/ drive. It's incredibly important to provide it from your Switch's microSD card. It's also important to never move that NRO file. Your Step 8 builds at "X:/hbmenu.nro", are you sure that file is still there?

The following is the exact build call used when making a release:

It only uses --sdmc because the path to the NRO is in this case on the C:/ drive (just by relative path). Therefore, by specifying --sdmc I can bypass the restriction of it being on the Switch's SD card since obviously, the auto-release system wouldn't have one.

from nton.

You could just place prod.keys wherever your terminal/cmd currently is, e.g., if your terminal has cd to Desktop, put it in the Desktop.

I totally forgot that was an option. Will try tonight.

Are you referring to the one under NTON releases in the Assets section? This makes it even more clear that it could be the new ExeFS ROM as that forwarder would have been built on the older ExeFS ROM.

Yes. But if I build my own forwarder with the old ExeFS ROM, I still get the same issue so I don't think it's that.

poetry run nton build "hbmenu.nro" --name "Homebrew Menu" --sdmc "/hbmenu.nro"

I will try this, but as per the readme I built it as follows (my Switch SD card was plugged into my PC with a MicroSD card adapter, with the drive letter H):

poetry run nton build --name "Homebrew Menu" "H:/hbmenu.nro"

And it clearly finds the NRO properly, since it pulls the version and developer strings properly and automatically adds the correct icon and sets the title ID. The NRO is still in that location, otherwise I would never be able to launch the Homebrew Menu. I'm wondering if building it that way is adding the drive letter to the path and the Switch is look for "H:/" instead of "sdmc:/"?

from nton.

I'm wondering if building it that way is adding the drive letter to the path and the Switch is look for "H:/" instead of "sdmc:/"?

If you go to this line,

And after it add print(path, sdmc), what is printed? There's a possibility it will be H:\hbmenu.nro.

from nton.

Yup, it outputs this:

E:\hbmenu.nro E:\hbmenu.nro

So there is something wrong with that logic. It switches the forward slash to a backslash, so is this an issue with the path resolution and the fact that Windows uses backslashes maybe?

Also, looking at the entire block that checks for the C drive, I think this logic is not the right way to go about creating the path if I'm honest. I feel like the user should just be required to specify the full sdmc path to build because I have 4 SSDs in my PC so checking only for C is kind of pointless, since I could be running this from any other drive.

I'm not at home right now so I can't connect my Switch SD card to my PC so I just remoted in to my PC and put the NRO on the root of one of my other drives (E:) and nton has no idea that E:\ is not my SD card.

from nton.

Yup, it outputs this:

E:\hbmenu.nro E:\hbmenu.nro

I fixed that here, f7845a2 maybe it works now? I wonder if this fixes the rest of the issues you were having.

I feel like the user should just be required to specify the full sdmc path to build
checking only for C is kind of pointless, since I could be running this from any other drive

While this is true, that it's not efficient, it's the only option I have. The only other possibility would be to somehow check if a Drive is a removable device, but also specifically a SD card/reader. Forcing everyone to provide the --sdmc by default is also not better since they then have to still write down the exact path and be sure of it. It just introduces more possibilities of error (e.g., typos, them misremembering the path, and if they go to check they would have the microSD open ready to use like we do now anyway).

The current way of basing it off the NRO path, then optionally having an override with --sdmc is the cleanest solution. It would be more-or-less perfect if I had a way to know for-sure if the input NRO was on an SD card or not. One way I was thinking was to get the drive path, do "X:/Nintendo" and see if this folder exists. However, this would mean that people using NTON on a completely fresh SD card would fail.

from nton.

Nope, that outputs the following:

E:\hbmenu.nro E:/hbmenu.nro

So now it doesn't flip the slash on the sdmc path, but it does on the NRO path, but both still show the drive letter instead of the second one showing sdmc:/

Also, I don't quite understand the complexity issue about the paths. This tool is already more complex than what 99% of Switch users are even willing to look at, being that most of them are kids who just follow a guide to do everything. I'm a programmer myself (it's what I do for a living) and I think most people using this tool would be technically capable enough to enter in a relative path ("/" for sdmc root, "/switch/homebrew/homebrew.nro", etc). It doesn't really seem that complex to me.

I get the intent behind it, but like I said, anyone with more than one drive could easily bypass that C drive check without even realizing it. I technically would have if I hadn't read the readme because my downloads folder is on a second drive and I cloned the repo into my downloads folder.

from nton.

path.resolve().absolute().as_posix().replace(path.drive, "sdmc:")

The above should work (at least it outputs correctly, I can't test the NSP until I get home).

The reason it didn't work is because "path.drive" already includes the colon, so "{path.drive}:/" ended up with two colons and didn't match the replace.

from nton.

Nope, that outputs the following:

E:\hbmenu.nro E:/hbmenu.nro

Ahh, I have this properly fixed now by using anchor instead of malforming drive.

I think most people using this tool would be technically capable enough to enter in a relative path ("/" for sdmc root, "/switch/homebrew/homebrew.nro", etc)

Not sure I understand what you mean. They would need to specify the NRO path and then the SDMC path. That would be hella repetitive in various ways, prone to typos, mistakes, etc. If you're a programmer I'm sure you have encountered numerous brain-dead users across your journey lmfao. I'd rather try to make the user experience as easy as possible over dealing with 90 emails through my git commit email asking why it crashes on launch.

anyone with more than one drive could easily bypass that C drive check without even realizing it

Yeah again, there is even a TODO comment relating to that exact problem, the fact that it isn't perfectly efficient.
Or rather, wasn't. I commit this 8925b0f which checks by looking for Nintendo & switch folders, or atmosphere & bootloader (hekate) folders. This will be quite a bit more efficient, enough to remove that TODO comment, but even still it has holes. E.g., a completely blank SD that they are preparing via packs and then trying to do forwarders with.

The reason it didn't work is because "path.drive" already includes the colon, so "{path.drive}:/" ended up with two colons and didn't match the replace.

It's kind of strange how this has only begun to be a problem recently. I could have sworn this code was tested working and all. It's old code even, from versions back. Strange stuff.

from nton.

What I mean is have the command something like these examples:

nton build --name "Homebrew Menu" --nro "C:\...\hbmenu.nro" --sdmc "/"

nton build --name "Edizon" --nro "C:\...\edizon.nro" --sdmc "/switch/Edizon/"

I mean yah, there is some redundancy but if you're forced to set both paths manually then you don't have to make any assumptions or do any weird transformations to the NRO path, or try to figure out of it's an SD card or not. All you have to do is take the specified sdmc path and place the NRO file name at the end of it.

I have used tons of applications that require you to specify two similar paths, it's just for sanity really. I'm all for making it easier for people but also even the documentation on the paths is confusing. The "H:/hbmenu.nro" example in the readme actually confused me for a bit last night because I wasn't sure if I was supposed to be putting a drive letter or what the example was really trying to say.

from nton.

That's only slightly less repetition though. I'd find that very annoying to do personally. Like think about it. Here's why it's just more work:

• First things first, this would only ever be more convenient over a single path on the Switch microSD card, if they don't have the option or can't be bothered to insert their microSD card into their PC.
• If they could put it into the PC, then why not just use the one path.
• If they cant put it into the PC, then they have to guess or remember the folder/path as well as the NRO filename. Sometimes the NRO filename to not be the same one as downloaded via stuff like the HB Store versus GitHub Releases e.t.c.

Overall it's just more work in terms of remembering, figuring out, and possibly renaming the NRO if we do your relative sdmc method. Which then brings in the guessing/remembering problems again, for the NRO filename.

EDIT: Another issue that gets brought up by not explicitly using the NRO on the microSD card, is that you may or may not be using the correct NRO on your PC that you have on your microSD card. This may lead to incorrect values on your generated NSP in regards to Icon (if it changed) or Version, or other general NACP stuff.

from nton.

I think we'll have to agree to disagree on this one, but it is your software and you are free to write it as you wish. I appreciate that it even exists though.

I will try the resulting NSP with the new ExeFS ROM and let you know how it goes.

from nton.

The path thing fixed it, NSP works now and I tried with the new ExeFS ROM and it does work, homebrew closes now without crashing (although, back to the home screen instead of the Homebrew Menu, but that's fine).

from nton.

Fantastic news :)

from nton.