This is essential to ensure that MSFS hasn’t balled-up anything in the operating system, especially after a CTD or crash to BIOS.
If errors are found, especially if some errors could not be repaired, you should run these two programs over again until everything’s taken care of.
==================== Begin Article ====================
Awhile back I ran into a (seemingly) odd problem when installing MSFS-2024 using the default settings on a system that already had MSFS-2020 installed: The 2024 install trashed the existing 2020 install to the point that I needed to remove, run fixups, and reinstall both flight simulators.
After I ran the fixups I documented here:
. . . completely removed and reinstalled both X-Box and the Microsoft Store apps, (documented above), I was able to completely reinstall both sims - 2020 then 2024, without an installation collision.
One of the things I did was to run both DISM and SFC within an elevated command prompt.
When I ran that, (after I did the first attempt at cleaning things up, which failed miserably), it took a long time to finish.
After a total shut-down and reboot, attempts to clean things up worked wonderfully.
Again, after a total shut-down and reboot, (and reinstalling the fundamental gaming/MS Store apps and yet ANOTHER reboot), both installations did what they were supposed to and the MSFS-2024 installation was much less fussy and grumpy. (It only crashed to the BIOS once.)
Today, after futzing around with the system, posting to various forums, watching Chris Boden crawl into the bowels of a gigantic hydro-electric turbine on YouTube, a few restarts, some sleep, (etc.), I decided to re-run DISM and SFC again, “just for the grins-and-giggles” of it, since I’ve already done that a few times over the last few days - and after the first run, everything was squeaky-clean. . .
And today it found issues again.
(It ran MUCH more quickly, but it DID find issues.)
I am not sure exactly what happened, but I ran both MSFS-2020 and MSFS-2024 yesterday after doing an Acronis True Image off-line backup - and had things happen in 2024 - so this might be worth investigating as a way to clean up the O/S after MSFS, especially FS-2024, crashes or does something unusual.
In summary, I am going to recommend as a possible solution/troubleshooting aid that you folks consider running DISM and SFC periodically, especially after a serious malfunction or crash.
SFC made its first appearance in Windows 7 and was able to help resolve a limited subset of Windows O/S inconsistencies that had previously required a reinstall. DISM made its first appearance in Windows 8, originally as a helper program for SFC to help manage the Windows repair file store. Since then it has become the primary management tool for the Windows Deployment Image. SFC has also evolved to become a more sophisticated automated repair tool for borked Windows installations.
Neither one can totally repair a Windows installation that is seriously borked, but in Windows 10+ they do a pretty good job of helping to keep an honest operating system honest.
Note that if you’re encountering a crash that reboots the machine, you’re likely encountering serious hardware problems (bad or overloaded power supply, improperly seated components, bad RAM, unstable overclocks, etc).
In this case all bets are off until you resolve the hardware problems. These sorts of things can be the cause of many “weird” bugs and crashes that not everyone encounters (as opposed to bad logic in the program code that is dutifully followed by the CPU and GPU).
It’s also important to remember that just because your machine works with other games doesn’t mean it’s problem-free: MSFS is heavy on both CPU and GPU unlike most games which are heavy only on the GPU, and it stresses your system a lot more. You may encounter failures (which may be big visible instant crashes, or may be small invisible corruption of data or program code in RAM which causes failures or misbehaviors down the line) even if other programs appear to work reliably.
MSFS-2024 is the only thing that has ever - and I mean EVER ever - provoked a crash-to-BIOS. I don’t even remember the last CTD I’ve seen anywhere.
The general run-of-the-mill kind of stuff, (like a buddy flight in MSFS-2020 with several other aircraft with both audio and video sharing), doesn’t even cause my system to burp loudly in MSFS-2020.
With the exception of (I forget the exact term Gigabyte uses for video memory snooping), there really isn’t anything set strangely - and that’s not even “strange” as that particular BIOS setting is required for the AMD video drivers, (and the rest of the system) to see the entire 16 gigs of VRAM. on my video card.
Based on my, (and my son’s), analysis of my system’s config, a ±500W PSU should be generously overkill, (including a considerable amount of reserve) and, (me being the OCD such-and-so that I am), I dropped a 750W PSU in it just so MSFS and the graphic card would have plenty of headroom.
And! I didn’t buy some [garble-garble, cough, sneeze] branded PSU whose name The Devil Himself couldn’t pronounce - I got one of “The Good Ones” (I forget which), awhile ago here in Russia (Pre-Sanctions), that cost like an entire PC back in the U.S.
Then I added 16 gigs of, (supposedly), “matched” G-Skill CAS-16, 3200 DDR-4 RAM, and the biggest and baddest of the bad beasties that would fit an AM-4 CPU socket the last time I was in the US - and what I did to my credit-cards while at the Cambridge Micro Center shouldn’t happen to a DOG!
I’ll check, but (for me) I get a crash-to-BIOS every time I’ve first-booted a fresh MSFS-2024 install. Nothing else does it, not even MS2024, except on the first time I boot a “virgin” installation of '24.
P.S.
Aside from things like Prime-95, what would YOU recommend as a totally inhumane, Geneva-Convention bashing, Ultimate Crimes Against Humanity torture-test for a PC if you really want to separate the sheep from the goats? (i.e. Something that makes MSFS set to “Whacked-Out” look like a game of Solitaire or Minesweeper on Win-95.)
Interesting side-note:
When MSFS-2020 first came out, several of the more trustworthy PC review pundits suggested that, instead of testing the PC to see if it could run 'FS-2020, they suggested actually using MSFS-2020 as the torture test par excellence, noting that machines they had that had successfully weathered the worst they could throw at them, (other than a MIL-SPEC thermal gradient test while on a 10G shaker-table), crumbled to their knees when they saw the box that MSFS-2020 was shipped in!
P.P.S.
Assuming I run something like Prime-95, set to it’s absolute worst “you ARE kidding me, right?” torture settings, (and if we assume that my system DOES end up a blubbering ruin ready to confess to anything I want including the Reichstag Fire, The Fall Of Rome, and Original Sin), how do I know what caused the system to crash? It’s not like I get a telegram saying “Mr. Cosby, we are crashing at this time” when it happens, 'eh?
Is fs24 really worth all that futzing around? When you could have been flying, visiting friends, walking the dog, taking a nap after eating xmas turkey, etc?
there is NOTHING that a Windows-based program can do that can crash the machine to the BIOS if there is not one of the following:
a major bug in the operating system or drivers that access hardware causing it to access hardware incorrectly
a hardware problem that causes the system not to work properly at the electronic level
The operating system simply doesn’t offer any way for a program to do that by simply misbehaving; the program doesn’t have access to any low-level hardware capabilities of that sort.
However when you’re stressing the system, it’s more likely to encounter problems. And the stresses, and the results of the stresses, will depend on what you’re doing to it.
If you’re crashing to BIOS in MSFS 2024, then MSFS 2024 IS your torture test. You have it.
Now you have to find a configuration that doesn’t fail.
Longer answer:
Yes, MSFS-2024 shouldn’t require a Ph.D. in Voodo-Science and threats from a Mafia Hit-Man to work correctly.
However, it is what it is and, (IMHO), we can choose to be part of the problem or part of the solution. Since one of my talents is software testing, here’s an opportunity to make a difference by (trying to) generate repeatable results that, hopefully, will allow folks to fix problems.
I absolutely agree.
AFAIK, (theoretically), it should be inordinately difficult[1] to crash a system to the point where either the BIOS/Motherboard locks up and needs a hard, (at the wall plug), power-cycle to recover, or a crash-to-BIOS.
It is the incredibly unusual nature of this failure that makes it interesting - especially since I appear to be the only one experiencing this issue - which leads me to believe that:
There is something particular and unique about my system that needs to be investigated and documented.
There is actually something seriously wrong with my system/hardware/software/etc. that needs to be explored, documented, and (hopefully), resolved.
IMHO nothing’s impossible, but the likelihood of this happening in the current environment should be incredibly small and even a catastrophic failure should result - at worst - in a BSOD. That’s what makes this so interesting.
