Two BSoDs in two weeks - hal.dll, ntoskrnl.exe

So, I ran driver verifier, but after every logging in PC just rebooted itself (without BSoD). So I restored from restore point and after successfully finish there was another BSOD - System Thread Exception Not Handled. Sadly there is no minidump again, despite proper settings. After reboot it works normally - except Chrome, which crashing all the time. MS Edge works.
After reinstall Chrome works again.

Please post a new set of beta log files, it's possible we can see what was happening during the boot from the logs.

I tried to run driver verifier again, this time no reboots.
Beta log in attachment.

1) Open administrative command prompt and type or copy and paste:
2) sfc /scannow
3) dism /online /cleanup-image /restorehealth
4) chkdsk /scan
5) wmic recoveros set autoreboot = false
6) When these have completed > right click on the top bar or title bar of the administrative command prompt box > left click on edit then select all > right click on the top bar again > left click on edit then copy > paste into the thread

Should I do it when driver verifier is running?

asm0d said:

Should I do it when driver verifier is running?

I would delay @zbook request for the scanning for 2 days until you have used the PC with Driver Verifier and waited for any new BSODs. If you do get BSOD events please post a new set of log files so we can examine them.

Windows driver verifier has customized settings for the drivers and for the tests.

In the link that @philc43 posted it displayed customized testing for many drivers with three specific tests.

Code:

    I/O Verification
    Force pending I/O requests
    IRP logging

The logs displayed that other tests were selected and that these three tests were not in use.

Code:

Standard Flags:

    [X] 0x00000001 Special pool.
    [X] 0x00000002 Force IRQL checking.
    [X] 0x00000008 Pool tracking.
    [ ] 0x00000010 I/O verification.
    [X] 0x00000020 Deadlock detection.
    [ ] 0x00000080 DMA checking.
    [X] 0x00000100 Security checks.
    [X] 0x00000800 Miscellaneous checks.
    [X] 0x00020000 DDI compliance checking.

  Additional Flags:

    [ ] 0x00000004 Randomized low resources simulation.
    [ ] 0x00000200 Force pending I/O requests.
    [ ] 0x00000400 IRP logging.
    [ ] 0x00002000 Invariant MDL checking for stack.
    [ ] 0x00004000 Invariant MDL checking for driver.
    [X] 0x00008000 Power framework delay fuzzing.
    [ ] 0x00010000 Port/miniport interface checking.
    [ ] 0x00040000 Systematic low resources simulation.
    [ ] 0x00080000 DDI compliance checking (additional).
    [ ] 0x00200000 NDIS/WIFI verification.
    [ ] 0x00800000 Kernel synchronization delay fuzzing.
    [ ] 0x01000000 VM switch verification.
    [ ] 0x02000000 Code integrity checks.

At times approximately 19 simultaneous tests are used.

Driver Verifier-- tracking down a mis-behaving driver. - Microsoft Community

Philc43 had suggested the testing and he may have a preferred customized testing method.

My bad, I was running driver verifier with settings from another forum, where I was also asked to run it (I made a thread also somewhere else and these are settings from there).

So, RAM is faulty. One stick is fine, no errors, but other has hundreds of errors in first test. Sticks were tested in same DIMM slot, so mobo is fine too. I'm gonna RMA my RAM. Shame that I must return both sticks, because they're from same set. Results from memtest96 are in attachment.

Nice progress.

When the RAM were tested together they only failed the hammer test.
When the RAM were tested one at a time neither failed the hammer test.
The RAM module that failed displayed during the 40 minute test:

Code:

Test 1 [Address test, own address, 1 CPU]
0/1 (0%)
532

Use the RAM module that has passed testing until the RAM to evaluate computer stability/instability.

Follow up on the steps in post #24.

Were there no BSOD with Windows driver verifier?
If there were none then make sure the tool has been turned off.