Right now: copy your Mods folder somewhere else, then rename the original Mods_off and launch the game. If it runs fine without mods, the test can begin. If it still breaks, a mod isn't the cause and this page won't help — the full guide will. Nothing here deletes anything, and you'll know when to stop: that's a case often left out.
This test is the guide's last resort, and it should stay last: only start it if nothing else explained your problem. Before it, two two-minute checks. Has the game just updated? Then it unticked your mods, and no test will find a file that isn't even loaded: tick them again first (guide, step 1). Is OneDrive or iCloud touching your folder? If they left only empty stubs on disk, what you're testing changes from one launch to the next, and the test is wrong from start to finish: fix that first (guide, step 3).
Rename your Mods folder to Mods_off (Documents → Electronic Arts → The Sims 4), launch the game, open the same save and repeat the same action that used to crash. The game recreates an empty Mods folder and a healthy Resource.cfg: that's normal. Two outcomes. It still breaks: a mod isn't the cause — the game, a save, a cache — and the rest of this page doesn't apply; put Mods back and return to the guide. It runs fine: a file is involved, or the sheer volume — and that's exactly what the test is going to settle.
If your problem is random — sometimes yes, sometimes no, with no precise trigger — one clean launch proves nothing. The test needs a fault you know how to reproduce; otherwise it will clear the culprit half the time.
Create a third folder next to the other two: Mods_ok. The rule, the same at every launch: what's in Mods is being tested; what's in Mods_off is waiting its turn; what's in Mods_ok is cleared. Move half of what sits at the top level of Mods_off — folders and files, whole, without opening them — into Mods. Launch the game, same save, same action. It breaks: the culprit is in Mods, and everything still in Mods_off goes to Mods_ok. It runs fine: the culprit is in Mods_off, and everything that was in Mods goes to Mods_ok. Then split what's still suspect in two — one half in Mods, the other in Mods_off — and relaunch. Each launch halves the suspects: 1,000 items → 500 → 250 → 125 → 63 → 32 → 16 → 8 → 4 → 2 → 1, ten launches; eight are enough for two hundred. When you're down to a single folder holding a hundred files, carry on inside it the same way.
When a single suspect is left, don't name it yet: "it's the only one left" is not "it's the one". The last round is the only one that proves anything — put everything back into Mods, Mods_ok included, except that one. If the game runs fine without it and breaks as soon as it comes back, it's the one. If the game breaks without it too, it doesn't explain the fault on its own: go straight to step 5.
A shortcut that saves hours: if your game freezes in build mode when you type in the search bar, start by putting only your Build/Buy CC into Mods, nothing else. It's a case the community knows well, caused by broken CC — often old, and still up for download somewhere. It has nothing to do with a recent patch.
On paper or in a text file, one line per launch: the number, what's in Mods (folder names are enough), what you did, the result. By the fourth launch without notes, nobody knows what's been tested anymore — and that's how people wipe everything and start over. One line looks like this: "3 — Mods: CC_hair, Gameplay_scripts — the Smith save, build mode, typed in the search bar — froze".
During the test, half your content is missing: Sims who wore custom hair or clothes show up bald or naked, custom furniture is gone. That's normal, and putting the files back fixes it. But a save made while that content is missing can forget it for good: your Sims stay bald even after the files are back. For as long as the test lasts, quit without saving — or, if you really must save, save under a different name. Your copy of Mods and a save from before the test are your two safety nets.
This is a case often left out, and you need to recognise it before you spend the night on it. Three signs: the game runs fine with each half on its own and breaks when they're together; the "guilty" half changes from one round to the next, with no logic to it; or the game runs fine as long as Mods stays small enough, whatever you put in it. That isn't a failed test, it's a result. It has two readings, and only the test can tell them apart.
First reading: two files that can't stand each other. Each is fine alone; together, they break. The test still finds them, in two passes: keep one half whole in Mods and run the test on the other — you land on the file that clashes with something in the first half; then keep that file and run the test on the first half. The last round must then break with the two together, and pass as soon as either one is removed.
Second reading: it isn't a file, it's the volume. The game runs fine with one half — any half — and breaks with everything. There's no culprit to find here, and carrying on with the test will only hand you a different name every night. There's no number to give you either: no threshold has been measured here, and an invented one would send you looking in the wrong place. What's left to do is simpler, and fairer: lighten the load. Set aside in Mods_off — never in the bin — what you no longer use, folder by folder; bring back first what you actually play with; relaunch after each addition, and stop at the last addition that still runs fine. And if all this happens right after a game update, check first the list of broken mods the community keeps on the official forum: a file a patch just broke isn't found by halves, it gets updated.
You have it all: the method, the traps, and the case where you have to stop.