So I've just solved an interesting CTD that consistently hit in one area of the map by manually performing a binary search on my save file to locate and delete a bad record and thought I might share the process here since I haven't seen it posted before.
The CTD I was getting was around Riverside Camp - this is a new bandit camp added by the 'More Bandit Camps' mod, so of course my first thought was to remove the mod, but that did not solve it. I had visited the camp previously (it was used as a location for the radient Amulet of the Moon quest, but the Amulet failed to spawn on my earlier visit and I tried returning after enough days had passed that the cell should have respawned), so I knew the area had been okay at some point - so my next thought was to remove some other mods I had recently installed. Again, no dice. I then disabled all mods that had made worldspace edits anywhere in the general area, but of course that did not help.
Starting a new game and navigating here showed that the area loaded just fine - indicating that whatever was wrong was in fact embedded in my save file. Reloading an earlier save file wasn't really a viable option at this point since trying a few older saves showed the CTD had been present for quite a long time, and I would have sooner put the game down than go back to an old enough save that was not impacted. The usual ReSaver cleaning process of 'Remove unattached instances' and 'Remove undefined elements' did nothing, which left one option... Figure out which record(s) in my save were causing the CTD and delete them. That is figure out which ONE out of around ONE HUNDRED AND FIFTY THOUSAND records was causing the CTD.
Everything I've said so far is basically to show you that if you are experiencing a CTD, there are other things to check before embarking on this next procedure. CTDs can be caused by a myriad of different things, so make sure you have eliminated other possibilities and narrowed the issue down to your save file before proceeding.
Okay, so first thing is to travel near the CTD area (but obviously not close enough to actually CTD) and make TWO saves. The first is your backup in case you royally feck up, and the second is the one we will be editing, restoring, editing, restoring, editing, restoring and so on while we narrow things down...
The basic premise of a binary search is simple - with every step we want to eliminate half the possibilities. If we did a perfect binary search the 150,000 records I started with would be narrowed down to 75,000 after the first step, 37,500 after the second step, 18,750 after the third step, 9,375 after the fourth step, 4,688 after the fifth step, and so on. This optimally would require 17-18 steps in total, though we aren't going to be completely optimal so it will probably take a few extra (it took me 21 steps).
The CTD is almost certainly going to be due to a ChangeForm, but to verify that - highlight the ChangeForms folder in ReSaver, press delete and confirm and save. Load up the game (you will be naked since you just deleted all your stuff, among other things) and travel to the offending area and confirm the CTD does not occur - great :)
Now, after every test we are going to replace the original save with the backup file that ReSaver automatically generates, so that we always remove the edited save and resume with the unedited save. You could do otherwise, but you will lose track of what is what and feck something up. I'm not going to repeat this - just know you need to do it after every test. After a dozen steps or so you may zone out and feck something up anyway - that's why you made two saves. I personally put a mv command in a cygwin terminal and ran it after every step to save me cocking this part up, but renaming the file in Windows explorer works just fine. Every four or five tests it will also become necessary to close and reopen ReSaver (because Java is the worst virtual machine ever invented and has no clue how to properly manage memory) - if ReSaver is getting sluggish, restart it.
Okay, so you have confirmed that it is indeed a ChangeForm in your save, and so the next step is to determine which kind of ChangeForm is at fault. Here we are going to start our binary search - expand ChangeForms, click on ACHR and shift click on LVLN. See how you just highlighted roughly half the ChangeForms? Yeah, now you get it ;-) Press delete and save the file. Load it up in Skyrim and see if you still get a CTD. If you did get a CTD it means that one of the entries you did NOT delete is the culprit, but if you did not get a CTD it means one of the entries you DID delete was at fault.
Now, before you go any further open up notepad and write down which record types you have narrowed it down to so far. You are going to update this notepad document after every step, noting which entries you tested and whether the test passed or failed. Keep in mind you might feck something up, so I suggest not deleting anything you write down here in case you need to go back a few steps or double check something without having to start over.
(Restore the original file and reopen it in ReSaver at this point. I won't repeat this again)
So, let's say the CTD did not occur (as was the case for me). That narrows it down to these possible ChangeForm types: ACHR, BOOK, CELL, ECZN, FACT, FLST, INFO, INGR, LCTN, LVLI and LVLN. If that is the case highlight half of these entries (ACHR through FACT) and delete. Load the save in Skyrim and see if you CTD. In my case I did not, so repeat - this time deleting just ACHR, BOOK and CELL. Repeat. No crash. Delete just ACHR and BOOK. No crash. Delete just ACHR. No crash. Okay - it's an ACHR type ChangeForm. Now to work out which one of the 15,000 ACHR records is at fault. Hey - we're already an entire order of magnitude lower than when we started - making good progress :-)
Okay, so within ACHR we are going to use the 32bit hexadecimal identifier to narrow things down, but the numbering is a little odd (which I only noticed on my second pass) - it seems like it starts at 00000014 and goes on to ff00****, then drops back down to 000***** and continues to ff00**** once more... So, that's two large groupings so let's start by working out which of those two groups the CTD is in. Highlight the first entry, scroll down roughly half way to find the last f******* before it resets to 0*******, shift click and delete. Load up the save in Skyrim, and in my case I got a CTD, indicating that the second group is at fault.
Okay, go back in and (in my case) find the start of the second group and click it, then move the scrollbar roughly half way down from there to the end. Pick an entry - record it in your notepad, shift click, delete and test. In my case I actually rounded the target entry to the most significant not-yet-eliminated digit to keep things making sense for my programmer brain (e.g. I landed on 00083eca, so I went back to 00080000), but so long as you ALWAYS WRITE DOWN THE ENTRIES YOU ARE USING SO YOU CAN FIND THEM AGAIN ON THE NEXT PASS you don't have to do that. With each test you should be eliminating approximately half the remaining entries, until eventually you have just one record left, that you can finally delete and move on with your save.
If during this process you have had a few (let's say... four or five?) crashes in a row, do a sanity check and delete all the entries you believe you have narrowed it down to rather than just half of them. If you still get a CTD you either fecked something up, or there could possibly be two or more separate records causing the crash and you need to identify all of them... good luck with that, it's a little more tricky than locating just a single record :-[
Once you have identified the crashing record it might also be worthwhile making a permanent note of what it was - just in case there might be others, and maybe there's a pattern to it. In my case I narrowed it down to a changeform on 00086117, which bunged into xEdit revealed it to be a LvlAnimalForestPredator (so, perhaps SkyTEST which I recently uninstalled after noting its moderate script usage on cell change left behind a little surprise for me? Edit: This is just a hypothesis, and by no means am I confirming that this mod is bad - if it was related it was probably my bad for not following their uninstall instructions properly the first time. Other thread is here: https://www.reddit.com/r/skyrimvr/comments/c6o0vj/hang_on_fast_travel_cell_change_find_out_which/).
If anyone is interested, my binary search notes and the contents of the crashing record are here:
[link] [comments]
