Windows 10 BSOD Kernel-Power

[Zev_07]

As the title states, I'm getting random BSODs in Windows 10. The Windows event viewer is just showing me Kernel-Power. This issue has persisted in multiple complete reinstalls of Windows 8, 8.1 and 10. It is highly random, sometimes it doesn't happen for 2-3 days, other times it happens within seconds of every restart as soon as Windows boots up. I'm mentioning my configuration below: (please keep in mind that it's a laptop and not a desktop)

HP Envy 14
Core i5 4200U
4GB RAM
Intel HD Graphics 4400/Nvidia GT740M
750GB HDD + 24GB SSD

So far I've ruled out RAM and HDD. RAM through memtest (16 cycles so far and 8+ hours of testing, 0 errors) and HDD because I tried installing Windows on both the SSD and HDD, and the issue persisted nonetheless. I've Googled a ton and now I'm drawing a blank. I'm including one of the memory dumps as well as a screenshot from Bluescreenview and a .txt file from Windows event viewer here:

https/www.mediafire.com/folder/2a17gxybuabf6/BSOD

I need help in narrowing down the component which might be causing this issue. Based on the Google searches I know PSU is a huge factor in Kernel-Power issue but since this is a laptop, I don't know how to test this one.

 

[ffg7]

disconnect the battery to see if still happens.

 

[Zev_07]

disconnect the battery to see if still happens.

Thanks, I'll try that and update.

If it doesn't happen with the battery disconnected though, how would I fix it? Also, I forgot to mention that this issue doesn't happen at all in Ubuntu. Wouldn't a battery problem persist in Linux too?

 

[ffg7]

don't know as I've never used Linux. was the Windows 8 off the recovery disk\partition or from a retail disk?

 

[Zev_07]

don't know as I've never used Linux. was the Windows 8 off the recovery disk\partition or from a retail disk?

It was factory installed, I didn't have to activate it because my laptop activated the Windows by itself when I connected it to the internet after Windows install. I downloaded it from Microsoft and installed using a USB.

Update btw: removing the battery didn't change anything. Encountered the error after a couple of days. Help please!

 

[johnbl]

kernel power error 41 is unrelated to your problem, it is just a log entry to indicated that the system did not do a clean shutdown. It is written when the system boots up again after a power failure or in your case a bugcheck. In this case you has a service running under a host process crash and the system called a bugcheck.


looks like you have a generic windows 10 install and have not updated any of the required custom drivers.
I can see why after looking at the hp support:
http/support.hp.com/us-en/drivers/selfservice/hp-envy-14-k000-sleekbook/5375376/model/5400000

you will want to use the use the BIOS and firmware updates from the HP windows 8.1 support page and also attempt to install any of the drivers that were updated after about may of 2015. (basically all of them)

if you just want to fix the cause of the bugcheck you have to find out what service was running the name is not helpful. It is most likely going to be a service installed by HP or one that requires a custom driver.
Maybe \SystemRoot\System32\drivers\WirelessButtonDriver64.sys Sat Jul 25 14:52:57 2015
(just can not tell with a minidump, need a full or kernel dump)



machine info:
Product Name HP ENVY 14 Sleekbook

Manufacturer Hewlett-Packard
Product 198C
Version 86.14
Chassis Type Notebook
Processor ID 51060400fffbebbf
Processor Version Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
Processor Voltage 88h - 0.8V
External Clock 100MHz
Max Speed 2300MHz
Current Speed 2300MHz

 

[Zev_07]

(just can not tell with a minidump, need a full or kernel dump)

Thank you for your detailed answer. I'm updating the BIOS and Firmware now, along with all the other drivers. If I encounter the BSOD again I'll upload the full dump and update here.

Edit: one question. How did you figure out that WirelessButtonDriver64.sys might be the likely culprit?

 

[johnbl]

I have seen a few bugchecks that involved that driver before. So I was just guessing that you had a similar issue.

(just can not tell with a minidump, need a full or kernel dump)

Thank you for your detailed answer. I'm updating the BIOS and Firmware now, along with all the other drivers. If I encounter the BSOD again I'll upload the full dump and update here.

Edit: one question. How did you figure out that WirelessButtonDriver64.sys might be the likely culprit?

 

[Zev_07]

I have seen a few bugchecks that involved that driver before. So I was just guessing that you had a similar issue.

(just can not tell with a minidump, need a full or kernel dump)

Thank you for your detailed answer. I'm updating the BIOS and Firmware now, along with all the other drivers. If I encounter the BSOD again I'll upload the full dump and update here.

Edit: one question. How did you figure out that WirelessButtonDriver64.sys might be the likely culprit?

Even after installing all the drivers from HP's website. I'm still getting the BSOD. I have a couple of complete memory dumps, but uploading those on my connection would take three forevers because they're 4GB each (and I have 50KB max upload speed). Would you be willing to connect to my machine through RDP to take a look at them?

 

[johnbl]

try turning on verifier functions.
start cmd.exe as an admin, then run
verifier.exe /standard /all
then reboot your system

if verifier finds a driver that is doing something wrong, it will call a bugcheck and name the driver name.
you can then use bluescreenview or whocrashed.exe to look at the memory dump and it should name the driver.

Note: use verifier.exe /reset to turn off verifier functions after you are done testing.
if your machine bugchecks during boot, you will have to go into safe mode and turn off verifier.
F8 to get into safe mode (or shift+f8)

I have seen a few bugchecks that involved that driver before. So I was just guessing that you had a similar issue.

(just can not tell with a minidump, need a full or kernel dump)

Thank you for your detailed answer. I'm updating the BIOS and Firmware now, along with all the other drivers. If I encounter the BSOD again I'll upload the full dump and update here.

Edit: one question. How did you figure out that WirelessButtonDriver64.sys might be the likely culprit?

Even after installing all the drivers from HP's website. I'm still getting the BSOD. I have a couple of complete memory dumps, but uploading those on my connection would take three forevers because they're 4GB each (and I have 50KB max upload speed). Would you be willing to connect to my machine through RDP to take a look at them?

 

[Zev_07]

try turning on verifier functions.
start cmd.exe as an admin, then run
verifier.exe /standard /all
then reboot your system

if verifier finds a driver that is doing something wrong, it will call a bugcheck and name the driver name.
you can then use bluescreenview or whocrashed.exe to look at the memory dump and it should name the driver.

Note: use verifier.exe /reset to turn off verifier functions after you are done testing.
if your machine bugchecks during boot, you will have to go into safe mode and turn off verifier.
F8 to get into safe mode (or shift+f8)

Tried the verifier, it gave the BSOD on Windows start. Logged into safe mode, only two files are causing the issue: dxgkrnl.sys and ntoskrnl.exe. If I uninstall my Nvidia driver, the windows boots up fine with the verifier enabled. Without it, I get the BSOD on Windows start (I've reset the verifier functions now). Verifier also started giving me BSOD on Windows start because of Panda antivirus but I uninstalled it and replaced it with Avast and that's working fine.

I don't get the issue, I've stress tested the Nvidia graphics card using 3DMark and Furmark. For at least 30 minutes each (continuously and multiple times) and it didn't get a BSOD. Randomly though, doing anything other than stress testing such as using Microsoft Office, browsing using Chrome, etc., I get kernel-power BSODs. Any ideas?

 

[johnbl]

you might update the audio drivers for your system, reboot and set the BIOS to defaults then boot winodows.
(motherboard audio drivers can conflict with the video audio support and cause hangs in the graphics drivers)

if you get a power error 41 but no bugcheck, then often it is a power problem. Things like a GPU overheating and using too much power can reset your CPU. In this case you would not see a bugcheck or get a memory dump produced.

if you get a bugcheck on the screen but no memory dump saved then you would have issues with the device the dump is being saved to.

try turning on verifier functions.
start cmd.exe as an admin, then run
verifier.exe /standard /all
then reboot your system

if verifier finds a driver that is doing something wrong, it will call a bugcheck and name the driver name.
you can then use bluescreenview or whocrashed.exe to look at the memory dump and it should name the driver.

Note: use verifier.exe /reset to turn off verifier functions after you are done testing.
if your machine bugchecks during boot, you will have to go into safe mode and turn off verifier.
F8 to get into safe mode (or shift+f8)

Tried the verifier, it gave the BSOD on Windows start. Logged into safe mode, only two files are causing the issue: dxgkrnl.sys and ntoskrnl.exe. If I uninstall my Nvidia driver, the windows boots up fine with the verifier enabled. Without it, I get the BSOD on Windows start (I've reset the verifier functions now). Verifier also started giving me BSOD on Windows start because of Panda antivirus but I uninstalled it and replaced it with Avast and that's working fine.

I don't get the issue, I've stress tested the Nvidia graphics card using 3DMark and Furmark. For at least 30 minutes each (continuously and multiple times) and it didn't get a BSOD. Randomly though, doing anything other than stress testing such as using Microsoft Office, browsing using Chrome, etc., I get kernel-power BSODs. Any ideas?

 

[Zev_07]

if you get a bugcheck on the screen but no memory dump saved then you would have issues with the device the dump is being saved to.

Apart from the dxgkrnl.sys and KMODE_EXCEPTION_NOT_HANDLED bugchecks, I had that problem! The memory dumps weren't always being saved, and sometimes there was a dump but it was 0 bytes so it was useless. I thought it was a problem with Windows. I didn't get a single Kernel 41 power problem while using the verifier though, and I ran it at least a dozen times.

Do you think that the HDD might need to be changed?

 

[johnbl]

verifier does a lot of checking and it can mask timing related bugs because it slows your machine down.

your ssd is very small, is it used for caching the hard drive? if so is there a way to clear its cache?
if you updated to winodows 10 your cache might be filled with outdated files from the previous version of windows. Often the cache will not clear until windows.old is removed or a tool is used to clear the cache.
You can also have firmware bugs in the SSD. you might use crystaldiskinfo.exe and read the firmware version in the smart data and see if there is a update.

if it is a cache problem with the drive you might check the drive properties and disable lazy writes to the drive.
I think you can find it in device manager, find the drive, check for policies and disable write caching .
It will make it slower but might effect your problem. Also, caching a drive that is already being cached by a ssd, and the actual cache memory in the drive is overkill.

I stopped using small SSD cache drives years ago when the cost of SSD fell to a reasonable cost.
these old drives can start failing. (look with crystaldiskinfo.exe for the smart errors)

if you get a bugcheck on the screen but no memory dump saved then you would have issues with the device the dump is being saved to.

Apart from the dxgkrnl.sys and KMODE_EXCEPTION_NOT_HANDLED bugchecks, I had that problem! The memory dumps weren't always being saved, and sometimes there was a dump but it was 0 bytes so it was useless. I thought it was a problem with Windows. I didn't get a single Kernel 41 power problem while using the verifier though, and I ran it at least a dozen times.

Do you think that the HDD might need to be changed?

 

[Zev_07]

The OS wasn't (and isn't currently) installed on the SSD while testing. I was using a 200GB partition for the OS, with more than 140GB free. So there's no reason for it to create 0B dump files. Could it be the HDD?

verifier does a lot of checking and it can mask timing related bugs because it slows your machine down.

your ssd is very small, is it used for caching the hard drive? if so is there a way to clear its cache?
if you updated to winodows 10 your cache might be filled with outdated files from the previous version of windows. Often the cache will not clear until windows.old is removed or a tool is used to clear the cache.
You can also have firmware bugs in the SSD. you might use crystaldiskinfo.exe and read the firmware version in the smart data and see if there is a update.

if it is a cache problem with the drive you might check the drive properties and disable lazy writes to the drive.
I think you can find it in device manager, find the drive, check for policies and disable write caching .
It will make it slower but might effect your problem. Also, caching a drive that is already being cached by a ssd, and the actual cache memory in the drive is overkill.

I stopped using small SSD cache drives years ago when the cost of SSD fell to a reasonable cost.
these old drives can start failing. (look with crystaldiskinfo.exe for the smart errors)

 

[johnbl]

if the dump file was opened but was zero bytes it means the system rebooted before the writes were flushed to disk.
this can happen if the drive is configured for lazy writes, or if there is 3rd party cache software installed, bugs in the SATA controller driver, bugs in the firmware of the drive.

you might go to device manager, right click on your disk drive and bring up properties, then find the tab that allows delayed or lazy writes and disable that function. This will prevent the system from assuming a write is on disk when it could still be in a buffer in memory, it will wait for to confirm the data is on disk and will retry the write operation until it get the proper confirm signal. Very hard to determine the source of the error unless you find a event log error that tells you or run hardware diagnostics.

The OS wasn't (and isn't currently) installed on the SSD while testing. I was using a 200GB partition for the OS, with more than 140GB free. So there's no reason for it to create 0B dump files. Could it be the HDD?

verifier does a lot of checking and it can mask timing related bugs because it slows your machine down.

your ssd is very small, is it used for caching the hard drive? if so is there a way to clear its cache?
if you updated to winodows 10 your cache might be filled with outdated files from the previous version of windows. Often the cache will not clear until windows.old is removed or a tool is used to clear the cache.
You can also have firmware bugs in the SSD. you might use crystaldiskinfo.exe and read the firmware version in the smart data and see if there is a update.

if it is a cache problem with the drive you might check the drive properties and disable lazy writes to the drive.
I think you can find it in device manager, find the drive, check for policies and disable write caching .
It will make it slower but might effect your problem. Also, caching a drive that is already being cached by a ssd, and the actual cache memory in the drive is overkill.

I stopped using small SSD cache drives years ago when the cost of SSD fell to a reasonable cost.
these old drives can start failing. (look with crystaldiskinfo.exe for the smart errors)

 

[Zev_07]

if the dump file was opened but was zero bytes it means the system rebooted before the writes were flushed to disk.
this can happen if the drive is configured for lazy writes, or if there is 3rd party cache software installed, bugs in the SATA controller driver, bugs in the firmware of the drive.

you might go to device manager, right click on your disk drive and bring up properties, then find the tab that allows delayed or lazy writes and disable that function. This will prevent the system from assuming a write is on disk when it could still be in a buffer in memory, it will wait for to confirm the data is on disk and will retry the write operation until it get the proper confirm signal. Very hard to determine the source of the error unless you find a event log error that tells you or run hardware diagnostics.

The OS is installed on the HDD. The SSD has been empty for the duration of testing. I've disable lazy writes though and there are no more 0B dump files.

The problem is, no matter what I do driver verifier is indicating dxgkrnl.sys and nvldmkm.sys as the culprits. I've tried uninstalling the nvidia drivers through the display driver uninstall tool on Guru3D, then clean installing the driver. But that isn't helping either. If I disable/uninstall the Nvidia display adapter, Windows boots just fine with verifier enabled. Does this mean I can no longer install/use my Nvidia GPU?

 

[johnbl]

you have two graphic drivers the intel one and the nvidia one. have you updated the intel driver, then reset the BIOS to defaults so that it will rescan your hardware and assign resources again. Also, make sure you have updated the motherboard sound drivers. They can interfere with the sound support in the 2 graphics drivers you have installed.

verifier can flag problems in drivers that are not the cause of the problem you were having. It just bugchecks on the first problem it finds.

if the dump file was opened but was zero bytes it means the system rebooted before the writes were flushed to disk.
this can happen if the drive is configured for lazy writes, or if there is 3rd party cache software installed, bugs in the SATA controller driver, bugs in the firmware of the drive.

you might go to device manager, right click on your disk drive and bring up properties, then find the tab that allows delayed or lazy writes and disable that function. This will prevent the system from assuming a write is on disk when it could still be in a buffer in memory, it will wait for to confirm the data is on disk and will retry the write operation until it get the proper confirm signal. Very hard to determine the source of the error unless you find a event log error that tells you or run hardware diagnostics.

The OS is installed on the HDD. The SSD has been empty for the duration of testing. I've disable lazy writes though and there are no more 0B dump files.

The problem is, no matter what I do driver verifier is indicating dxgkrnl.sys and nvldmkm.sys as the culprits. I've tried uninstalling the nvidia drivers through the display driver uninstall tool on Guru3D, then clean installing the driver. But that isn't helping either. If I disable/uninstall the Nvidia display adapter, Windows boots just fine with verifier enabled. Does this mean I can no longer install/use my Nvidia GPU?

 

[luk3ZPL]

In my case (W10 x64) helped disable "write caching on disk" in devmgmt.msc \ Disk drives.
BSOD disappear.