My BSODs seemed to start when there was a failed Windows 1909 update install. They seem to happen when the PC is cold booted. Attached are the winver and logfile from the V2 log tool.
ABSOLUTION-(2020-08-17_16-19-47).zip
No dumps in the collected zip file unfortunately. Also nothing in Event Viewer logs that gives a hint to what is going on.
Please make sure your PC is configured for small dump files:
How to Configure Windows 10 to Create Dump Files on BSOD
Please download this batch file to your Desktop then run it. You can delete it when your done with the BSOD problem.
Tuneup.bat - Run SFC and DISM commands and use WMIC to change some settings
Information is at the link on how to run it and how to collect the batch output data to post here.
I changed to the small memory dump and ran the .bat file.
###########################################################
# The following commands will be run in sequence. #
# The first 4 will take quite a while to run, be patient. #
###########################################################
sfc /scannow
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /restorehealth
sfc /scannow
chkdsk /scan
wmic recoveros get autoreboot
wmic recoveros set autoreboot = false
wmic recoveros get autoreboot
wmic recoveros get DebugInfoType
wmic recoveros set DebugInfoType = 7
wmic recoveros get DebugInfoType
C:\Windows\system32>echo Logfile is
Logfile is
C:\Windows\system32>echo. 1>&2
C:\Windows\system32>sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection did not find any integrity violations.
C:\Windows\system32>dism /online /cleanup-image /scanhealth
Deployment Image Servicing and Management tool
Version: 10.0.17134.1550
Image Version: 10.0.17134.1667
[==========================100.0%==========================] No component store corruption detected.
The operation completed successfully.
C:\Windows\system32>dism /online /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.17134.1550
Image Version: 10.0.17134.1667
[==========================100.0%==========================] The restore operation completed successfully.
The operation completed successfully.
C:\Windows\system32>sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection did not find any integrity violations.
C:\Windows\system32>chkdsk /scan
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
699392 file records processed.
File verification completed.
24169 large file records processed.
0 bad file records processed.
Stage 2: Examining file name linkage ...
791 reparse records processed.
882810 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered to lost and found.
791 reparse records processed.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
91710 data files processed.
CHKDSK is verifying Usn Journal...
39951024 USN bytes processed.
Usn Journal verification completed.
Windows has scanned the file system and found no problems.
No further action is required.
499526916 KB total disk space.
239270968 KB in 392336 files.
275644 KB in 91711 indexes.
0 KB in bad sectors.
830192 KB in use by the system.
65536 KB occupied by the log file.
259150112 KB available on disk.
4096 bytes in each allocation unit.
124881729 total allocation units on disk.
64787528 allocation units available on disk.
C:\Windows\system32>wmic recoveros get autoreboot
AutoReboot
TRUE
C:\Windows\system32>wmic recoveros set autoreboot = false
Updating property(s) of '\\ABSOLUTION\ROOT\CIMV2:Win32_OSRecoveryConfiguration.Name="Microsoft Windows 10 Education|C:\\Windows|\\Device\\Harddisk2\\Partition4"'
Property(s) update successful.
C:\Windows\system32>wmic recoveros get autoreboot
AutoReboot
FALSE
C:\Windows\system32>wmic recoveros get DebugInfoType
DebugInfoType
3
C:\Windows\system32>wmic recoveros set DebugInfoType = 7
Updating property(s) of '\\ABSOLUTION\ROOT\CIMV2:Win32_OSRecoveryConfiguration.Name="Microsoft Windows 10 Education|C:\\Windows|\\Device\\Harddisk2\\Partition4"'
Property(s) update successful.
C:\Windows\system32>wmic recoveros get DebugInfoType
DebugInfoType
7
C:\Windows\system32>bcdedit -- /enum {badmemory}
Invalid command line switch: /-
Run "bcdedit /?" for command line assistance.
The parameter is incorrect.
C:\Windows\system32>bcdedit /enum {badmemory}
RAM Defects
-----------
identifier {badmemory}
#########################################################################
# Now copy the results in this window to the Clipboard so you can paste #
# it into a post in your tenforums BSOD thread. #
# See here for directions: #
https://www.tenforums.com/bsod-crashes-debugging/162488-batch-files-use-bsod-debugging.html
Press any key to continue . . .
Thanks. Looks like SFC and DISM did not fix anything which is too bad. I was hoping there was some corruption from the failed upgrade and they would fix it.
Automatic restarts are now turned off (wmic recoveros set autoreboot = false) so if you get another BSOD the screen will stay there until you manually reboot. The reason for this is to allow you time to record anything useful on the screen, like taking a picture with a cell phone then uploading it here (if it has useful info).
Also it changed to have Windows Create an Automatic Memory Dump on BSOD: wmic recoveros set DebugInfoType = 7
Last edited by Ztruker; 17 Aug 2020 at 22:24.
This is the data from the cold boot crash that just happened:
ABSOLUTION-(2020-08-18_13-42-38).zip
Got a couple dumps this time. Both are the same.
That belongs to EneTechIo, what ever that is. Everything I find says virus.Code:PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffffda0bd7798000, memory referenced. Arg2: 0000000000000000, value 0 = read operation, 1 = write operation. Arg3: fffff801df81e4f6, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000000, (reserved) Debugging Details: ------------------ *** WARNING: Unable to verify timestamp for ene.sys
Also noticed your RAM is not on the motherboard QVL list.
If you recognize the driver, see if you can find an update for it.
I believe the ene.sys is related to the RGB control software of the motherboard and RAM. My motherboard is an ASRock Z390 Phantom Gaming X. My guess is this might be related to an issue with the RGB control software. The BSOD does always seem to happen during the boot phase of ASRock Polychrome. I will see what I can find in regards to it.
As for the memory I am surprised it is not on the QVL. It is one of the best 3200 CL14 Sasmung B-die based kits out there. There are other G.Skill kits that match the specs of it on the QVL. I am curious as to why mine is missing.
- - - Updated - - -
I uninstalled the RGB software just to test it and shutdown the computer. I let it sit for about 5 minutes and booted it up. There was no BSOD this time. I will run it for a couple of more days without the control software and in the meantime see what I can find from the manufacturer support forums.
Would be nice if you can tie it to the RGB software.
I don't think RAM is a problem, just noticed it was not on the QVL list.
I don't have an answer but it's interesting that you mention ram chips with an ASRock RGB board. I'm also having weird issues that kind of look like memory issues, with an ASRock RGB board and G.Skill RGB ram. I was googling about it the other night, and I found forum posts from 2017 about ASRock Polychrome and other software interfacing with the SMBus at the same time, causing the SPD chips in G.Skill RAM sticks to corrupt.
I don't know if that still applies in 2020 though, or how we would verify that that is or isn't the case. Some folks in the aforementioned forum posts used Thaiphoon Burner, but there are rumors that that project has been tied to malware, so I haven't tried it and wouldn't really advise it. The idea that our RGB chips are screwing up the rest of our systems seems like a long shot anyway though.
The issue you are describing is when two different softwares are trying to control the LEDs on the RAM. They don't work nicely with each other and can corrupt the SPD. This would occur say if you installed the RAM LED control software and the motherboard LED control software that also controls the RAM LEDs. The issue I was having is different because I have only installed the motherboard software.
- - - Updated - - -
It honestly looks like it was the RGB software. During my investigation I came across this forum post:
RGB Utility issues and workaround - ASRock Forums - Page 1
So, I did a clean uninstall using REVO Uninstaller and then I was able to install the windows update using the ISO method. Then I downloaded the software and performed a firmware update as described in that post. After the firmware upgrade and reinstall of the software, I have not had a BSOD. My theory is that the RGB software was having a conflict with the firmware and since it was related to the motherboard, it caused the BSOD.
Quote
