New
#81
Your manual says it is in the Dram information > Load XMP Setting
Your manual says it is in the Dram information > Load XMP Setting
It is set to Auto
"It is set to Auto"
Perfect.
"Would a different wifi adapter be suitable?"
Try everything you can.
"Restarted into safe mode with networking and had a near immediate BSOD"
"Not sure exactly what this experiment is seeking to prove or disprove."
When you stop getting BSOD'S, we have found the culprit. If you took it to a dealer, they would be interchanging power supply & other parts, until they found the culprit. Theories go out the window.
I'm down to experiment further, just don't have the components on hand to do that right away.
Safe mode with no networking stopped the BSODs. Stable idle with screensaver overnight, haven't been able to do that otherwise.When you stop getting BSOD'S, we have found the culprit.
Normal boot with integrated NIC disabled in device manager did not stop BSODs.
In the meantime, is there any other way to bypass the built in network card on the mobo? I don't really need to set it up with youtube videos or anything to test at this point, getting an overnight idle in normal boot would be progress.
"Safe mode with no networking stopped the BSODs. Stable idle with screensaver overnight, haven't been able to do that otherwise"
That is why I'm going down a problem with networking path.
"is there any other way to bypass the built in network card on the mobo?"
Yes, when you plug a network card into a slot on the motherboard.
I have always used just the basic card, naturally you have to get one to suit your slots.
Security Challenge
I'll try and borrow a card from my buddy. If I have to order one, I'ma go with a north american seller, heheh
Coincidentally, the only place I can find a PCB I want for a different project is in AU, but they can't sell to me apparently.
First off, congrats to all for perseverance.
As an observer:
- Windows BSODs whilst connected to YouTube using ethernet controller (connected to PCI controller via PCI bus)
- Windows BSODs with USB Wi-Fi dongle (using USB Host controller as a bridge to PCI controller via PCI bus)
- Latest SnailDriver screenshot indicates the driver for the PCI bus is out of date (although this really means the driver for the PCI controller)
- Linux didn't detect ethernet adapter (connected to PCI controller via PCI bus)
- Linux didn't detect SATA drive (connected via SATA controller to PCI controller via PCI bus)
Doesn't this suggest that the common hardware component in all this appears to be the PCI controller? If so then an alternate ethernet adapter is unlikely to help (PCI controller and bus again).
I don't have any hardware expertise nor any suggestions... except perhaps run in Safe Mode with ethernet cable disconnected then, if stable, run normally with ethernet cable disconnected... then, if stable, put the ethernet cable back in whilst Windows is running and, without opening a browser, check for Windows Updates via Settings (or just open a PowerShell/commandline prompt and ping your router) so the ethernet adapter is suddenly used. I can't think of another way of testing the PCI controller.
Hope this helps...
Hi Rick, thanks for slogging through all that to weigh in. JMatt's kept me going, probably would have given up by now without his input.
Your take about the PCI bus makes sense to me, especially if the PCI bus handles USB and integrated nic traffic.
I'll try safe mode with networking with the cable unplugged, see how it goes.
AFAIK the bus is basically just the conduit and it's the PCI controller that actually talks data/addressing with the CPU... which may explain the ntoskernel errors, i.e. ring 0 OS/hardware interaction between the controller and processor. Ethernet, USB and SATA data/addressing do all end up (via their own respective controllers) at the PCI controller so it's the only common gateway to the CPU.
The only other common element to your Windows experience that I can think of is 'device power-management' but I don't have a clue how to test this using Linux.
Windows 10 constantly monitors its environment... so the moment you reconnect the ethernet cable may be all that's required to trigger a BSOD.
Idled overnight in safe mode with networking with the cable unplugged.
However, I noticed this morning that I had the network interface disabled, so maybe that's why it worked.
I've re-enabled the network card, plugged in the cable, and successfully pinged "google.com" from the command line. No BSOD, so the machine has been running for a good 14 hours without rebooting.
I'll leave it on through the day and see how it fares.
Update: 5 hours in safe mode with this forum post up in firefox and network connected. So far so good. Was kind of hoping it'd crash by now tbh....
Update Again: Ok, looks like it finally crashed. DMP timestamps it at 17:50 so that was a pretty good run, but ultimately still not stable.
Not sure how to proceed. I can run the test again since I had the network card disabled at first. Either way, after it was enabled, it ran for several hours in safe mode with networking with the ethernet cable plugged in.
Last edited by molotov256; 14 Apr 2021 at 21:21.