About a few months ago, I encountered two really annoying issues. One was that my computer really loved to restart itself quite randomly, most of the time when idling or doing a simple task like watching YouTube from one tab of Chrome. Second was that the infamous Blue Screen of Death (BSOD) occurred for quite some numbers too. It only stopped just about a couple months ago.
I got two hypotheses for the random restart. The first was that my PSU was old enough, therefore it needed to be replaced. The second, we started selling ice cream at home and we needed one freezer. So, it might affect the electricity. I was starting to think it was like brown out that made the computer restarted itself. Also there was a chance that these two hypotheses complement each other to affect the two problems that I encountered.
Moving to the blue screen side, it was more complicated. As it would be a cause of a Windows update, installed software, incompatible and/or buggy driver. And don’t forget there is always a chance of misconfigured UEFI.
Coming from a computer engineering background, sometimes I trace problems using the OSI Model. Even when the problem is not quite related to networking. As we can see, the first layer is the Physical Layer. That is why I was trying to look at the hardware first, and more specifically the power supply.
Let’s start breaking down from the first problem.
PSU that was old
The PSU that I was using was old enough for its class. The kind of rule of thumb for PSU age is we look at the warranty. Mine was past its 3 years warranty for about some months. So, it was only natural to replace it.
I replaced the FSP Hexa+ 400 with Seasonic Core GM-500. The Seasonic one is a 500W semi-modular PSU that has 80 Plus Gold certification. My goal was not only to replace the old one, but also upgrade the system altogether. Unfortunately, the problem still persisted even with the new and higher quality PSU.
High power usage from another appliance: ice cream freezer
For this problem, I could not really validate it. At the time there was no wattmeter at hand to calculate the exact power draw. So, my conclusion for this one was just let it slide. As when I took a look at lamps in the house, actually there has never been any brownout.
Changed all SATA cables
The cables might cause the problem as all of them bent when the computer case closed down. Unfortunately the all new cables didn’t do any magic.
f.lux is a software to adjust display’s color temperature. As the nature of the automatic update, it updates quite occasionally. I was afraid some updates might cause the problem.
I was running XMP but raised the frequency from 3000MHz to 3200MHz. So, I decided to change it back to the default XMP. But still no luck with this setting. In the end, running on default JEDEC @2400MHz.
There were no new driver updates on Windows update
The route I went was using DriverPack to check and install any driver updates. Frustratingly DriverPack brought more problems than solution, as follows:
- Installer was detected as malware.
- The actual installed program was detected as malware.
- This is total garbage as making slow/jaggy a mouse cursor.
- Glad I could rollback using system restore points.
The more frustrating part was because of the system restore, I need to re-sign into my account. But somehow I got the wrong password. Therefore I tried to reset it. The one functionality with this reset flow was that there was no verification code delivered to my phone number. As far as I can remember this never works in forever. Sending the code through email is okay by the way.
Checking on Device Manager, there were some undetected PCI/E devices
I’ve come to a conclusion these might be AMD related drivers. Therefore I updated them using the chipset driver installer from AMD website. All good on Device Manager but still no luck with the BSOD.
Disabled Windows Hypervisor Platform, leaving Hyper-V as is
Disabled Hyper-V then enabled Windows Hypervisor Platform
As I’m using Android Emulator from Android Studio, an older version of it (beta support for AMD) required it to be configured like this.
Uninstalled many applications that have drivers
Acronis True Image, EaseUS Partition Master, Betternet and Minitool Partition Wizard.
Also uninstalled some unused applications FAHClient and Python 3.7.6
Updated DroidCam Client from 6.2.7 to 6.3.1
How I tried all of the things above was through some Internet searches and my educated guess. Other than that, I also tried to use WhoCrashed.
As detailed as its information be, the main idea is the same as when we browse through the Internet. The suggestion is more or less the same but we can get more information like the .exe and the bug code. However these are usable only if you really know what it means.
The thing about Hyper-V and Hypervisor was because I played the setting and tried to fix the BSOD. But the IRQL was all about the driver issue, not about the virtualisation.
And yes it was all about the driver. I could only use the computer BSOD free just after updating the DroidCam Client.
When I started working fully from home, we held daily meetings at least once in the morning and once right before the end of the working hours. So, I needed a webcam for the video conference. At the same time, there was an inflated price of webcam (I believe still happening till this writing is posted) and the general situation of the economy in Indonesia was not okay due to Covid-19.
Then I found out about DroidCam. It’s easy to use and free (with the pro version available if we want to upgrade the resolution and unlock more features). Basically you just need to connect your phone with the computer, and that’s it, free webcam!
Unfortunately, the version I downloaded somehow got that nasty bug which caused the BSOD. The crazy part was that I used that version for some months.
At first, I thought updating DroidCam would fix the random restart too. But it was not. Then I tried to rethink the solution from the hardware parts first.
Looking at the PSU, it would not be the case anymore. The cables are all good too. So then there is one thing that I missed. The other thing from the physical parts, UEFI! As I stated earlier, I only change the RAM settings but without resetting the UEFI settings.
The only route that made sense for me was to reset the UEFI and use the computer as usual to test it through. As the process went, I tried to change the UEFI to my original customisation. Changing the LED was fine, also the fan speed, then the RAM settings.
My last setting would be changing the VCore three steps down. As Biostar B350ET2 (the motherboard that I use) doesn’t have an option to specifically set the exact voltage. In the end this was the cause and my solution was to change the VCore two steps from default.
My learning from the BSOD was to focus only on one message first. In this case, I should only fix the drivers and/or applications that have drivers.
From the hardware perspective, it seems whether the motherboard’s VRM has lost its ability to maintain lower voltage or the CPU has a need of a little bit higher voltage. Either way, now I’m happy to use my computer without issues no more.