Hey, so I have some bad news and possible some
really,
really bad news.
I've seen this type of data corruption before where the folders and files are strangely [mis]spelled in the CTRNAND.
- ? (This is an illegal character. Try renaming a folder or file with this char on computer or GodMode9. Not allowed.)
- extdata → ex4da4a (substituted letters)
Also, while words are not case sensitive,
- ro → Ro
- __journal.nn_ → __jOurnal.nn_
- Example: data | DATA | dAtA | daTA , etc. are technically all equal to each other.
, having their letters changed to capital form without you purposely doing this raises red flags.
***
This mishap could have been caused (in the first place) by failed system update, manual install of system title CIAs corrupted by a failing or fake SD card, or from repeated CTRTransfer(s) that end up messing with the partition table keeping track of all the items you're supposed to have on the CTRNAND.
Here's a prime example of this seen in this thread, and it is the main reason why CTRTransfer (Type D9) was developed in the first place to fix this sort of softbrick.
The bad news.
Before you started using
CTRTransfer (Type D9), did you make sure to read the warning and follow step 3 found in
Instructions?
One of the drawbacks of the Decrypt9 approach of CTRTransfer is that instead of fixing the 3DS firmware, you can very much make it worse if the SD card is fake or faulty.
The way (Type D9) works is to pull certain files and folders out of the CTRNAND, force reflash the RAW ctrnand *.bin image to that partition, and then add back your console unique + personal items back to CTRNAND.
Using (Type D9) on a bad SD card would be like if a pregnant woman got C-section ran into a complication where the surgeons required temporarily taking out and setting her intestines aside on an operating table, but that table being used wasn't sterilized as well as it should have been. After they deliver her baby and put her guts back in, she develops post infection to her organs and requires heavy dosages of antibiotics to stay alive.
Okay, maybe the analogy is over-dramatic, but basically
- bad SD card ≈ dirty operating table
From your
post #5, did you make sure to test the SD card in H2testw with the card starting
empty or
blank? If so, did the program report any errors?
The really, really bad news.
If you can absolutely verify the SD card had
GOOD results, the most likely reason your n2DSXL crashes a lot is due to a failing motherboard.
Story Time
I once helped this user who came to the noob paradise thread seeking to fix his n2DSXL. We continued our discussion in PM, so I can only share excerpts.
* The details story of this might be stretched in truth.
Despite our best efforts trying to revive his n2DSXL
*going so far as ship his n2DSXL from the Netherlands all the way to Florida, we were not able to dump his
ctrnand_full.bin,
twln.bin, and
twlp.bin partition images from the
[S:] SYSNAND VIRTUAL. There's a method of manually debugging someone's 3DS firmware by dumping those images and using them on another working 3DS system (has to be same OLD / NEW series). We were never able to get past dumping those images because GodMode9 kept crashing whenever trying to
Copy to 0:/gm9/out. In fact, Jiyorude noted some of his NAND's virtual files were named as "
?"
before he sent his n2DSXL to me.
After I air shipped back his n2DSXL marking it as a lost cause, Jiyorude eventually got his n2DSXL entirely replaced by Nintendo with another unit as it was still under warranty.
It was later concluded that the reason his n2DSXL acted the way it did was due to a failed eMMC (ie, the physical NAND chip).
***
In case your n2DSXL internal storage is going bad,
The eMMC found on the 3DS systems is not that much different than the SD card. They can and do fail like any flash memory.
While it is technically possible to run a crude diagnostic test (similar to H2testw / F3 / F3X) on the eMMC to determine if it's on way out (R.I.P.), I refuse to share the step-by-step instructions in how to do it because of the extremely high risks in softbricking (bootrom 8046)
blue screens of death and/or permanently erasing console unique + personal files.
What you can do instead is bypass the borked eMMC by switching over to an EmuNAND setup. This requires flashing a previously backed up (clean) SysNAND *.bin image onto the SD card.
To activate EmuNAND once it is created on the SD card, go to
Luma3DS v#.# configuration and use these settings.
- (x) Autoboot EmuNAND
- (x) show NAND or user string in System Settings
Go to
System Settings to look for 3DS firmware string,
Emu 11.13.0-45U.
If the n2DSXL does stabilizes, keep in mind DSiWare and GBA VC games will no longer work in EmuNAND unless you continually update the SysNAND to match the EmuNAND whenever removing or installing new games.
- GodMode9 → (HOME) button → Scripts... → NANDManager → <LEFT> Transfer Emu to Sys
- You may need to backup the DSiWare saves in the [2:] SYSNAND TWLN before the transfer and then re-add them back to keep them from getting erased: CTRTransfer (Type D9) - DSiWare CIAs & Saves
***
In case the n2DSXL still crashes despite using EmuNAND,
I've ran out of party tricks by this point.
You can try to get your n2DSXL fixed by,
There's also testerfan. He specializes in SMD/SMT level board repairs, although he doesn't seem to offer service for n2DSXL.
There's also replacing the n2DSXL motherboard.
Replacing the motherboard would require System Transfer or SDTransfer when migrating the user profile and games.
Lastly, there's buying a replacement 3DS system. I recommend purchasing a New 3DS XL over the New 2DS XL for durability and repairability reasons. Check my signature; see the Nintendo official refurbished models.
