[SOLVED] BSOD: "KMODE_EXCEPTION_NOT_HANDLED" ?

[Androshi]

So after a short while when I assumed things were fixed my computer crashed with the following stop code while I was using it: "KMODE_EXCEPTION_NOT_HANDLED"

I ran a Window's memory diagnostic which came back clean so it appears to not be a memory issue, so I'm still pretty stumped what the problem could be. Here's the latest memory dump https://www.mediafire.com/file/kvul5t7zypcbb8x/072322-9921-01.dmp/file help is appreciated, thanks.

My computer specs:
OS: Windows 10 Home
Motherboard: AORUS master Z590 Version F8a
CPU: Intel I9-10900KF 3.70Ghz
GPU: Nvidia MSI 1660 Ti 6gb
RAM: Team T-Force Delta RGB 32GB (2x16GB) DDR4 3600
PSU: Seasonic Prime Fanless 700 W 80+ Titanium
SSD: Samsung Evo 870 1TB

 

[johnbl]

bugcheck was cause by an access violation in some expired timer

generally a driver messes up its own timer but it can also mess up a timer for another object you just can not tell with a minidump.

general fix would be to update drivers:
here are some suspect old driver:
dtlitescsibus.sys (nov12 2018)
dtliteusbbus.sys (jul 2021)
rtkbtfilter.sys (oct 2018)
ace-base.sys
mhyprotect.sys

generally, for this problem you would first try to update the drivers or remove drivers. if you still get the bugcheck you would want to change the memory dump type to kernel so the timer table could be looked at to see who owned the timer. (most times the owner corrupts the timer). otherwise you will have to run verifier on the drivers and try to catch the corruption as it happens. verifier will call a bugcheck and name the driver.
Note: if you run verifier you need to make sure you know how to boot into safe mode so you can turn it off if it bugchecks during boot.
you might also start by using a verifier option to run verifier only on one boot up and automatically turn off. I mention this because some people are unable to get into safe mode and just have to reinstall windows after getting a verifier bugcheck during boot.

 

[Androshi]

you might also start by using a verifier option to run verifier only on one boot up and automatically turn o

bugcheck was cause by an access violation in some expired timer

generally a driver messes up its own timer but it can also mess up a timer for another object you just can not tell with a minidump.

general fix would be to update drivers:
here are some suspect old driver:
dtlitescsibus.sys (nov12 2018)
dtliteusbbus.sys (jul 2021)
rtkbtfilter.sys (oct 2018)
ace-base.sys
mhyprotect.sys

generally, for this problem you would first try to update the drivers or remove drivers. if you still get the bugcheck you would want to change the memory dump type to kernel so the timer table could be looked at to see who owned the timer. (most times the owner corrupts the timer). otherwise you will have to run verifier on the drivers and try to catch the corruption as it happens. verifier will call a bugcheck and name the driver.
Note: if you run verifier you need to make sure you know how to boot into safe mode so you can turn it off if it bugchecks during boot.
you might also start by using a verifier option to run verifier only on one boot up and automatically turn off. I mention this because some people are unable to get into safe mode and just have to reinstall windows after getting a verifier bugcheck during boot.

Hi John,
I've already ran a few things when I posted my problem through microsoft community and someone did mention about a verifier check option, but I will hold off on that for now just to see if the other solution I was provided fixed the problem at hand. If not I will attempt the verifier check as mentioned by you and one other person from the microsoft community. I'll update as needed thanks for the response.

 

[Androshi]

bugcheck was cause by an access violation in some expired timer

generally a driver messes up its own timer but it can also mess up a timer for another object you just can not tell with a minidump.

general fix would be to update drivers:
here are some suspect old driver:
dtlitescsibus.sys (nov12 2018)
dtliteusbbus.sys (jul 2021)
rtkbtfilter.sys (oct 2018)
ace-base.sys
mhyprotect.sys

generally, for this problem you would first try to update the drivers or remove drivers. if you still get the bugcheck you would want to change the memory dump type to kernel so the timer table could be looked at to see who owned the timer. (most times the owner corrupts the timer). otherwise you will have to run verifier on the drivers and try to catch the corruption as it happens. verifier will call a bugcheck and name the driver.
Note: if you run verifier you need to make sure you know how to boot into safe mode so you can turn it off if it bugchecks during boot.
you might also start by using a verifier option to run verifier only on one boot up and automatically turn off. I mention this because some people are unable to get into safe mode and just have to reinstall windows after getting a verifier bugcheck during boot.

Welp given that the solution I mentioned previously didn't work I enabled the verifier so now I'm just waiting for if anything to happen and if nothing happens within 48 hrs I'll be disabling it and will keep you posted if anything occurs. Thanks for the help by the way. Also you mentioned "run verifier only on one boot up and automatically turn off " in which case how do I do that? Do you have a step by step guide for that possibly? Thanks.

 

[Androshi]

bugcheck was cause by an access violation in some expired timer

generally a driver messes up its own timer but it can also mess up a timer for another object you just can not tell with a minidump.

general fix would be to update drivers:
here are some suspect old driver:
dtlitescsibus.sys (nov12 2018)
dtliteusbbus.sys (jul 2021)
rtkbtfilter.sys (oct 2018)
ace-base.sys
mhyprotect.sys

generally, for this problem you would first try to update the drivers or remove drivers. if you still get the bugcheck you would want to change the memory dump type to kernel so the timer table could be looked at to see who owned the timer. (most times the owner corrupts the timer). otherwise you will have to run verifier on the drivers and try to catch the corruption as it happens. verifier will call a bugcheck and name the driver.
Note: if you run verifier you need to make sure you know how to boot into safe mode so you can turn it off if it bugchecks during boot.
you might also start by using a verifier option to run verifier only on one boot up and automatically turn off. I mention this because some people are unable to get into safe mode and just have to reinstall windows after getting a verifier bugcheck during boot.

Well after turning off verifier and then a few hours later my computer crashed into a BSOD this time with stop code: IRQL_NOT_LESS_OR_EQUAL so that's sad. Here's my file dump after my computer crashed. https://drive.google.com/file/d/1RMsg79WbZ5bhhlDt34ClPMVi1GFtrjoo/view?usp=sharing

As for the drivers you listed:
dtlitescsibus.sys (nov12 2018) - Deleted
dtliteusbbus.sys (jul 2021) - Deleted
rtkbtfilter.sys (oct 2018) - I don't know which one that could be
ace-base.sys - from a game i think
mhyprotect.sys - that's from a game

The BSOD seems to always occur mainly when I have a browser open watching video/streaming and playing bluestacks 5 on two instances of emulator, which I'm not too sure if that will help or not. Also, my ram (32GB) was something I bought recently from newegg, although the tests ran clean for it I wonder if the new RAM I bought is the issue as my old RAM (16GB) never gave me any issues.

 

[johnbl]

Well after turning off verifier and then a few hours later my computer crashed into a BSOD this time with stop code: IRQL_NOT_LESS_OR_EQUAL so that's sad. Here's my file dump after my computer crashed. https://drive.google.com/file/d/1RMsg79WbZ5bhhlDt34ClPMVi1GFtrjoo/view?usp=sharing

As for the drivers you listed:
dtlitescsibus.sys (nov12 2018) - Deleted
dtliteusbbus.sys (jul 2021) - Deleted
rtkbtfilter.sys (oct 2018) - I don't know which one that could be
ace-base.sys - from a game i think
mhyprotect.sys - that's from a game

The BSOD seems to always occur mainly when I have a browser open watching video/streaming and playing bluestacks 5 on two instances of emulator, which I'm not too sure if that will help or not. Also, my ram (32GB) was something I bought recently from newegg, although the tests ran clean for it I wonder if the new RAM I bought is the issue as my old RAM (16GB) never gave me any issues.

last bugcheck the direct x graphics tried to use a bad memory address of 20 .
All I can suggest is to change the memory dump type to kernel and provide the file memory.dmp

 

[Androshi]

last bugcheck the direct x graphics tried to use a bad memory address of 20 .
All I can suggest is to change the memory dump type to kernel and provide the file memory.dmp

Ok I'll give it a shot

 

[Androshi]

last bugcheck the direct x graphics tried to use a bad memory address of 20 .
All I can suggest is to change the memory dump type to kernel and provide the file memory.dmp

Well after testing my theory out I have not seen anymore BSOD occur. My theory being that it had something to do with my RAM frequency that I set. The first time I had it set with XMP enabled at around 3300 MHz and the second time with XMP disabled but the frequency set itself to 3.4MHz which very could be the reason for my BSOD occurrences. As of now with it set at 2933 MHz the computer is finally stabilized. What I don't understand is why my old RAM of 16 GB OC was able to function fine to run at 3.2MHz but my new current RAM 32GB cannot be set above 2933 MHz without crashes happening.

 

[johnbl]

Well after testing my theory out I have not seen anymore BSOD occur. My theory being that it had something to do with my RAM frequency that I set. The first time I had it set with XMP enabled at around 3300 MHz and the second time with XMP disabled but the frequency set itself to 3.4MHz which very could be the reason for my BSOD occurrences. As of now with it set at 2933 MHz the computer is finally stabilized. What I don't understand is why my old RAM of 16 GB OC was able to function fine to run at 3.2MHz but my new current RAM 32GB cannot be set above 2933 MHz without crashes happening.

best to test the ram using memtest86
when you fully populate ram slots you often have to increase the timing values, sometimes you have to increase the command delay.
often motherboard vendors set a default memory command delay of 1T (one clock tick) but in the manual they put a little note that if you use all of the slots you have to set the command rate to 2T. (this is the part of the setup and hold time for the electronics to ensure the memory address is locked in before it is used)

this sometimes shows up as memory address 0 being used but for some functions, the functions add a offset to the memory address and you get memory address 20 showing up at the bad memory address.

 

[Androshi]

best to test the ram using memtest86
when you fully populate ram slots you often have to increase the timing values, sometimes you have to increase the command delay.
often motherboard vendors set a default memory command delay of 1T (one clock tick) but in the manual they put a little note that if you use all of the slots you have to set the command rate to 2T. (this is the part of the setup and hold time for the electronics to ensure the memory address is locked in before it is used)

this sometimes shows up as memory address 0 being used but for some functions, the functions add a offset to the memory address and you get memory address 20 showing up at the bad memory address.

Hm, I see well I'll see about doing that and reading a bit more into how RAM works. Thanks for everything~