second bugcheck, system up 10 hours, steam running
It was waiting for some signal, when it was called it was found to be corrupt and a bugcheck was called.
windows puts a known block of data before and after the apps data. if it finds any portion of the block is modified it shuts down the system. The assumption is malware or a bad program is running. again you do not know what driver modified the block.
All drivers have unlimited access to kernel memory. Only running verifier and puting the blocks in special pool can make windows bugcheck at the time of corruption.
otherwise you just have to guess until you get the correct answer.
ie steam uses network functions, maybe update the network driver
media tek mt7612u.sys (marked as invalid by the debugger for some reason)
but you also have a 2018 vpn that effects the network driver
also have
RtkBtfilter.sys from 2018 (old realtek bluetooth driver)
note:
MediaTek | MT7612U | Smart Wi-Fi Dongle Solution
might be the driver directly from mediatek. most often you want to get it from the motherboard vendor. Not sure where you got the current installed version. but
sometimes these chips need all the drivers related to it to be updated at the same time. Ie maybe windows updated the wifi but not the bluetooth drivers.
note: the media tek chip provides the wifi and the bluetooth. I would expect both of the drivers to be installed at the same time and basically have the same build number.
in your case looks like the wifi portion was updated but the bluetooth portion is from 2018. I would try to install the current versions again.
you also have a wired network adapter
e1r68x64.sys Mon Jun 15 03:26:56 2020
and
nordlwf.sys Tue Jul 7 23:53:44 2020
vpn driver that effects network functions
any of these drivers could be related to corruption of a steam network function.
generally, you would remove what you can, update the rest and retest.
or run verifier and crash the system on data corruption.
----------
looked at the first bugcheck
file =022623-19828-01 - Copy.dmp
system was running 18 hours.
basically looks like a critical checked process accessed some bogus timer data and faulted
looks like something overwrote the timer data.
it would be assumed that this process is just a victim of data corruption.
rather than the cause.
you might google how to delete a pagefile.sys on system restart and make the registry settings.
maybe something like this:
How to delete the Windows 10 paging file on every shutdown | TechRepublic
to look at the timer data you would have to provide a kernel dump, even then bugcheck does not happen at the time of the corruption but later when the data in the corruption is used.
kernel dump can be useful since I can look at who the owner of the timer is for the timer that is stored next to the timer that failed. (most lilkly the timer next to the failed timer caused the problem)
just because a driver can corrupt various areas of a memory, then the memory gets saved to virtual memory pagefile.sys with all the corruptions saved. even if you delete the driver later the corruptions remain saved in the virtual memory until the page file is deleted.
making the change will help from getting bugchecks due to old data corruptions.
(but it takes longer to know if you have fixed the problem since you will have fewer bugchecks)
you can use verifier.exe to force the system to bugcheck at the time of the corruption rather than when the system uses the bad data later and bugchecks.
this is the best method but people sometimes have issues in knowing how to turn verifier off, or figuring out how to get into safe mode to run the
verifier.exe /reset command.
IE the can not boot and do not know how to fix the problem and end up reinstalling windows and refuse to use verifier again.