BSOD "System_Thread_Exception_Not_Handled" after installing new SSD

Replacing a 15 year old HHD with a new SSD and getting "System_Thread_Exception_Not_Handled" error.
If I disconnect the new SSD I can boot up fine, but reinstalling the SSD and I crash again. I want to clone the old HDD to the SSD, but gotta boot to do that.
System: ASRock Z77 Extreme4, Intel Core i7 3770, 16 gig of ram, 2TB HHD, 1TB Boot SSD, 2TB Game SSD.
Windows 10 build 19045.2965
New SSD is Samsung 870 EVO 4TB.
Cannot attach the V2 log. When I try to add it, it say Upload of file failed. It is zipped. Opening it, there are no recent dump files. I don't get it, Windows 'collecting information' message went to 100%.

Thanks

Upload the V2 log to the cloud somewhere (Dropbox, OneDrive, Google Drive, etc.) with a link to it here (be sure to make it public).

This is a SATA SSD? I don't think that board has any M.2 slots?

Is there anything on that SSD, or is it blank?

Do you have RAID enabled in the BIOS (you shouldn't have)?

Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

After my post, I attached the SSD again, BSOD'ed, and ran the crash report again. Still did not create a report for the crash last night.

It is a SATA SSD. MOBO is too old for M.2. No Raid, SSD is blank, brand new out of the box.

- - - Updated - - -

Anyone have any insight? Please?

The dumps are old and of no interest.

You have a 1TB Samsung 860 SATA SSD as your boot drive (C: drive), a 2TB Hitachi SATA HDD (D: drive), and a 2TB Crucial SATA SSD (H: drive). Presumably the 15-year old HDD is the Hitachi?

What SSD are you trying to add? If you remove the HDD and replace it with the SSD, using the same connectors, does it boot?

New SSD is Samsung 870 EVO 4TB. Hitachi is the old HDD. (I want to clone this to the new drive, lots of data)

I removed the HDD and plugged in the new drive with the same plugs, BSOD. I unplugged everything but the new drive and the Boot drive, BSOD. I plugged in nothing but the new drive, it asked for a floppy to boot from (LOL, the good old days)

Also, I let the BSOD go through to reboot, twice each time, no new .dmp files were created. I looked at my CrashDumps, and the system Crashdumps and no new files.

Ah. To utilise a drive greater than 2.2TB it must be formatted as GPT, see here: https://learn.microsoft.com/en-us/tr...exceeding-2-tb. If you ever plan to boot from that 4TB drive you must also use UEFI booting.

I doubt that's what is causing the crash however. It's more likely that the drive is faulty. Can you try it in another PC? Or put it in a caddy and try it as a USB attached drive?

What was the BSOD bugcheck code?

Confirmed that 2 of my drives are not GPT, including the Boot drive. Thanks for reminding me.

I found an attached drive case and hooked the new drive up. Was able to initialize the drive with Disk Management and format it. System recognized it. Did not assign a drive letter. I did confirm that BIOS can see and recognize the drive and ID'ed it correctly as a Samsung 4tb drive.

Took it out of the enclosure and hooked it back up to the computer with SATA. The computer booted without issue. However, about 10 minutes later it BSOD'd. This time I got a crash report, however. That is attached.

Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

Please make sure that links are available without logon.

The June 1st dump is clear cut, it's a classic IRQL_NOT_LESS_OR_EQUAL. That indicates that a kernel-mode driver accessed an invalid memory page (not allocated or paged out) whilst running at an elevated IRQL. Microsoft kernel drivers never make this basic error, it's always a third-party driver that's responsible.

Argument 4 in the triage analysis gives us the address of the module where the BSOD occurred...

Code:

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8016c68b7a1, address which referenced memory

That address is in the Windows nt!KiRemoveEntryTimer function...

Code:

7: kd> ln fffff8016c68b7a1
(fffff801`6c68b750)   nt!KiRemoveEntryTimer+0x51   |  (fffff801`6c68ba20)   nt!KiSelectActiveTimerTable

We can see this function called in frame 3 of the stack trace...

Code:

7: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffbc85`f48849d8 fffff801`6c80fd29     nt!KeBugCheckEx
01 ffffbc85`f48849e0 fffff801`6c80b8e3     nt!KiBugCheckDispatch+0x69
02 ffffbc85`f4884b20 fffff801`6c68b7a1     nt!KiPageFault+0x463
03 ffffbc85`f4884cb0 fffff801`6c68adaa     nt!KiRemoveEntryTimer+0x51
04 ffffbc85`f4884d20 fffff801`6c804195     nt!KiRetireDpcList+0x73a
05 ffffbc85`f4884fb0 fffff801`6c803f80     nt!KxRetireDpcList+0x5
06 ffffbc85`f7735ac0 fffff801`6c803705     nt!KiDispatchInterruptContinue
07 ffffbc85`f7735af0 fffff801`6c7fe481     nt!KiDpcInterruptBypass+0x25
08 ffffbc85`f7735b00 00000000`00000000     nt!KiInterruptDispatchNoLockNoEtw+0xb1

Looking deeper at the details of frame 3 we can see why we had the BSOD...

Code:

7: kd> .frame /r 3
03 ffffbc85`f4884cb0 fffff801`6c68adaa     nt!KiRemoveEntryTimer+0x51
rax=0000000000000000 rbx=0000000000000012 rcx=0000000000000000
rdx=ffffbf0f0b4b8218 rsi=0000000000000440 rdi=0000000000000003
rip=fffff8016c68b7a1 rsp=ffffbc85f4884cb0 rbp=0000000000000012
 r8=0000000000000000  r9=ffffbc85f4884da8 r10=fffff80169ff0ac0
r11=0000000000000000 r12=0000000000002440 r13=000000000031cb28
r14=fffff80169ff0ac0 r15=0000000000000012
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0000  ds=002b  es=002b  fs=0053  gs=002b             efl=00000282
nt!KiRemoveEntryTimer+0x51:
fffff801`6c68b7a1 48395108        cmp     qword ptr [rcx+8],rdx ds:002b:00000000`00000008=????????????????

The CMP instruction being executed in nt!KiRemoveEntryTimer referenced a memory location pointed to (in part) by the RCX register. This pointer should almost certainly point to the timer structure for which an entry is being removed. However, as you can see the RCX register is all zeroes and thus the referenced memory address is invalid (=????????????????).

Clearly the RCX register should have been set by a driver we don't see on this limited call stack. If we display the (relevant part of the) full call stack the problem third-party driver is revealed...

Code:

ffffbc85`f7735868  fffff801`6c667226 nt!EtwpSwitchBuffer+0x146
ffffbc85`f7735870  00000000`00000004
ffffbc85`f7735878  fffff801`715be250Unable to load image \SystemRoot\system32\drivers\aswVmm.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for aswVmm.sys
 aswVmm+0xe250
ffffbc85`f7735880  fffff7f9`00000004
ffffbc85`f7735888  00000000`00000001
ffffbc85`f7735890  fffff7f9`00017950
ffffbc85`f7735898  fffff801`6c78dd5b nt!HalpHvCounterQueryCounter+0x1b

The aswVmm.sys driver is a component of Avast! Security (it's actually the Avast! VM Monitor driver).

I really have lost count of the number of BSODs caused by third-party antimalware tools - and Avast! is one of the worst IMO. The version of aswVmm.sys that you have looks to be current...

Code:

7: kd> lmDvmaswVmm
Browse full module list
start             end                 module name
fffff801`715b0000 fffff801`715fd000   aswVmm   T (no symbols)           
    Loaded symbol image file: aswVmm.sys
    Image path: \SystemRoot\system32\drivers\aswVmm.sys
    Image name: aswVmm.sys
    Browse all global symbols  functions  data
    Timestamp:        Wed Apr 26 15:09:12 2023 (64491468)
    CheckSum:         00059133
    ImageSize:        0004D000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

It's still worth checking for an Avast! update though if you really must use it. TBH my best advice is to uninstall it using the appropriate specialised tool here. You really don't need third-party security on Windows 10 or 11.

THANK YOU!!
I updated Avast! and the BSOD's have stopped. I installed the new drive as a storage drive and am able to use 4TB, and in fact moved all the files from the HDD.

Thank you for all your help.