Homebrew Homebrew app sys-patch - sysmod that patches on boot

[bombayjack]

sys-patch should not deploy atmosphere related config files to the end user.

either way, the return of 0x11653c (21.1.0) in NIM is what determines if an update is being initiated.

and that gets the value determining if its updating from function if that function (the one below) returns zero, it will fetch the update.


0x166FE0 (20.5.0)
0x1657F0 (21.0.0)
0x1657E0 (21.1.0)

(RET 1 - patch applied to that offset (00 08 size)
20 00 80 d2 c0 03 5F


View attachment 544173View attachment 544175

You forgot to put D6 at the end of the RET, however I just tried the patch on 20.5.0 and it still downloads the update nca files. But thanks for looking.

Here's a patch, this one is working now: (System Update Blocking patch)

412CA954A47280118C72280EFAEAC33F490793B6.ips

50 41 54 43 48 11 B3 10 00 04 C0 03 5F D6 11 93 84 00 04 C0 03 5F D6 45 4F 46

Now we can't update, 1st address is for debug firmware updates, second address is for firmware updates.

Here's the offsets from firmware blocking from 10-21+
(note 10/11 old routines but I tested them and they were good) 14.x is odd because 12.x and 13.x look like the same kind of patterns as 15+ so I need to recheck that as it seems wrong.

1000 - 105FD0 - 00 00 00 00 FC6FBAA9FA6701A9F85F02A9F65703A9F44F04A9FD7B05A9FD430191FF4317D1FF231139F30301AA
1100 - 10BED8 - C0 03 5F D6 FC0F1CF8F65701A9F44F02A9FD7B03A9FDC30091FF0317D1FF031139F30301AA014C40F9F40300AA
1200 - 11696C - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FFC328D1FF831D39F30301AA014C40F9F40300AAE0831D91
1210 - 116B9C - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1300 - 11EADC - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1310 - 11F2CC - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1321 - 11FFFC - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1400 - 105DAC - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FFC32BD1FF632039F30301AA014C40F9F40300AA
1500 -  E97D4 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FFC32BD1F30301AA014C40F9F40300AAE0832091
1601 -  DCCE4 - C0 03 5F D6 FD7BBCA9FC0B00F9F65702A9F44F03A9FD030091FFC32BD1F30301AA014C40F9F40300AAE0832091
1700 -  E02C4 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF432CD1F30301AA014C40F9F40300AAE0032191
1801 -  E3704 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
1900 -  E8A34 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2001 - 119164 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2010 - 119384 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2100 - 114670 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2110 - 114600 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291


(12.x/13x/15-21+) - wildcard pattern + 0x04
C0035FD6FD7BB.A9FC.....9F...0...F...0.A9F.......FF.3....F30301AA014C40F9F40300AAE0.3..91

10.x/11.x/14.x
Just use shown patterns

 

[bth]

You forgot to put D6 at the end of the RET, however I just tried the patch on 20.5.0 and it still downloads the update nca files. But thanks for looking.

Here's a patch, this one is working now: (System Update Blocking patch)

412CA954A47280118C72280EFAEAC33F490793B6.ips

50 41 54 43 48 11 B3 10 00 04 C0 03 5F D6 11 93 84 00 04 C0 03 5F D6 45 4F 46

Now we can't update, 1st address is for debug firmware updates, second address is for firmware updates.

Here's the offsets from firmware blocking from 10-21+
(note 10/11 old routines but I tested them and they were good) 14.x is odd because 12.x and 13.x look like the same kind of patterns as 15+ so I need to recheck that as it seems wrong.

1000 - 105FD0 - 00 00 00 00 FC6FBAA9FA6701A9F85F02A9F65703A9F44F04A9FD7B05A9FD430191FF4317D1FF231139F30301AA
1100 - 10BED8 - C0 03 5F D6 FC0F1CF8F65701A9F44F02A9FD7B03A9FDC30091FF0317D1FF031139F30301AA014C40F9F40300AA
1200 - 11696C - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FFC328D1FF831D39F30301AA014C40F9F40300AAE0831D91
1210 - 116B9C - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1300 - 11EADC - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1310 - 11F2CC - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1321 - 11FFFC - C0 03 5F D6 FD7BBDA9FC5701A9FD030091F44F02A9FF4329D1FF031E39F30301AA014C40F9F40300AAE0031E91
1400 - 105DAC - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FFC32BD1FF632039F30301AA014C40F9F40300AA
1500 -  E97D4 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FFC32BD1F30301AA014C40F9F40300AAE0832091
1601 -  DCCE4 - C0 03 5F D6 FD7BBCA9FC0B00F9F65702A9F44F03A9FD030091FFC32BD1F30301AA014C40F9F40300AAE0832091
1700 -  E02C4 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF432CD1F30301AA014C40F9F40300AAE0032191
1801 -  E3704 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
1900 -  E8A34 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2001 - 119164 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2010 - 119384 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2100 - 114670 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291
2110 - 114600 - C0 03 5F D6 FD7BBCA9FC0B00F9FD030091F65702A9F44F03A9FF032ED1F30301AA014C40F9F40300AAE0C32291


(12.x/13x/15-21+) - wildcard pattern + 0x04
C0035FD6FD7BB.A9FC.....9F...0...F...0.A9F.......FF.3....F30301AA014C40F9F40300AAE0.3..91

10.x/11.x/14.x
Just use shown patterns

i would prefer if the patch was MOV X0, XZR, RET ( e0 03 1f aa c0 03 5f d6 ) ( - size 0008) (the offset itself is fine, but the function returns zero when it's supposed to be done with its job) (just returning to the calling function without something loaded for it to return just going to cause problems with the IPC/SVCs, better to feed it the value which indicates completion/success)

 

[bombayjack]

i would prefer if the patch was MOV X0, XZR, RET ( e0 03 1f aa c0 03 5f d6 ) ( - size 0008) (the offset itself is fine, but the function returns zero when it's supposed to be done with its job) (just returning to the calling function without something loaded for it to return just going to cause problems with the IPC/SVCs, better to feed it the value which indicates completion/success)

View attachment 544306

I tested both ways out, but it doesn't make any difference. I've written the code for sys-patch now and tested it on every firmware from 10-21+ and it's working fine for them all, It's simply a case of adding those 4 bytes to the patch (1 line to change), so I can do that. I've also cleaned up/optimised the sys-patch code now and added debug compiling flags so the compiled code is now only 94kb while still keeping all the new stuff that I added. I also changed the heap back to 0x1000 as before since it works fine with that for now. I've got some more tweaks to add to the the overlay but for now everything is working great. Here's the updated sys-patch if you want to take a look at it. Also please check but the new patch for blocking seems to also fix the endless loop fix for forwarders in 21+. (good side effect to have), I'll remove the code from the overlay I added to fix that if it's working for you as well (It could just be 21.1.0 firmware fixed that).

 

[bth]

I tested both ways out, but it doesn't make any difference. I've written the code for sys-patch now and tested it on every firmware from 10-21+ and it's working fine for them all, It's simply a case of adding those 4 bytes to the patch (1 line to change), so I can do that. I've also cleaned up/optimised the sys-patch code now and added debug compiling flags so the compiled code is now only 94kb while still keeping all the new stuff that I added. I also changed the heap back to 0x1000 as before since it works fine with that for now. I've got some more tweaks to add to the the overlay but for now everything is working great. Here's the updated sys-patch if you want to take a look at it.

no to olsc config stuff in overlay. that's not within scope of what sys-patch should do. it's entirely dependant on end user having nx-ovlloader present.

not sure why you have removed the functions that create /config/sys-patch/

im not sure why you have changed mov2_cond from 0x2A/0x92 to 0xAA/0x92

it seems with your additions to the conds, you perhaps dont fully understand the pre-existing naming conventions.

it's mov2 cond because it represents the arm instruction with the same name, beq_cond, because it's a arm instruction b.eq, and so on, so i don't approve the changes related to that (in form of naming conventions and abstractions of the concept, such as unrelated arm instruction bits placed in them, or removal of some from others)

i understand your intent in refactoring the conds, but there already was code for utilising only x or y cond for x or y firmware within the pattern definitions.

i also disapprove of loader patch reversion, and non-compliance with naming conventions, as it still is noacidsigchk, inside of loader, moved out from fs in 10.0.0.

the pattern section is too inconsistent

there's no need for the changes you did under "
PatchEntry patches[]", nor a nim2 catagory with the exact same titleid, see FS patch pattern/code structure.



also rebase your work onto latest master of 1.5.8, as im assuming thats where some of your weird changes originate from (not being up to date)

 

[bombayjack]

no to olsc config stuff in overlay. that's not within scope of what sys-patch should do. it's entirely dependant on end user having nx-ovlloader present.

not sure why you have removed the functions that create /config/sys-patch/

im not sure why you have changed mov2_cond from 0x2A/0x92 to 0xAA/0x92

it seems with your additions to the conds, you perhaps dont fully understand the pre-existing naming conventions.

it's mov2 cond because it represents the arm instruction with the same name, beq_cond, because it's a arm instruction b.eq, and so on, so i don't approve the changes related to that (in form of naming conventions and abstractions of the concept, such as unrelated arm instruction bits placed in them, or removal of some from others)

i understand your intent in refactoring the conds, but there already was code for utilising only x or y cond for x or y firmware within the pattern definitions.

i also disapprove of loader patch reversion, and non-compliance with naming conventions, as it still is noacidsigchk, inside of loader, moved out from fs in 10.0.0.

the pattern section is too inconsistent

there's no need for the changes you did under "
PatchEntry patches[]", nor a nim2 catagory with the exact same titleid, see FS patch pattern/code structure.

Yep, it's for personal use though and that's how I want it, I'm posting the code so you can check out the update blocking patch. Don't worry about names of things, (that's not important for me) . If you want you can take some code out - just what you want, things like the reboot code in the overlay as an example. I'm not wanting to be a releaser, I'll leave that to you.

Edit; I forgot to make a linked account in the emunand I was testing on, so looping patch still needs added, so for now I will keep that in the overlay until a patch is found.

 

[bth]

Yep, it's for personal use though and that's how I want it, I'm posting the code so you can check out the update blocking patch and to check it also fixed the forwarder looping issues on 21+ firmware. Don't worry about names of things, (that's not important for me) . If you want you can take some code out - just what you want, things like the reboot code in the overlay as an example.

too much of mess to want to deal with, make naming conventions be consistent or don't bother with it.

maybe the vibecoding IDE's read that just fine, but it's not nice to read for humans.

 

[bombayjack]

too much of mess to want to deal with, make naming conventions be consistent or don't bother with it.

maybe the vibecoding IDE's read that just fine, but it's not nice to read for humans.

No problem, I was just trying to help but I can see you have your own way of doing things just like we all do. So what kind of things are you open to? Do I ask for a feature and then you add it? I already tried that, so I am lost to what else to do. I've tried asking, I've tried coding and giving it to you to try and help, but that's not good enough - I'm not you so I have my own way of doing things and I've not coded much in c++ before (only Arduino stuff) ,so...... I've also just owned a switch for a few weeks now so am a noob on it. So what do you exactly want people to say or do when they want a feature like loop blocking patch or something else as I don't really get you at all. You've given lots of advice about patches and screen shotted quite a few, but every single one I tried didn't work? At this point I just don't think you want any help or anyone to ask you to add anything to sys-patch, but I could be wrong or at least I hope I am.

 

[bth]

No problem, I was just trying to help but I can see you have your own way of doing things just like we all do. So what kind of things are you open to? Do I ask for a feature and then you add it? I already tried that, so I am lost to what else to do. I've tried asking, I've tried coding and giving it to you to try and help, but that's not good enough - I'm not you so I have my own way of doing things and I've not coded much in c++ before (only Arduino stuff) ,so...... I've also just owned a switch for a few weeks now so am a noob on it. So what do you exactly want people to say or do when they want a feature like loop blocking patch or something else as I don't really get you at all. You've given lots of advice about patches and screen shotted quite a few, but every single one I tried didn't work? At this point I just don't think you want any help or anyone to ask you to add anything to sys-patch, but I could be wrong or at least I hope I am.

you have not made a patch for OLSC; you have just made the optional overlay make an atmoshere config. The appropriate patch should be to OLSC.

as for "not wanting to help", you say you are inexperienced, so i went through the effort to show you exactly where in switchbrew, in both functions, both the svc/ipc in both ends of functions are, so that you can see for youself how that works. everything is related to another (READ SWITCHBREW DOCUMENTATION, READ ATMOSPHERE SOURCECODE)

you should not just ret without value, in the function desired, i tell you this and you go "i don't see any difference", but the underlying code does.

i provde you feedback, i tell you exactly where to look, and hope that you arrive at the conclusion you desire.

as for OLSC, i kind of already hinted and showed the functions where one would accomplish that in earlier posts as well.

im not doing this for you, i am forcing you to learn it yourself.


(im not going to apologize for you not being familiar with machinecode/arm instructions/ghidra, and not being able to feed your LLM the data or drawings i make on it to make sense out of it)

 

[bombayjack]

Thanks, but I'll have a look for more patches later, Just now I'm working on updating the overlay.

Post automatically merged: Dec 11, 2025

Here's for those that want to test it, redesigned overlay and fimware blocking patch added. All code has been cleaned up now so this is the first release for this. It shouldn't have any bugs as I spent all day going through the code and checking stuff out.

This isn't a bug as such, but I need to write some new/better code for IPS patch detection. I already started this and tested it for ldr patch with fusse/hekate booting and it works fine, so just need to do it for the other patches. That way it should work properly for all IPS patches from now on. I'll probably do that in the next day or so.

 

[TheCrow32]

Hello, I'm using sys-patch 1.5.8 v5 with AMS 1.10.1 and HOS version 20.1.1. I just noticed a behavior where homebrew apps would crash when "Disable CA Verification" patches are enabled. Homebrew apps that crash in my Switch are AIO Switch Updater, Edizon, Breeze, JKSV, and Sphaira. I'm also using the updated versions of these apps for 20.0.0+

 

[bth]

Hello, I'm using sys-patch 1.5.8 v5 with AMS 1.10.1 and HOS version 20.1.1. I just noticed a behavior where homebrew apps would crash when "Disable CA Verification" patches are enabled. Homebrew apps that crash in my Switch are AIO Switch Updater, Edizon, Breeze, JKSV, and Sphaira. I'm also using the updated versions of these apps for 20.0.0+

"Disable CA Verification" are for advanced users only and default to disabled for that reason.

Nintendo didn't refactor ssl until 21.0.0, so the patch embedded in sys-patch should still be valid for below.
(they most likely will be removed from sys-patch next version anyway, as to prevent people such as yourself from enabling them when they shouldn't)

you're thinking of updated for 21.0.0+, not 20.0.0+, paired with atmosphere 1.10

the reasons "app crash" is because the "Disable CA Verification" requires an actual mitm setup (no, not dns-mitm in atmosphere, actual proper mitm) to use properly (advanced users only)

 

[bombayjack]

@bth

I was testing erpt patch on 21.x today, when debugging it I noticed that you need to update this:

constexpr auto stp_cond(u32 inst) -> bool {
const auto bth = (inst >> 24) == 0xA9;
const auto good = (inst >> 24) == 0xD1; //this works on 21+ - check BTH on lower FW
return bth || good;
}

I didn't check on other firmware, but for 21.x stp_cond will return false because you need to change the check to 0xD1, and then it passes and works fine. I tested it with the firmware update blocker and connecting to eshop and it prevents the switch from crashing.

[ErrorTelemetry.no_erpt]
IDA_offset_address=0x4460
Actual_offset_address=0x4360
Memory_address=0x7496404360
Original_instruction first 4 bytes=0xFF4305D1
Patched_instruction=0xE0031F2AC0035FD6
Result=Patched (sys-patch)

 

[Naxster]

Where can we download the latest Sys-patch version that works for firmware 21.0.1?
GitHub haven't been updated in about a month now.

 

[browntigerz]

Where can we download the latest Sys-patch version that works for firmware 21.0.1?
GitHub haven't been updated in about a month now.

When i search sys patch, the first link i get is to impeezas sys patch github

Post automatically merged: Dec 14, 2025

When i search sys patch, the first link i get is to impeezas sys patch github. Which is what im using.

 

[bombayjack]

Where can we download the latest Sys-patch version that works for firmware 21.0.1?
GitHub haven't been updated in about a month now.

You can try this, it's an updated version of sys-patch. Currently a WIP but is up to date with all the patches. NOTE: If using IPS patches the log will show as unpatched because they are not patched by this. I've still got IPS patch detection to add which I removed from the code for now as it was not working properly.

 

[misterbean86]

hello, dunno if this has been answered but when i put my switch v2 into sleep mode and then power it on with a game active, it crashed. i think its something with the patches but not sure

edit: i did a bit of searching and people suggested to enable airplane mode, i did that and it doesnt crash anymore which is awesome, i dont mind this solution but is there a better alternative?

 

[bth]

@bth

I was testing erpt patch on 21.x today, when debugging it I noticed that you need to update this:

constexpr auto stp_cond(u32 inst) -> bool {
const auto bth = (inst >> 24) == 0xA9;
const auto good = (inst >> 24) == 0xD1; //this works on 21+ - check BTH on lower FW
return bth || good;
}

I didn't check on other firmware, but for 21.x stp_cond will return false because you need to change the check to 0xD1, and then it passes and works fine. I tested it with the firmware update blocker and connecting to eshop and it prevents the switch from crashing.

[ErrorTelemetry.no_erpt]
IDA_offset_address=0x4460
Actual_offset_address=0x4360
Memory_address=0x7496404360
Original_instruction first 4 bytes=0xFF4305D1
Patched_instruction=0xE0031F2AC0035FD6
Result=Patched (sys-patch)

https://armconverter.com/?disasm&lock=arm64&code=FF4305D1

no. that is not a stp arm instruction.

stop adding unrelated arm instruction register bits to unrelated arm instruction conds.

erpt doesn't crash consoles, the optional no-erpt patch sole purpose is to not create error reports on SD card.

and the actual code says sub_cond, and the pattern string itself even says in the comments, that it's a sub arm instruction, nowhere in erpt is there stp.

stp_cond is only used by ctest, nothing else. read the source code.

https://github.com/impeeza/sys-patch/blob/master/sysmod/src/main.cpp#L129-L132

constexpr auto sub_cond(u32 inst) -> bool {
    const auto type = inst >> 24;
    return type == 0xD1; // sub sp, sp, #0x150
}

https://github.com/impeeza/sys-patch/blob/master/sysmod/src/main.cpp#L295

 { "no_erpt", "0x...D1FD7B02A9FD830091F76305A9", 0, 0, sub_cond, erpt_patch, erpt_applied, false }, // FF4305D1 - sub sp, sp, #0x150 patched to E0031F2AC0035FD6 - mov w0, wzr, ret

i find it disrespectful for you to lie like this, stop asking LLM/"AI" to hallucinate things that aren't real for you.

rebase to latest master already, stop spreading misinformation.

at least put in the effort into reading the code before making up nonsense.

i try to be charitable, but i have already told you to rebase master once before, and you still mention me with such nonsense.
https://git-scm.com/book/en/v2/Git-Branching-Rebasing

 

[bombayjack]

i try to be charitable, but i have already told you to rebase master once before, and you still mention me with such nonsense.
https://git-scm.com/book/en/v2/Git-Branching-Rebasing

You must have me mixed up with someone else, I've neve spoken to you about this ever. Maybe you think I am someone I'm not. I've never even heard of that website you've linked. Also erpt can crash consoles, especially if in your Atmosphere folder you made that folder into a file so it wouldn't keep writing logs to it, in that case erpt patch can stop the switch from crashing.

 

[bth]

You must have me mixed up with someone else, I've neve spoken to you about this ever. Maybe you think I am someone I'm not. I've never even heard of that website you've linked. Also erpt can crash consoles, especially if in your Atmosphere folder you made that folder into a file so it wouldn't keep writing logs to it, in that case erpt patch can stop the switch from crashing.

also rebase your work onto latest master of 1.5.8, as im assuming thats where some of your weird changes originate from (not being up to date)

Why exactly are you trying to gaslight me? Your response doesn't invalidate none of what you just replied to. You're making up nonsense and spreading misinformation and attributing the nonsense you make up to me. Very disrespectful.

If you don't know how git works, i provided the link, as i already told you once to rebase, and apparently you did not.

 

[bombayjack]

Why exactly are you trying to gaslight me? Your response doesn't invalidate none of what you just replied to. You're making up nonsense and spreading misinformation and attributing the nonsense you make up to me. Very disrespectful.

If you don't know how git works, i provided the link, as i already told you once to rebase, and apparently you did not.

What are you talking about, you sound crazy.

I downloaded the source code from here:
https://github.com/impeeza/sys-patch/releases/tag/v1.5.8
https://github.com/impeeza/sys-patch/archive/refs/tags/v1.5.8.zip

This is what is in the code:

constinit Patterns erpt_patterns[] = {
    { "no_erpt", "0xFD7B02A9FD830091F76305A9", -4, 0, stp_cond, erpt_patch, erpt_applied, false },

constexpr auto stp_cond(u32 inst) -> bool {
    return (inst >> 24) == 0xA9; // stp x29, x30, [sp, #-0x30]!
}

Download it and look yourself, I didn't come to argue with you, but you seem to have a major issue with my posts, just put me on your ignore list if you find you can't read what I post without going into a meltdown.