KMODE EXCEPTION NOT HANDLED

[MrTom]

---

@SaltyLager wrote:

I had a few systems doing this exact issue. First round I ended up wiping and doing a fresh install. Despite deferring updates into June, it came back on one system. One of the threads mentioned the bug check check indicated an issue with windows defender and the kernel.

So I figured out how to disable windows defender from the recovery console and broke out of the boot loop.

Go to troubleshoot - advanced options - command prompt.

Login with your password

In the command prompt enter regedit and press enter.

Double-click hkey local machine

Click file - load hive

Browse to C( was D in my recovery environment):\windows\system32\config

Open software

Enter a Key Name, I used temp

Open the temp key, then expand policies - Microsoft - windows defender

Create a 32bit dword DisableAntiSpyware. Set it to 1

Right click windows defender in the left and create a new key Real-Time Protection and create these 32 bit dwords set to 1

DisableBehaviorMonitoring

DisableOnAccessProtection

DisableScanOnRealtimeEnable

Scroll back up and highlight the temp key, and then click file unload hive.

Then highlight hkey local machine again, and choose load hive. This time load system from the same location, and set 

Temp\contolset001\services\windefend start to 4

Hopefully someone can clean  these instructions up and add screenshots for the less skilled 

---

Well, came in this morning and now the DT was BSODing immediately after the login prompt showed, and not after 10 minutes anymore like yesterday.

I booted into the recovery environment and loaded the registry hive as you mentioned. I changed the Microsoft\Windows Defender keys DisableAntiSpyware and DisableAntiVirus to 1. Now I'm able to boot into Windows 10. I've had the system powered up for 40 minutes now and no BSOD. So for me at seems disabling Windows Defender did the trick and got me out the BSOD boot loop.

[Ferrumic]

I've now disabled Defender both by the registry tweak, and also turned it off in gpedit. I made the mistake of trying to download my paid Avast, in order to reinstall it, before rebooting after the registry changes, and the machine crashed.

This workaround is great (fingers crossed), but in my view the precise source and cause of this problem needs to be identified by HP and Microsoft. I do not like disabling things for no known good reason, and it's almost certain that this rigmarole will be necessary every time there are W10 Feature updates, and possibly cumulative ones as well.

It's ironic that to make a system run, it's necessary to remove core security features (however good or bad they may be). I had planned to run the Windows security stuff, together with Malwarebytes Premium, but that isn't going to work, unless the root cause of this is identified and remedied.

[philip42h_2]

---

@Ferrumic wrote:

...

This workaround is great (fingers crossed), but in my view the precise source and cause of this problem needs to be identified by HP and Microsoft. I do not like disabling things for no known good reason, and it's almost certain that this rigmarole will be necessary every time there are W10 Feature updates, and possibly cumulative ones as well.

...

---

+1 for that

It seems to me that there are multiple elements involved in this issue and that we have two or more incompatible software components conspiring to cause the symptoms experienced:

• There is an issue with a Windows Update delivered late April or early May. This could possibly be the recent Windows Defender platform upgrade since disabling Defender allows folk to get past the boot loop. There again, I have had version 4.18.2004.6 running on my Envy for over a week now without issue.
• It seems, to me, certain, that HP core software, possibly drivers, are complicit in the issue. Looking around the web there appears to be plenty of cases of failing HP kit and relatively few from any of the other major manufacturers. I rather suspect that an HP supplied driver that worked just fine before the recent Windows updates is now proving to be incompatible with these updates.

It is about time that HP took an interest in this thread and formally acknowledged the issue ... 😉

I note also that there were a couple of replies overnight (I'm in the UK) from cultlife and lucasy_81, basically recognising the value of SaltLager's workround, have been 'moderated' into an entirely new thread - this sort of action really doesn't help anyone.

[philip42h_2]

---

@philip42h_2 wrote:

...  I installed the Intel Rapid Storage Driver - 17.5.2.1024 Rev.A, Feb 11, 2020 from HP Support and have been running for three or four hours without any problems. It's way too soon to count chickens but I'll post back when it all fails or I take the next step! 🙂

---

The Intel Rapid Storage Driver has now been running for 24 hours so I start adding back the Realtek drivers starting with the Bluetooth Audio driver.

[I'm torn between adding them all in one go - to show that they all now work (?) - or adding them back one at a time so as to have the best opportunity of identifying the 'culprit']

[Ferrumic]

I'm not sure about which of the Windows updates, if any, may be involved. My BSODs started on 1st May, and before that, according my update history, I installed Cumulative KBs 4551762 and 4549951 on 13th and 16th April respectively. The last Defender platform update installed here was KB4052623, for version 4.18.2001.10. I haven't seen anything for 4.18.2004.6, which I presume was a separate update, and the last Cumulative for 2020-5 I have installed is KB4556799, which, after a couple of tries, arrived on 14th May; 2 weeks post-first BSOD.

In other words, the timings don't seem to fit the pattern of occurrences, given the delays between installation and beginning of KMODE BSODs.

As far as HP software is concerned, I haven't (knowingly, at least) downloaded anything via HP Assistant or off their website since the V 40 BIOS update in February. The last driver listed here via Windows Update is a Realtek Bluetooth driver, but that's January 2020. Nor have I been going through Device Manager for driver updates, and, if memory serves, I don't remember seeing anything that could be easily related back to HP.

As you say, it does seem to be tied to HP software in some way, and they really ought to "remove the digit" and at least respond here. I've been looking through possible ways of shaking their tree to get some action, but I can't see anything helpful at the moment.

[philip42h_2]

Ferrumic,

The hypothesis - and that's all it is so far - is that the fault arises because two or more pieces of software are incompatible - each may work perfectly well in isolation but they don't play well together ...

That means that any of the existing HP software items from say 2019 /2020 could be implicated. They worked just fine with Microsoft Windows software released prior to patch Tuesday, April 14 2020 but not in the context of software contained with that release or released subsequently.

I had my first incident with KMODE EXCEPTION NOT HANDLED on or about the 6th May and this was 'easily' resolved by rolling back to a restore point from the 5th May - that's not to say that the issue didn't already exist in my system on 5th May without being apparent; equally it could have 'arrived' with an early morning update applied on 6th.

The fault rapidly went 'hard' for me on 9th May when I foolishly applied the 2020-04 Cumulative Update for Windows Version 1909 for x64-based Systems (KB4549951). I believe that doing this wiped out earlier restore points.  I note that Microsoft acknowledge "We have seen social media reports related to KB4549951 that mention Bluetooth, a stop error with a blue screen, and other related issues." This may, or may not, have anything to do with our experience.

I note also that there was an Update for Microsoft Defender antimalware platform KB4052623 originally released on 1st May (based on the Google search date) but last updated by Microsoft on 12th May. This impacts versions 4.18.2004.6 and 4.18.2001.10 of the Defender platform. It seems perfectly possible, given all the evidence gathered so far, that this update could be implicated.

But I'm now running Windows based on the patch Tuesday, May 12, 2020 cumulative update - which may, or may not, contain the incompatible code sets. I don't know. But I'll continue to investigate until either I can better localise the fault or convince myself that there's no remaining fault to be found! Either way, I won't die in a ditch to defend the hypothesis ... 🙂

[alexgogan]

Hi Philip42h_2

Sorry missed your question, on 14th I got the first boot, (i answered this a little later but not directly to you). And I stupidly uninstalled the last feature update via the Troubleshooting Options. BTW I had version of Bit Definder on the machine, but I have removed that and now have Sentinal One instead.  I have also enabled full disaster recovery so I can roll back to any state I want to know.

But because I rolled back the Latest Feature instead of the last Updated things were not stable and I had the offending update still there. My machine did not feel well all day and I knew I was going to have to wipe and restart, but Firday morning I was greated not with Hello, but f..u.. BSOD so kind of distoryed Friday, I stupidly tried eveything possible, then gave up and contacted HP support, (they were helpful), downloaded the image for the PC from their site and havything is back the way it should be.... Ok data, did not back up my email filters (still crying with the Trumpian Twitter feed that is my inbox without filters.

Regards

Alex

[Ferrumic]

Philip42h_2

It's a real bind, but, as you say........!

The Cumulative KB4556799 has been on here since 14/5, and I've had BSODs both before and after. I agree that whatever it is has probably been lurking in the system for some time, prior to "activation".

At the moment, I've changed my Macrium imaging a bit to try to safeguard this. I've always kept some rollback images made monthly, but they're not a lot of use if they contain something deleterious which will in time be activated by something else; as seems to have happened here. The only way of dealing with that after going backwards in time, is to enter a state of suspended animation, in which nothing Microsoft can be updated, lest it screws things up. That's not a starter, either.

As giving Defender the chop seems to have been one way of dealing with this, it would make sense that it's one part of the problem. How to identify other factors is a real conundrum, especially if you need the machine for work, rather than fault diagnosis. I suppose one possible way of approaching it, is to replicate the system as a virtual machine, enable Defender and plough through the drivers and software, but I think that's a large undertaking.

Again, it would be helpful if the manufacturer were to make some effort to address this problem, or at least, acknowledge and comment on it.

[alexgogan]

Again, it would be helpful if the manufacturer were to make some effort to address this problem, or at least, acknowledge and comment on it.

I just reached out to HP support to take a look at this thread so hopefully they will get more involved.

[Ferrumic]

@Alexgogan,

Thanks for the update. I hope they do get stuck into this ASAP,  as it really needs to be sorted.