BSOD on startup every day - Trying to identify specific causation

Question

Hi all,

For the past week or so I've been experiencing BSODs whenever I power on the computer first during the day; after we REACH the Windows splash screen, I have no further issues, even when restarting.

rom reviewing the Event Logs I can see one in there stating the following:

"The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly."
followed closely by:
"The driver \Driver\WudfRd failed to load for the device PCI\VEN_5853&DEV_1003\1&1a590e2c&0&03."

So far as far as causation goes, this is the only thing throwing flags, as I've successfully performed Windows Memory Diagnostics with no issues being found, system file checks with no corruption being found, and lastly checking in on the device manager and checking all tabs to ensure nothing in there is throwing errors. As far as I can tell, these issues began this week.

I know that this week I plugged in a new keyboard that is different to that of my old one, and in doing so I needed to download some more drivers for it, however I went from a Roccat Aimo 120 to a Roccat Aimo 100, to which the only real difference is the fact that the 100 doesn't have a hand wrest with the keyboard. Besides that, it doesn't appear any different specification wise, so I'm unclear on whether this is the cause. I also changed my power plan on the rig from Balanced to Performance, though I don't expect this to be the cause.

Originally I believed perhaps that drivers were the issue, however, now I'm not so sure.

To cut a long story short, I ran a bugcheck analysis using the Windows Debug tools which threw me the following:

12: kd> !analyze -v
***

    *
    Bugcheck Analysis *
    *

***

MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000041792, A corrupt PTE has been detected. Parameter 2 contains the address of
the PTE. Parameters 3/4 contain the low/high parts of the PTE.
Arg2: ffff83816716da08
Arg3: 0000800000000000
Arg4: 0000000000000000

Debugging Details:
------------------


KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 3249

Key : Analysis.DebugAnalysisManager
Value: Create

Key : Analysis.Elapsed.mSec
Value: 10478

Key : Analysis.Init.CPU.mSec
Value: 1249

Key : Analysis.Init.Elapsed.mSec
Value: 65592

Key : Analysis.Memory.CommitPeak.Mb
Value: 73

Key : MemoryManagement.PFN
Value: 800000000

Key : WER.OS.Branch
Value: vb_release

Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z

Key : WER.OS.Version
Value: 10.0.19041.1


BUGCHECK_CODE: 1a

BUGCHECK_P1: 41792

BUGCHECK_P2: ffff83816716da08

BUGCHECK_P3: 800000000000

BUGCHECK_P4: 0

MEMORY_CORRUPTOR: ONE_BIT

BLACKBOXNTFS: 1 (!blackboxntfs)


CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: autochk.exe

STACK_TEXT:
ffff988d4679f388 fffff8054624423a : 000000000000001a 0000000000041792 ffff83816716da08 0000800000000000 : nt!KeBugCheckEx
ffff988d4679f390 fffff80546242a6f : ffff8688b7883700 0000000000000000 ffff868800000002 0000000000000000 : nt!MiDeleteVa+0x153a
ffff988d4679f490 fffff80546212c10 : 0000000000000001 ffff988d00000000 ffff8688b7883550 ffff8688b7910080 : nt!MiDeletePagablePteRange+0x48f
ffff988d4679f7a0 fffff80546252277 : 000000002ce2db4f 0000000000000000 ffff868800000000 fffff80500000000 : nt!MiDeleteVad+0x360
ffff988d4679f8b0 fffff805465f908c : ffff988d00000000 0000000000000000 ffff988d4679fa10 000002ce2db30000 : nt!MiFreeVadRange+0xa3
ffff988d4679f910 fffff805465f8b65 : 00007ff70784b980 000002ce44f49e50 ffff988d4679fad8 0000000000000000 : nt!MmFreeVirtualMemory+0x4ec
ffff988d4679fa60 fffff80546408bb8 : ffff8688b7910080 ffff868800000001 0000000000000000 ffff868800000000 : nt!NtFreeVirtualMemory+0x95
ffff988d4679fac0 00007ffa4676d134 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x28
000000e2f757a4b8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ffa`4676d134


MODULE_NAME: hardware

IMAGE_NAME: memory_corruption

STACK_COMMAND: .thread ; .cxr ; kb

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_ONE_BIT

OS_VERSION: 10.0.19041.1

BUILDLAB_STR: vb_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {e3faf315-c3d0-81db-819a-6c43d23c63a7}

Followup: MachineOwner

I work in tech, but I am by no means a master, and to be frank, I don't know what I'm reading here. I can gather that it is telling me that there's something wrong with memory, in that it's seeing corruption, but other than that I'm honestly not too sure.

Here's the event log that prompted me finding these issues:

Event ID 1001

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000001a (0x0000000000041792, 0xffff83816716da08, 0x0000800000000000, 0x0000000000000000). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: 15812135-3f48-42c4-b474-5b9fd5a5cf7e.

If there's any more information required, please don't hesitate to ask and I will do my best to gather it for you.

Answer 1

Chkdsk displayed some cleaning.

Please run these administrative command prompt commands:

wmic computersystem where name="%computername%" set automaticmanagedpagefile=true

wmic computersystem where name="%computername%" get automaticmanagedpagefile

When these have completed > right click on the top bar or title bar of the administrative command box > left click on edit then select all > right click on the top bar again > left click on edit then copy > paste into this thread"

.
.
.
.
.
Please remember to vote and to mark the replies as answers if they help.

On the bottom of each post there is:

Propose as answer = answered the question

On the left side of each post: Vote = a helpful post
.
.
.
.
.

Answer 2

Hi docs,

Please see the following for the C: drive as well, my mind jumped to just immediately performing chkdsk /f like it mentions, but I figured I should wait as you're the one leading this triage:

The C: drive has displayed some need for more repair as well:

Chkdsk was executed in scan mode on a volume snapshot.    
  
Checking file system on \Device\HarddiskVolume4  
  
Stage 1: Examining basic file system structure ...  
  925696 file records processed.                                                         File verification completed.  
 Phase duration (File record verification): 3.80 seconds.  
  6396 large file records processed.                                     Phase duration (Orphan file record recovery): 0.00 milliseconds.  
  0 bad file records processed.                                       Phase duration (Bad file record checking): 0.00 milliseconds.  
  
Stage 2: Examining file name linkage ...  
  2570 reparse records processed.                                           Found an unneeded link ($FILE_NAME: "MI488F~1.CAT") in index "$I30" of directory "\Windows\servicing\Packages <0x2,0x3562a>"  
was not able to send command for self-healing due to lack of memory.  
  
----------------------------------------------------------------------  
  
  
Stage 1: Examining basic file system structure ...  
  
Stage 2: Examining file name linkage ...  
The file reference 0x200000003da37 of index entry MI488F~1.CAT of index $I30  
with parent 0x3562a is not the same as 0x300000003da37.  
Deleting index entry MI488F~1.CAT in index $I30 of file 3562A.  
"chkdsk /scan" is aborting due to self-healing command failure: 0xc0000102  
"chkdsk /f" will be required to repair the volume.  

Here's the other information you asked for as well:

Microsoft Windows [Version 10.0.19042.1288]  
(c) Microsoft Corporation. All rights reserved.  
  
C:\WINDOWS\system32>wmic computersystem where name="%computername%" set automaticmanagedpagefile=true  
Updating property(s) of '\\DESKTOP-DSA3D75\ROOT\CIMV2:Win32_ComputerSystem.Name="DESKTOP-DSA3D75"'  
Property(s) update successful.  
  
C:\WINDOWS\system32>wmic computersystem where name="%computername%" get automaticmanagedpagefile  
AutomaticManagedPagefile  
TRUE  
  
  
C:\WINDOWS\system32>  

And lastly the two screenshots you requested:

Oh, and also, the BSOD from this morning when the crash began as it does usually:

Answer 3

Prior to your opening this thread the logs had had problems in the chkdsk results.

The report that you posted did not display a time stamp.

The chkdsk /r /v on D: was clean.

Was this chkdsk /r /v C: new or old?

Please post a new V2.

Answer 4

Here's the updated chkdsk as requested.

Source: Wininit
Event ID: 1001

Checking file system on C:  
The type of the file system is NTFS.  
  
A disk check has been scheduled.  
Windows will now check the disk.                           
  
Stage 1: Examining basic file system structure ...  
  932864 file records processed.                                                           
File verification completed.  
 Phase duration (File record verification): 3.13 seconds.  
  7006 large file records processed.                                      
 Phase duration (Orphan file record recovery): 0.00 milliseconds.  
  0 bad file records processed.                                        
 Phase duration (Bad file record checking): 2.31 milliseconds.  
  
Stage 2: Examining file name linkage ...  
  2634 reparse records processed.                                         
  1320894 index entries processed.                                                          
Index verification completed.  
 Phase duration (Index verification): 9.60 seconds.  
  0 unindexed files scanned.                                           
 Phase duration (Orphan reconnection): 1.54 seconds.  
  0 unindexed files recovered to lost and found.                       
 Phase duration (Orphan recovery to lost and found): 13.79 milliseconds.  
  2634 reparse records processed.                                         
 Phase duration (Reparse point and Object ID verification): 10.41 milliseconds.  
  
Stage 3: Examining security descriptors ...  
Cleaning up 315 unused index entries from index $SII of file 0x9.  
Cleaning up 315 unused index entries from index $SDH of file 0x9.  
Cleaning up 315 unused security descriptors.  
Security descriptor verification completed.  
 Phase duration (Security descriptor verification): 17.69 milliseconds.  
  194016 data files processed.                                              
 Phase duration (Data attribute verification): 2.32 milliseconds.  
CHKDSK is verifying Usn Journal...  
  35111704 USN bytes processed.                                                              
Usn Journal verification completed.  
 Phase duration (USN journal verification): 28.32 milliseconds.  
  
Stage 4: Looking for bad clusters in user file data ...  
  932848 files processed.                                                                  
File data verification completed.  
 Phase duration (User file recovery): 7.48 minutes.  
  
Stage 5: Looking for bad, free clusters ...  
  104660193 free clusters processed.                                                          
Free space verification is complete.  
 Phase duration (Free space recovery): 0.00 milliseconds.  
  
Windows has scanned the file system and found no problems.  
No further action is required.  
  
 976101375 KB total disk space.  
 555993640 KB in 723962 files.  
    401416 KB in 194017 indexes.  
         0 KB in bad sectors.  
   1065547 KB in use by the system.  
     65536 KB occupied by the log file.  
 418640772 KB available on disk.  
  
      4096 bytes in each allocation unit.  
 244025343 total allocation units on disk.  
 104660193 allocation units available on disk.  
Total duration: 7.72 minutes (463502 ms).  
  
Internal Info:  
00 3c 0e 00 e7 01 0e 00 0b ac 18 00 00 00 00 00  .<..............  
f5 09 00 00 55 00 00 00 00 00 00 00 00 00 00 00  ....U...........  

I recorded the process using my phone and chkdsk DID state that it was repairing things, and it seems to have done so successfully, as it processed itself through 0% to 100% and then rebooted and processed successfully once again. Let me know if you need any more details.

I noticed something strange, and I thought I would post it for your reference even if it turns out it isn't relevant, as it happened to be amongst the event logs on boot that I spotted:

Source: Windows Error Reporting
Event ID: 1001

Fault bucket 1589877815906082239, type 4  
Event Name: APPCRASH  
Response: Not available  
Cab Id: 0  
  
Problem signature:  
P1: ArmourySocketServer.exe  
P2: 0.0.8.8  
P3: 611e0457  
P4: ArmourySocketServer.exe  
P5: 0.0.8.8  
P6: 611e0457  
P7: c0000005  
P8: 000000000005ab00  
P9:   
P10:   
  
Attached files:  
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER37B9.tmp.dmp  
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER39FC.tmp.WERInternalMetadata.xml  
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER3A1D.tmp.xml  
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER3A1B.tmp.csv  
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER3A2B.tmp.txt  
  
These files may be available here:  
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_ArmourySocketSer_26c83645e16a1a667d6ede8a7636afc8277d487_11506942_c818072c-5583-4a90-a7e4-cf5e03eaf6ab  
  
Analysis symbol:   
Rechecking for solution: 0  
Report Id: f69241d0-5365-4049-b780-555b85918df9  
Report Status: 268435456  
Hashed bucket: 252613a932cf99cf36106173355b1dbf  
Cab Guid: 0  

Source: Application Error
Event ID: 1000

Faulting application name: ArmourySocketServer.exe, version: 0.0.8.8, time stamp: 0x611e0457  
Faulting module name: ArmourySocketServer.exe, version: 0.0.8.8, time stamp: 0x611e0457  
Exception code: 0xc0000005  
Fault offset: 0x000000000005ab00  
Faulting process ID: 0xe1c  
Faulting application start time: 0x01d7c3a06b128faa  
Faulting application path: C:\Program Files (x86)\ASUS\ArmouryDevice\dll\ArmourySocketServer\ArmourySocketServer.exe  
Faulting module path: C:\Program Files (x86)\ASUS\ArmouryDevice\dll\ArmourySocketServer\ArmourySocketServer.exe  
Report ID: f69241d0-5365-4049-b780-555b85918df9  
Faulting package full name:   
Faulting package-relative application ID:   

Here's a screenshot, all three event logs are in a row, from top to bottom (as they are ordered in this post)

Answer 5

The V2 log collector will collect most of the logs needed for troubleshooting BSOD.

Occasionally I'll ask you to post a log that it does not collect.

This thread is to troubleshoot windows crashes or BSOD.
Application crashes may be able to be troubleshooted with the software manufacturer.
For ArmourySocketServer you can contact Asus for troubleshooting.

The chkdsk results reported only cleaning with both C: and D:.

So there were no recurrent problems seen with the drive file systems.

Open administrative Powershell (PS) and copy and paste:

Get-WinEvent -ProviderName Microsoft-Windows-Kernel-boot -MaxEvents 10 | Where-Object {$_.id -like “27”}

Post images or share links into this thread.

The Microsoft Q&A website has a feature on the left side of each post.
Clicking on the up arrow is the method to acknowledge that you found that post informative or useful.
It is used instead or in addition to thank you.

.
.
.
.
.
Please remember to vote and to mark the replies as answers if they help.

On the bottom of each post there is:

Propose as answer = answered the question

On the left side of each post: Vote = a helpful post
.
.
.
.
.