Multiple BSOD Crashes per day

Hello, for a few months now I've been having BSOD crashes which started as once or twice every few weeks but now is happening 5-10 times in a working day. The crashes happen regardless of how much activity is going on i.e. it could be heavy usage with multiple apps or just having powered the laptop on and it sitting on the desktop page with no apps being actively run (excluding background processes).

Here are the specific BSOD error codes I have saved to date (in no particular order):

• KERNEL_DATA_INPAGE_ERROR
• PAGE_FAULT_IN_NONPAGED_AREA
• MEMORY_MANAGEMENT
• KERNEL_SECURITY_CHECK_FAILURE
• CRITICAL_PROCESS_DIED
• FAULTY_HARDWARE_CORRUPTED_PAGE
• PFN_LIST_CORRUPT

Some things I've noticed:

• Multiple BSOD crashes seem to happen in short timeframes and then nothing again until the next time
• More frequent when running Chrome or MS applications (Teams, Mail), but maybe because I frequently use these in general
• Tabs in Chrome or Firefox spontaneously crash, sometimes shortly before a BSOD crash

V2 Log Collector report: LAPTOP-IP833CFN-(2024-02-22_16-47-55).zip - Google Drive

(Windows 10 Home)

Hello Axe, thanks for your help. I've attached the screenshot of the report below.



- - - Updated - - -

EDIT - just had a BSOD with a new code:

• ATTEMPTED_WRITE_TO_READONLY_MEMORY

My suspicion would be that the computer has "bad RAM" since the beginning, w/o discarding other options (like a bad PCI card, a bad Motherboard o bad physical mounting; with bad I mean "in the middle" except the mounting, not the kind of part that -kidding a bit- can crash a computer while just approaching w/o connecting) but RAM is an usual culprit (now I recall that Windows 95 did this to a badly mounted desktop that could run MS-DOS w/o problems, it turned out the motherboard was badly attached to the case, with weldings doing contact, likely not used ones while running DOS for the bitwidth difference between DOS and W95).

I suggest running the following in this order from an elevated prompt (there's debate about the order or if only one suffices, but this if the most orthodox way afaik):

DISM /Online /Cleanup-Image /RestoreHealth
SFC /scannow

The 1st one took 37 minutes in a W10 destop here, the 2nd 5 minutes (this rig has "small instabilities" in 2 or 3 programs and I suspect about RAM, although you'd call it "stable"). I believe they serve different aspects and a successful DISM [...] is like the foundations and SFC [...] like the walls and roof, with the hardware acting as the parcel of land.

-------------------------------

PS: Attention: JLArranz

Before posting a BSOD thread, please read the instructions here: Blue Screen of Death (BSOD) Posting Instructions

If you need to add new information, please make a new post in your initial BSOD thread. Please do not make an extra new thread.

Please do not post anything other than Windows 10 Blue Screen Of Death problems in this section.

--------------------------------

I think that my information and advice is totally relevant and adequate, including the part in which I mention similar problems I had with other (very ancient nowadays and not used by me since maybe 23-24 years ago THAT TURNED OUT TO BE A VISIBLE HW PROBLEM, physically visible I mean.

This is not common, for instance a video card died here like 4 years ago but its problem wasn't physically visible, as most hw problems. It did not die suddenly and possibly caused BSOD's among other problems (I recall that there was being problems and what the cause was, not the details and long hex codes that with other possible cause would be extremely important, but they weren't at all in that concrete case).

A BSOD is "sacred" if it's concretely related to a localized software problem, but accumulations of assorted BSOD's use to mean different things. Btw I was able to fix a coding problem this way: I didn't have access to the source code and I didn't even consideror imagine disassembling object code etc, instead I took a screwdriver, opened a biggish case for the left, replaced two PC-100 modules (in theory adequate for a Coppermine 6.5x100, but lacking quality) with two PC-133 ones (quite more expensive and with all guarantees about "quality"). This operation not only debugged and recompiled the program successfully -kidding-, but it also allowed me to o/c the Coppermine to 6.5x133. The program was a car racing game that, at random moments, started to do the "car crash routine" with random intervals in the fractions of minute, w/o the gamer actually crashing. This behaviour pervived exiting to Windows and running the game again, only restarting Windows fixed it until the next random appearance of the bug, although restarting Windows wasn't necessary at all for running other programs, other games included. It was a clear case of "debugging screwdriver" :) . I told it to a hw vendor as if I had discovered a new continent, but he more or less said "it's very common, clients came with things like that every day".

I use size=1 for secondary things, I got surprised by the kind of warning I've quoted. 99,9999% (subjective impression) of the times anybody sees a BSOD is for gross configuration errors, malfunctioning hardware, random (isolated) hardware errors and from time to time a bug w/o debugging possible by the user (the usual fix in this case is an older or newer version). As for the OP's problem, I suspect it's accumulating dism and sfc detectable errors at a growing pace (the mentioned W95 system was doing that although much faster, I had to reinstall the OS every week, and finally I took it to a hw shop and told them to install the OS -a common service in that age- and they found the root problem). My suggestion was more for diagnosing than for fixing, although Swisster might also get a time extension that wouldn't hurt.

The hard disk seems covered now. At first it could be a dying hard disk but I've only seen it once, when I dropped one accidentally (from the spinning ones). Accidents apart, Idk if it's processors or hard disks the parts that have the most durability, resilience, reliability,... Another subjective impression: the failure rate of hard disks has increased a lot from some years ago. But it seems fine in this case.

Hey guys, thanks for the help once again.
@axe0 - Yes I did recently run chkdsk recently and it returned nothing untoward.

Apologies for potentially a stupid question, is it possible to remove/reseat the RAM if that is a likely culprit? Otherwise, what would be next steps?

Swisster said:

Hey guys, thanks for the help once again.
@axe0 - Yes I did recently run chkdsk recently and it returned nothing untoward.

Apologies for potentially a stupid question, is it possible to remove/reseat the RAM if that is a likely culprit? Otherwise, what would be next steps?

Imo you should run first the dism and sfc commands above with a different and less demanding memory config, because the system might produce instability for the bad disk contents regardless of the stability of the new memory config. Use half the modules for instance while doing this.

You'll normally have 2 or 4 RAM slots and 1, 2 or 4 RAM modules (I've also heard name the latter as "RAM cards", even "memory cards" although this latter name can create confusion, with "modules" you never fail). You always can reseat the modules although it isn't a very useful action unless the the computer does beeps when turned on and it doesn't boot.

Trying the modules one by one might detect a defective one relatively quickly, because it's the lowest performing and most stable configuration.

If you have one module you can move it to other slots, but you cannot boot w/o RAM.

If you have 2 modules and 4 slots you'll normally place them in equally colored slots, although they should also work in slots of different colors at the possible price of a performance penalty and maybe better stability, and you can also use the other pair of slots (same performance in general). With two slots the best is trying the modules one by one.

With 4 modules already tried one by one successfully, it would be best trying 2, 3 and 4 in this order. I include "4" because you could have 2 pairs of different models, and you could try them "the other way round": if the blue modules were in the white slots and the red modules in the gray slots, the other way round.

Theory (most of this can be ignored if all the modules are equal): there are other motherboard/chipset/processor configurations, I have only considered "dual channel". I've never dealt with triple or quad channels, and I'm not sure how they work in "funny" configs like 2 modules in a triple channel or 3 in a quad channel, although I know a quad channel works well with 2 modules.

You should use equal modules in the same coloured slots, at the very least they should all have the same size and number of ranges, otherwise systems use to beep and not boot (in more ancient times there were only 1 range and 2 range modules, what always was one sided and two sided respectively, I know that technical progress is starting to allow more than one range per side, but Idk how much spread is this).

If they have the same number of ranges/sides but still are different, you should use the higher latency ones in the lower slot numbers, to allow all use looser latencies instead of tighter ones (using tighter latencies can cause instability or beeps/not boot).

If you have two groups of coulored slots for two different sets of modules, it's best to use the looser latencies in the lower numbers for the same reason.

Slots of the same colors don't correspond to channels, but to slots used at the same time in different channels. If two or more modules are to be used "at the same time", the best is that they're equal (equal or not they'll all get the same latencies, and if they're different the mobo might choose the ones read from the lower numbered slots) and otherwise not too different, hence, the rules above.

Example: all modules have 4 GB and are equal, there're 4 slots with 2 pairs of different colors. The white ones have numbers 1 and 2, the gray ones 3 and four. In this case, the first 8 GB of RAM will be the modules in slots 1 and 2, with some kind of addresses interleaving between them that might be regulated in the mobo advanced options. The second 8 GB of RAM will be the modules in slots 3 and 4, idem about interleaving. Hence, if you only have two modules and want to try them in the same channel, it would be best to place them in slots 1 and 3. 2nd best option for this config would be in slots 2 and 4, but 1-4 and 2-3 might work too.

Don't try all possible combinations. For instance if a given module works well in slot 1, you could try it in the other slots for testing the slots. If all proofs go well, you already know that all slots work and that that module works. Try the other modules once each in any slot. If all goes well, all modules work and all slots work, but it doesn't imply that all combinations work. If you have 4 modules, try with two as next step, either same of different channels (single and dual channel respectively), the other way if it doesn't work,...