Question Can someone please analyse this BSOD dump file for me ?

[Alexvideo]

Im a video editor and since a while back pc started to blue screen randomly when exporting or doing heavier task but the dask depends on the program mostly in Resolve and Premier Pro.

I built the pc myself and recently upgraded the cpu il link the dump file and system specs.
I tried meem test stress testing the gpu and cpu without a problem or a crash but when editing it does it every time
I also have a fresh Win11 installed.(MB bios up to date for the newer cpu)
I have been struggling with this fdor months now using laptop for heavier tasks but its affecting my work hopefully somebody can give me a hand or have an idea about what could be wrong

Processor AMD Ryzen 9 5950X 16-Core Processor 3.40 GHz
Installed RAM 32.0 GB
x470- f Asus motherboard
1080 ti gigabyte aurous water cooled with aio

---

windbg file link @weetransfer

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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: ffff9a85a27cd250, memory referenced.
Arg2: 0000000000000002, X64: bit 0 set if the fault was due to a not-present PTE.
bit 1 is set if the fault was due to a write, clear if a read.
bit 3 is set if the processor decided the fault was due to a corrupted PTE.
bit 4 is set if the fault was due to attempted execute of a no-execute PTE.
- ARM64: bit 1 is set if the fault was due to a write, clear if a read.
bit 3 is set if the fault was due to attempted execute of a no-execute PTE.
Arg3: fffff80038cc882e, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)

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


KEY_VALUES_STRING: 1

Key : AV.Type
Value: Write

Key : Analysis.CPU.mSec
Value: 1765

Key : Analysis.Elapsed.mSec
Value: 5108

Key : Analysis.IO.Other.Mb
Value: 11

Key : Analysis.IO.Read.Mb
Value: 17

Key : Analysis.IO.Write.Mb
Value: 52

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

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

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

Key : Bugcheck.Code.LegacyAPI
Value: 0x50

Key : Dump.Attributes.AsUlong
Value: 1008

Key : Dump.Attributes.DiagDataWrittenToHeader
Value: 1

Key : Dump.Attributes.ErrorCode
Value: 0

Key : Dump.Attributes.KernelGeneratedTriageDump
Value: 1

Key : Dump.Attributes.LastLine
Value: Dump completed successfully.

Key : Dump.Attributes.ProgressPercentage
Value: 0

Key : Failure.Bucket
Value: AV_W_(null)_Ntfs!NtfsGrowLengthInCachedLcn

Key : Failure.Hash
Value: {6cf3e289-3ff4-490f-2157-adefe365446e}


BUGCHECK_CODE: 50

BUGCHECK_P1: ffff9a85a27cd250

BUGCHECK_P2: 2

BUGCHECK_P3: fffff80038cc882e

BUGCHECK_P4: 0

FILE_IN_CAB: 112123-12281-01.dmp

DUMP_FILE_ATTRIBUTES: 0x1008
Kernel Generated Triage Dump

READ_ADDRESS: fffff8003431d470: Unable to get MiVisibleState
Unable to get NonPagedPoolStart
Unable to get NonPagedPoolEnd
Unable to get PagedPoolStart
Unable to get PagedPoolEnd
unable to get nt!MmSpecialPagesInUse
ffff9a85a27cd250

MM_INTERNAL_CODE: 0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

TRAP_FRAME: fffffe8c005d6bd0 -- (.trap 0xfffffe8c005d6bd0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffff9a85a2680000 rbx=0000000000000000 rcx=0000000000029a48
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80038cc882e rsp=fffffe8c005d6d60 rbp=fffffe8c005d6d98
r8=000000000000de18 r9=0000000000000000 r10=0000000000008b6b
r11=ffff9a85bc4b0056 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz ac pe cy
Ntfs!NtfsGrowLengthInCachedLcn+0x132:
fffff800`38cc882e 66448954c810 mov word ptr [rax+rcx*8+10h],r10w ds:ffff9a85`a27cd250=????
Resetting default scope

STACK_TEXT:
fffffe8c`005d69a8 fffff800`33a8c442 : 00000000`00000050 ffff9a85`a27cd250 00000000`00000002 fffffe8c`005d6bd0 : nt!KeBugCheckEx
fffffe8c`005d69b0 fffff800`33862d8c : fffffe8c`005d6b49 00000000`00000002 00000000`00000000 ffff9a85`a27cd250 : nt!MiSystemFault+0x1fd1f2
fffffe8c`005d6ab0 fffff800`33a27529 : fffff800`3150b180 00001f80`008600c4 00000000`0000ffff ffff9a85`a2738b80 : nt!MmAccessFault+0x29c
fffffe8c`005d6bd0 fffff800`38cc882e : ffff9a85`bc49b000 00000000`00000015 ffff9a85`a271dc80 fffffe8c`005d6de0 : nt!KiPageFault+0x369
fffffe8c`005d6d60 fffff800`38bb95a0 : 00000000`000082c5 fffffe8c`005da833 ffff9a85`92740000 00000000`00006930 : Ntfs!NtfsGrowLengthInCachedLcn+0x132
fffffe8c`005d6de0 fffff800`38bb92e0 : 00000000`00000000 ffff9a85`92746a98 00000000`00000000 ffff840d`00000001 : Ntfs!NtfsInsertCachedLcn+0x29c
fffffe8c`005d6e90 fffff800`38cc5454 : 00000000`00000000 ffff9a85`92746a98 ffff9a85`92746a98 00000000`00000000 : Ntfs!NtfsInsertCachedRunInTier+0x5c
fffffe8c`005d6f30 fffff800`38cc5238 : 00000000`00000000 fffffe8c`005d74b0 ffff840d`e643a1b0 00000000`03f00480 : Ntfs!NtfsInsertCachedRun+0xac
fffffe8c`005d6fb0 fffff800`38ba20be : 00000000`00000000 00000000`00000000 ffff9a85`92b8f690 00000000`00010000 : Ntfs!NtfsAddCachedRun+0x80
fffffe8c`005d7020 fffff800`38bad343 : 000000f7`4a2fc5ba fffffe8c`005d74b0 00000000`00000000 fffffe8c`005d7440 : Ntfs!NtfsMarkUnusedContextPostTrimProcessing+0x426
fffffe8c`005d73b0 fffff800`33834f85 : ffff840d`d8c8bc80 ffff840d`ed496040 ffff840d`d8c8bc80 fffff800`3434aac0 : Ntfs!NtfsMarkUnusedContextPreTrimWorkItemProcessing+0x703
fffffe8c`005d79c0 fffff800`33907287 : ffff840d`ed496040 00000000`00000a18 ffff840d`ed496040 fffff800`33834e30 : nt!ExpWorkerThread+0x155
fffffe8c`005d7bb0 fffff800`33a1b8e4 : ffffbd80`67c81180 ffff840d`ed496040 fffff800`33907230 00007ff9`ddf759c0 : nt!PspSystemThreadStartup+0x57
fffffe8c`005d7c00 00000000`00000000 : fffffe8c`005d8000 fffffe8c`005d1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34


SYMBOL_NAME: Ntfs!NtfsGrowLengthInCachedLcn+132

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

IMAGE_VERSION: 10.0.22621.2715

STACK_COMMAND: .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET: 132

FAILURE_BUCKET_ID: AV_W_(null)_Ntfs!NtfsGrowLengthInCachedLcn

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {6cf3e289-3ff4-490f-2157-adefe365446e}

Followup: MachineOwner
---------

 

[ubuysa]

It's really risky making a diagnosis based on just one dump, it would be easier if you download and run the V2 log collector and upload the resulting zip file to the cloud with a (public) link to it here. That way we get all the troubleshooting data in one go. Note that there is no personally identifiable data in there, nor any data that you should worry about making public.

In the absence of that data, the one dump you have uploaded shows a failure during storage drive processing. We see the Windows ntfs.sys filesystem driver called several times, apparently manipulating the drive cache...

2: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffffe8c`005d69a8 fffff800`33a8c442     nt!KeBugCheckEx
01 fffffe8c`005d69b0 fffff800`33862d8c     nt!MiSystemFault+0x1fd1f2
02 fffffe8c`005d6ab0 fffff800`33a27529     nt!MmAccessFault+0x29c
03 fffffe8c`005d6bd0 fffff800`38cc882e     nt!KiPageFault+0x369
04 fffffe8c`005d6d60 fffff800`38bb95a0     Ntfs!NtfsGrowLengthInCachedLcn+0x132
05 fffffe8c`005d6de0 fffff800`38bb92e0     Ntfs!NtfsInsertCachedLcn+0x29c
06 fffffe8c`005d6e90 fffff800`38cc5454     Ntfs!NtfsInsertCachedRunInTier+0x5c
07 fffffe8c`005d6f30 fffff800`38cc5238     Ntfs!NtfsInsertCachedRun+0xac
08 fffffe8c`005d6fb0 fffff800`38ba20be     Ntfs!NtfsAddCachedRun+0x80
09 fffffe8c`005d7020 fffff800`38bad343     Ntfs!NtfsMarkUnusedContextPostTrimProcessing+0x426
0a fffffe8c`005d73b0 fffff800`33834f85     Ntfs!NtfsMarkUnusedContextPreTrimWorkItemProcessing+0x703
0b fffffe8c`005d79c0 fffff800`33907287     nt!ExpWorkerThread+0x155
0c fffffe8c`005d7bb0 fffff800`33a1b8e4     nt!PspSystemThreadStartup+0x57
0d fffffe8c`005d7c00 00000000`00000000     nt!KiStartSystemThread+0x34

Note that this is a push-down stack, so you read it from the bottom up. During this ntfs.sys processing we get a page fault and according to the bugcheck the specified memory should have been in a non-pageable memory pool. If we examine the failing function in more detail...

2: kd> .frame /r 4
04 fffffe8c`005d6d60 fffff800`38bb95a0     Ntfs!NtfsGrowLengthInCachedLcn+0x132
rax=ffff9a85a2680000 rbx=000000000000a833 rcx=0000000000029a48
rdx=0000000000000000 rsi=ffff9a85a271dc80 rdi=ffff9a8592746ae8
rip=fffff80038cc882e rsp=fffffe8c005d6d60 rbp=fffffe8c005d6d98
 r8=000000000000de18  r9=0000000000000000 r10=0000000000008b6b
r11=ffff9a85bc4b0056 r12=0000000000000001 r13=000000000000ffff
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040246
Ntfs!NtfsGrowLengthInCachedLcn+0x132:
fffff800`38cc882e 66448954c810    mov     word ptr [rax+rcx*8+10h],r10w ds:002b:ffff9a85`a27cd250=????

You can see at the bottom there that the failing instruction was a MOV (move) instruction using the RAX and RCX registers as a pointer. Both registers appear to contain reasonable values and yet the resulting memory reference is invalid (the ????). Clearly one of those registers contains a bad value, the question is; what set the bad value?

It could be a flaky driver that we don't see in this dump (not unusual) - that will take a bit more work to find - or it could be a flaky storage drive. If this drive is an M.2 drive then try removing the drive and re-seating it firmly. I've seen many niggly issues caused by poorly seated M.2 drives.

I really can't comment more without seeing the V2 log data.

 

[Alexvideo]

It's really risky making a diagnosis based on just one dump, it would be easier if you download and run the V2 log collector and upload the resulting zip file to the cloud with a (public) link to it here. That way we get all the troubleshooting data in one go. Note that there is no personally identifiable data in there, nor any data that you should worry about making public.

In the absence of that data, the one dump you have uploaded shows a failure during storage drive processing. We see the Windows ntfs.sys filesystem driver called several times, apparently manipulating the drive cache...

2: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffffe8c`005d69a8 fffff800`33a8c442     nt!KeBugCheckEx
01 fffffe8c`005d69b0 fffff800`33862d8c     nt!MiSystemFault+0x1fd1f2
02 fffffe8c`005d6ab0 fffff800`33a27529     nt!MmAccessFault+0x29c
03 fffffe8c`005d6bd0 fffff800`38cc882e     nt!KiPageFault+0x369
04 fffffe8c`005d6d60 fffff800`38bb95a0     Ntfs!NtfsGrowLengthInCachedLcn+0x132
05 fffffe8c`005d6de0 fffff800`38bb92e0     Ntfs!NtfsInsertCachedLcn+0x29c
06 fffffe8c`005d6e90 fffff800`38cc5454     Ntfs!NtfsInsertCachedRunInTier+0x5c
07 fffffe8c`005d6f30 fffff800`38cc5238     Ntfs!NtfsInsertCachedRun+0xac
08 fffffe8c`005d6fb0 fffff800`38ba20be     Ntfs!NtfsAddCachedRun+0x80
09 fffffe8c`005d7020 fffff800`38bad343     Ntfs!NtfsMarkUnusedContextPostTrimProcessing+0x426
0a fffffe8c`005d73b0 fffff800`33834f85     Ntfs!NtfsMarkUnusedContextPreTrimWorkItemProcessing+0x703
0b fffffe8c`005d79c0 fffff800`33907287     nt!ExpWorkerThread+0x155
0c fffffe8c`005d7bb0 fffff800`33a1b8e4     nt!PspSystemThreadStartup+0x57
0d fffffe8c`005d7c00 00000000`00000000     nt!KiStartSystemThread+0x34

Note that this is a push-down stack, so you read it from the bottom up. During this ntfs.sys processing we get a page fault and according to the bugcheck the specified memory should have been in a non-pageable memory pool. If we examine the failing function in more detail...

2: kd> .frame /r 4
04 fffffe8c`005d6d60 fffff800`38bb95a0     Ntfs!NtfsGrowLengthInCachedLcn+0x132
rax=ffff9a85a2680000 rbx=000000000000a833 rcx=0000000000029a48
rdx=0000000000000000 rsi=ffff9a85a271dc80 rdi=ffff9a8592746ae8
rip=fffff80038cc882e rsp=fffffe8c005d6d60 rbp=fffffe8c005d6d98
 r8=000000000000de18  r9=0000000000000000 r10=0000000000008b6b
r11=ffff9a85bc4b0056 r12=0000000000000001 r13=000000000000ffff
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040246
Ntfs!NtfsGrowLengthInCachedLcn+0x132:
fffff800`38cc882e 66448954c810    mov     word ptr [rax+rcx*8+10h],r10w ds:002b:ffff9a85`a27cd250=????

You can see at the bottom there that the failing instruction was a MOV (move) instruction using the RAX and RCX registers as a pointer. Both registers appear to contain reasonable values and yet the resulting memory reference is invalid (the ????). Clearly one of those registers contains a bad value, the question is; what set the bad value?

It could be a flaky driver that we don't see in this dump (not unusual) - that will take a bit more work to find - or it could be a flaky storage drive. If this drive is an M.2 drive then try removing the drive and re-seating it firmly. I've seen many niggly issues caused by poorly seated M.2 drives.

I really can't comment more without seeing the V2 log data.

Thank you for the quick reply! I’m not at home now but will do the v2 log data as soon as possible.I recently installed windows on a new crucial m2 drive in a new slot it used to do it on the old m2 drive which is sloted in the faster pic slot actually. Installed windows Nicosia drivers and DaVinci resolve just as a test still did it at first but less frequent now it started again as before. Without me installing anything else .
I did read something about drive problems from what I could tell was erotte. In the dmp, so did a drive check and resulted in a 4tb disk drive giving an overheating issue , I disconnected the drive thinking that was it, it was not. So yea have no clue my imial guess was maybe the power supply it tends to crash when I’m using a lot resources mostly gpu , or maybe the motherboard since I’m having issues when connecting usb external drives with large capacity and no external power usb to type b conectors , the had get disconnected at random
But yea thank you again and hopefully with the full data it will be easier to pinpoint the problem

 

[Alexvideo]

It's really risky making a diagnosis based on just one dump, it would be easier if you download and run the V2 log collector and upload the resulting zip file to the cloud with a (public) link to it here. That way we get all the troubleshooting data in one go. Note that there is no personally identifiable data in there, nor any data that you should worry about making public.

In the absence of that data, the one dump you have uploaded shows a failure during storage drive processing. We see the Windows ntfs.sys filesystem driver called several times, apparently manipulating the drive cache...

2: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffffe8c`005d69a8 fffff800`33a8c442     nt!KeBugCheckEx
01 fffffe8c`005d69b0 fffff800`33862d8c     nt!MiSystemFault+0x1fd1f2
02 fffffe8c`005d6ab0 fffff800`33a27529     nt!MmAccessFault+0x29c
03 fffffe8c`005d6bd0 fffff800`38cc882e     nt!KiPageFault+0x369
04 fffffe8c`005d6d60 fffff800`38bb95a0     Ntfs!NtfsGrowLengthInCachedLcn+0x132
05 fffffe8c`005d6de0 fffff800`38bb92e0     Ntfs!NtfsInsertCachedLcn+0x29c
06 fffffe8c`005d6e90 fffff800`38cc5454     Ntfs!NtfsInsertCachedRunInTier+0x5c
07 fffffe8c`005d6f30 fffff800`38cc5238     Ntfs!NtfsInsertCachedRun+0xac
08 fffffe8c`005d6fb0 fffff800`38ba20be     Ntfs!NtfsAddCachedRun+0x80
09 fffffe8c`005d7020 fffff800`38bad343     Ntfs!NtfsMarkUnusedContextPostTrimProcessing+0x426
0a fffffe8c`005d73b0 fffff800`33834f85     Ntfs!NtfsMarkUnusedContextPreTrimWorkItemProcessing+0x703
0b fffffe8c`005d79c0 fffff800`33907287     nt!ExpWorkerThread+0x155
0c fffffe8c`005d7bb0 fffff800`33a1b8e4     nt!PspSystemThreadStartup+0x57
0d fffffe8c`005d7c00 00000000`00000000     nt!KiStartSystemThread+0x34

Note that this is a push-down stack, so you read it from the bottom up. During this ntfs.sys processing we get a page fault and according to the bugcheck the specified memory should have been in a non-pageable memory pool. If we examine the failing function in more detail...

2: kd> .frame /r 4
04 fffffe8c`005d6d60 fffff800`38bb95a0     Ntfs!NtfsGrowLengthInCachedLcn+0x132
rax=ffff9a85a2680000 rbx=000000000000a833 rcx=0000000000029a48
rdx=0000000000000000 rsi=ffff9a85a271dc80 rdi=ffff9a8592746ae8
rip=fffff80038cc882e rsp=fffffe8c005d6d60 rbp=fffffe8c005d6d98
 r8=000000000000de18  r9=0000000000000000 r10=0000000000008b6b
r11=ffff9a85bc4b0056 r12=0000000000000001 r13=000000000000ffff
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040246
Ntfs!NtfsGrowLengthInCachedLcn+0x132:
fffff800`38cc882e 66448954c810    mov     word ptr [rax+rcx*8+10h],r10w ds:002b:ffff9a85`a27cd250=????

You can see at the bottom there that the failing instruction was a MOV (move) instruction using the RAX and RCX registers as a pointer. Both registers appear to contain reasonable values and yet the resulting memory reference is invalid (the ????). Clearly one of those registers contains a bad value, the question is; what set the bad value?

It could be a flaky driver that we don't see in this dump (not unusual) - that will take a bit more work to find - or it could be a flaky storage drive. If this drive is an M.2 drive then try removing the drive and re-seating it firmly. I've seen many niggly issues caused by poorly seated M.2 drives.

I really can't comment more without seeing the V2 log data.

Here it is, hope it's shared properly and contains the information needed to get to the bottom of this.

V2 log zip file via google drive

 

[ubuysa]

There is only one dump because there's only been the one BSOD since the System logs started on 13th Nov. That dump I pointed out was probably down to a flaky M.2 drive. Now I can see that you have two Samsung NVMe drives and a Corsair NVMe drive, as well as a SATA SSD.

In your System log there are errors relating to an NVMe drive...

Event[2004]
  Log Name: System
  Source: stornvme
  Date: 2023-11-13T03:15:07.3070000Z
  Event ID: 11
  Task: N/A
  Level: Error
  Opcode: N/A
  Keyword: Classic,
  User: N/A
  User Name: N/A
  Computer: AlexPC11-23
  Description:
The driver detected a controller error on \Device\RaidPort2.

Event[2005]
  Log Name: System
  Source: disk
  Date: 2023-11-13T03:16:52.2050000Z
  Event ID: 51
  Task: N/A
  Level: Warning
  Opcode: N/A
  Keyword: Classic,
  User: N/A
  User Name: N/A
  Computer: AlexPC11-23
  Description:
An error was detected on device \Device\Harddisk4\DR4 during a paging operation.

It's clear that your issue is related to one of your NVMe drives - and most likely your system drive. Have you tried removing and re-seating the M.2 drives yet? You should also download Samsung Magician and run a full diagnostic on those Samsung drives, also check for firmware and/or driver updates for the drives. Corsair don't have a diagnostic tool unfortunately.

BTW. I note that your boot drive is the Corsair NVMe, but your System drive is the 500GB Samsung 970 EVO Plus. Was that deliberate, or did you not intend that?

 

[Alexvideo]

There is only one dump because there's only been the one BSOD since the System logs started on 13th Nov. That dump I pointed out was probably down to a flaky M.2 drive. Now I can see that you have two Samsung NVMe drives and a Corsair NVMe drive, as well as a SATA SSD.

In your System log there are errors relating to an NVMe drive...

Event[2004]
  Log Name: System
  Source: stornvme
  Date: 2023-11-13T03:15:07.3070000Z
  Event ID: 11
  Task: N/A
  Level: Error
  Opcode: N/A
  Keyword: Classic,
  User: N/A
  User Name: N/A
  Computer: AlexPC11-23
  Description:
The driver detected a controller error on \Device\RaidPort2.

Event[2005]
  Log Name: System
  Source: disk
  Date: 2023-11-13T03:16:52.2050000Z
  Event ID: 51
  Task: N/A
  Level: Warning
  Opcode: N/A
  Keyword: Classic,
  User: N/A
  User Name: N/A
  Computer: AlexPC11-23
  Description:
An error was detected on device \Device\Harddisk4\DR4 during a paging operation.

It's clear that your issue is related to one of your NVMe drives - and most likely your system drive. Have you tried removing and re-seating the M.2 drives yet? You should also download Samsung Magician and run a full diagnostic on those Samsung drives, also check for firmware and/or driver updates for the drives. Corsair don't have a diagnostic tool unfortunately.

BTW. I note that your boot drive is the Corsair NVMe, but your System drive is the 500GB Samsung 970 EVO Plus. Was that deliberate, or did you not intend that?

Hey there! So, I ran a full scan on my Samsung NVMe drives, and they're all in good working condition. Just to give you a little background, I used to have a 500GB drive as my main drive, but I replaced it with a 2TB drive that's now in the fastest Pcie slot on my motherboard. However, I didn't get rid of the 500GB drive just yet because I still had some important data on it that I needed to recover( so ran dual boot with win 10). I did the same thing with my Corsair drive, which I added to my system to perform a clean Windows installation on a new SSD that I took from an unused laptop.

The bsod was on the old Windows install which I still have access to if I set the 2tb as the boot drive ,problem is it never created a minidump file I even tried taking out the automatic restart. and still nothing ~

So I'm beginning to think that the NVMe issue is a one-off and the real culprit is yet to be found, also cause I've had several bsod on this win install already.

I could try to use the v2 on the old win11 install but as I said noo minidump file there I just checked
And yes reseated the drive I have 2 on the motherboard and one though an expansion card

 

[Alexvideo]

Just tried exporting a video and bsod in the first 2 minutes , mini dump file is still the old one fro.m 21/11/2023 no update

 

[ubuysa]

If you have multiple drives active all with different Windows systems on them then you're asking for trouble.