[SOLVED] Sudden BSOD issue

Yeah, it's an NVME SSD (ADATA SX8200 Pro)

It does have a small heatsink on, but the SSD is mounted on the bottom of the motherboard against the bottom of the case. It's a mini itx board so that was the only free space for them to put the M.2 slot. However, since my case (Silverstone SG13) is small, there isn't much airflow around the back of the motherboard.

I did put a desk fan next to the PC and it didn't stop the crashes, but if it's been overheating I guess it could already have done some damage.
 
Yep, that was my thought. NVMe drives run a bit hotter than their SATA counterpart. With a heatsink, I would expect you're less likely to see issues, but it may depend on how well the heat is dissipating in the confined space. When you mentioned it being under the motherboard, I got a bad feeling about heat possibly being the culprit.
 
Do you have any old HDDs lying around that you could install Windows on so that we can rule out motherboard, PSU, etc...?

Bugchecks on the last 3 dumps -

`
Rich (BB code): 

Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\072519-9562-01.dmp]
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Debug session time: Thu Jul 25 15:44:36.983 2019 (UTC - 4:00)
System Uptime: 0 days 0:08:02.673
Probably caused by : ntkrnlmp.exe ( nt!ExpGetProcessInformation+f08 )
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  AV
PROCESS_NAME:  firefox.exe
FAILURE_BUCKET_ID:  AV_INVALID_nt!ExpGetProcessInformation
Bugcheck code 00000050
Arguments ffffd48b`bc517550 00000000`00000002 fffff805`47c24b48 00000000`00000002
BiosVersion = 3406
BiosReleaseDate = 07/10/2017
SystemManufacturer = System manufacturer
SystemProductName = System Product Name
MaxSpeed:     4000
CurrentSpeed: 4008
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\072519-10265-01.dmp]
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Debug session time: Thu Jul 25 15:31:48.118 2019 (UTC - 4:00)
System Uptime: 0 days 0:26:40.819
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : memory_corruption ( nt!MiDeletePteRun+15e2d8 )
BUGCHECK_STR:  0x1a_41790
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
PROCESS_NAME:  svchost.exe
FAILURE_BUCKET_ID:  0x1a_41790_nt!MiDeletePteRun
Bugcheck code 0000001A
Arguments 00000000`00041790 ffffa400`064d5c20 00000000`00000027 00000000`00000028
BiosVersion = 3406
BiosReleaseDate = 07/10/2017
SystemManufacturer = System manufacturer
SystemProductName = System Product Name
MaxSpeed:     4000
CurrentSpeed: 4008
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Loading Dump File [C:\Users\PalmDesert\_jcgriff2_\dbug\__Kernel__\072519-10078-01.dmp]
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Debug session time: Thu Jul 25 15:01:02.529 2019 (UTC - 4:00)
System Uptime: 0 days 0:06:33.219
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+2ae )
BUGCHECK_STR:  0x7f_8
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
PROCESS_NAME:  svchost.exe
FAILURE_BUCKET_ID:  0x7f_8_STACKPTR_ERROR_nt!KiDoubleFaultAbort
Bugcheck code 0000007F
Arguments 00000000`00000008 ffffdd00`c2fb9050 00000000`56e75300 fffff805`8169f283
BiosVersion = 3406
BiosReleaseDate = 07/10/2017
SystemManufacturer = System manufacturer
SystemProductName = System Product Name
MaxSpeed:     4000
CurrentSpeed: 4008
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``

Bugchecks
0x50 - invalid memory referenced
0x1a - severe memory management error
0x7f (0x8,,,) - double fault -- an error occurred while the error handler was processing another error (an "error within an error"; hence a "double fault"

2 dumps named NT (Windows kernel) as the probable cause; the 0x1a BSOD named "memory corruption"; it also warned that symbols could not be found for the Win32 subsystem driver, win32k.sys, the likely victim of the memory corruption. It is a Microsoft Windows driver, so it cannot be the cause.

If you're satisfied with the RAM tests, then SSD would be the next logical place to go.

But as I mentioned earlier, it would be a good idea to stick a SATA HDD into your system (ONLY THAT DRIVE - none others) and install Windows onto it and see if the system regains stability.

If it does not, or if you're unable to install Windows on to it, you can then assume that the failing hardware may be the mobo, PSU or other unknown part.

There is absolutely no way that these BSODs are software (driver) related, Stephen. The sheer number of different bugchecks tells us that.

Regards. . .

John
 
Check for a BIOS update too.

I do not have enough info to look it up for you -

Code: 
BiosVersion = 3406 
BiosReleaseDate = 07/10/2017 
SystemManufacturer = System manufacturer 
SystemProductName = System Product Name

John
 
Sorry to post again, but. . .

I just noticed that on the 0x1a severe memory management error BSOD, the 1st parm was 0x41790

Rich (BB code): 
Bugcheck code 0000001A
Arguments 00000000`00041790 ffffa400`064d5c20 00000000`00000027 00000000`00000028

0x41790A page table page has been corrupted. On a 64 bit version of Windows, parameter 2 contains the address of the PFN for the corrupted page table page. On a 32 bit version of Windows, parameter 2 contains a pointer to the number of used PTEs, and parameter 3 contains the number of used PTEs.
Click to expand...
We're back to the SSD again.

Even though 0x1a is typically a RAM related bugcheck, SSDs act just like RAM and can throw off bugchecks that we used to associate with RAM only.

John
 
Will see if I can dig round in my parts box and find an old HDD/SSD that I can try installing Windows on - good idea. To further support this theory actually, I've been running Linux Mint from a USB SSD for the last few hours and it's been rock solid. If it was a RAM issue, I'd expect to see crashes in Linux as well.

Looks like there's also a new BIOS version so will try updating to that as well.

Version 3805
2018/07/20
Click to expand...
Z170I PRO GAMING BIOS & FIRMWARE | Motherboards | ASUS United Kingdom
 
Ok, so I'm certain it's the SSD. Have been running from another drive this morning without issues.

I've been trying to clone the failing drive to another SSD so I can return the SSD. However, the cloning software I'm using (clonezilla) is actually kernel panicking during the clone process. Yet another sign the SSD is failing... Am going to see if I can do a basic clone with dd in Linux, but if anyone has any suggestions I'd be all ears.
 
Ok, so after that very confident post claiming I'm certain it's the SSD, I'm now really confused. I'm still running off another SSD running Linux. The "failing" SSD is unmounted in Linux, but I've started occasionally seeing tabs crash in FF in Linux.

I still don't think it's RAM, as the BSODs in Windows occur regardless of which stick of RAM I use or which slot it's in. Unless it is just another failing piece of hardware (motherboard/PSU?)
 
Are you able to put your SSD in another computer or do you not have another M.2 (?) motherboard to test with?

I'm sorry to hear you're having all these issues. I had similarly hard to track down hardware failure after a home build of mine a few years ago and it was very annoying.
 
niemiro said:
Are you able to put your SSD in another computer or do you not have another M.2 (?) motherboard to test with?

I'm sorry to hear you're having all these issues. I had similarly hard to track down hardware failure after a home build of mine a few years ago and it was very annoying.
Click to expand...
Good shout. I've transplanted the SSD into a brand new Intel NUC I've got lying around for another project. Let's see how stable it is in the NUC
 
Sorry, John! I have to disagree. Please do not try Macrium Reflect. It's gotten extremely bad and causes severe issues on systems. I spent days diagnosing a WU failure case, it turned out that Macrium had changed the WIMMount path and wreaked havoc on a system. And it did that more than once. Steer clear!
 
softwaremaniac said:
Sorry, John! I have to disagree. Please do not try Macrium Reflect. It's gotten extremely bad and causes severe issues on systems. I spent days diagnosing a WU failure case, it turned out that Macrium had changed the WIMMount path and wreaked havoc on a system. And it did that more than once. Steer clear!
Click to expand...
Really!?! I have been using Macrium Reflect for years without issues. I recently made a universal system image to deploy to all my systems by using VirtualBox and Macrium Reflect, and it has worked flawlessly. I wonder what went wrong on the system you analyzed. Maybe they didn't keep Macrium Reflect updated? Or maybe they updated too soon with a bad version that was later fixed?

Oh, interesting. My WIMMount ImagePath is set to "\??\C:\program files\macrium\reflect\wimmount.sys" but it has not interfered with Windows Updates so far.

Found a reference on the Macrium Reflect forums that others have noticed an issue with uninstalling and that path not changing back to the original location: Wimmount.sys Image Path
 
No, sadly, we have tested multiple versions and the issue still occurs. Not each and every machine experiences it after the same amount of time, but they do eventually. It bricked one of my VMs that I've deployed using MR (I created a VM and saved it via MR, experienced the same issue). It's extremely hard to fix the first time, baceuse you don't know where to look. I had to remote with a businessman in Ireland and we worked on it for 3 days. Do I really need to mention that MR was immediately eradicated from each and every system the guy has...
 
That's interesting. I know Macrium Reflect had some issues with Windows 1903 on my system until I updated it. Most likely wimmount.sys is updated in a Windows Update, and that results in the version that Macrium copied no longer being valid.
 
I've swapped my SSD into the NUC and it's been running for over an hour without any issues. Whilst that's definitely no conclusive, it's longer than it has been running. That said, my SSD runs a lot cooler in the NUC than it did in my PC.

However.... I also swapped the M.2 SSD out of the nuc into my PC and it's also running fine....

If the problem was the SSD, I'd have expected the NUC to crash but so far no issues. And if the problem was other hardware in my PC, I'd expect it still to crash with the new M.2 ssd in it. What I wasn't expecting was both machines to be stable!

Ignore this, my PC has just crashed again. Will update thread in a bit.
 
Last edited:

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top