BSOD - ekrn.exe

[Rukus 0]

I'm having similar issues. Running Windows 8.1 64bit on a z87 motherboard (Asus Maximus Hero VI) with a 4670k. I'm using their AI Suite III software which includes features like overclocking, direct BIOS updates, and fan profiles. Computer hardlocks with an error that is usually WHEA related shortly after startup (the nod32 icon shows an active scan or update was in progress during this time).

 

With nod32 AV completely uninstalled (or in safe mode) I don't have any freezing, and can run any gamut of hardware tests (prime95, Intel burn, furmark) without any issues at all, so it's definitely not hardware related in that sense. I've had the AISuite software running with nod32 for almost two years, so I'm very curious to see what's actually causing this. Regardless of what version of AISuite I install, the freezing keeps occuring, so I don't think it's a recent update from Asus that's causing it.

 

I'll PM my Log Collector files to Marcos, let me know if you need any additional files. Until then I'll leave nod32 uninstalled.

[Hegge 1]

I have a Gigabyte Z97 Board, the GA-Z97X-UD5H-BK. I also have the App Center installed but disabled its autostart. Have not run it in months.

[shard 0]

I have a Gigabyte GA-Z97MX Gaming 5 motherboard, Intel i5-4590 processor.

[SwansonAssoc 0]

Hi, I have a Gigagbyte GA-Z97-D3H motherboard.  Like several others mentioned, I do not believe I have had Gigabit updates recently.

 

Question, has anyone updated MalWareBytes recently?  I did that on 6/18/15?  That is the only real change I can think of.  (I occasionally run a scan with the free version.)

 

--Robert

[Marcos 5,070]

We're going to contact Gigabyte and ASUS as it turned out the issue is not caused by ESET (we were performing standard process read and memory freeing operations when BSOD occurred). I've been trying to reproduce the issue on a system with a Haswell CPU to no avail though.

As an interim solution, we recommend uninstalling APP Center (Gigabyte) and AI Suite (ASUS) and also encourage you to contact the appropriate vendor of your motherboard.

[grinr 0]

We're going to contact Gigabyte and ASUS as it turned out the issue is not caused by ESET (we were performing standard process read and memory freeing operations when BSOD occurred). I've been trying to reproduce the issue on a system with a Haswell CPU to no avail though.

As an interim solution, we recommend uninstalling APP Center (Gigabyte) and AI Suite (ASUS) and also encourage you to contact the appropriate vendor of your motherboard.

 

You can appreciate that uninstalling the software we use to manage our computers is not an ideal solution.  Installing alternative AV products is a far more likely alternative.  Do you have any of the motherboards available that have been mentioned (Z97 chipset) that you can test with to see if uninstalling the system software actually works?  Can you identify what the conflict is?

 

If the solution you're proposing is to QA software, especially system software, I'll reluctantly have to pass and select a new AV solution.  It's my hope we can encourage ESET to investigate what the conflict is and resolve it from their end.

[Marcos 5,070]

If the solution you're proposing is to QA software, especially system software, I'll reluctantly have to pass and select a new AV solution.  It's my hope we can encourage ESET to investigate what the conflict is and resolve it from their end.

 

The crashes were caused by a hardware failure, ie. they couldn't have been caused by ESET. The fact that the crash doesn't occur with ESET installed doesn't mean that your system will be ok after uninstalling ESET as ESET acts only as a catalyst of the issue. The crash may return randomly in the future as long as the problematic software mentioned above is installed. It's in the interest of both ESET and Gigabyte and ASUS to work on the issue and fix it, otherwise the users will remain at risk no matter if ESET is installed or not (there are many examples when the mentioned software caused a crash and the users didn't have ESET installed).

[grinr 0]

 

If the solution you're proposing is to QA software, especially system software, I'll reluctantly have to pass and select a new AV solution.  It's my hope we can encourage ESET to investigate what the conflict is and resolve it from their end.

 

The crashes were caused by a hardware failure, ie. they couldn't have been caused by ESET. The fact that the crash doesn't occur with ESET installed doesn't mean that your system will be ok after uninstalling ESET as ESET acts only as a catalyst of the issue. The crash may return randomly in the future as long as the problematic software mentioned above is installed. It's in the interest of both ESET and Gigabyte and ASUS to work on the issue and fix it, otherwise the users will remain at risk no matter if ESET is installed or not (there are many examples when the mentioned software caused a crash and the users didn't have ESET installed).

 

 

Ah, true, the multitude of possibilities is what keeps us on our toes.  Anything could potentially cause a system crash randomly in the future.  What is currently known, however, is that the systems reported on here today have Z97 chipsets from two different manufacturers (who naturally have different system software) and seem to have been fine for many months without issue.  We also know that removing ESET solves the problem of persistent BSODs.  We also know that installing alternative AV does not cause persistent BSODs.

 

That said, I certainly agree that a discussion is merited between the various companies to sort this out.  As I cannot be without AV protection, and will not be without system software, I have no choice at the moment but to use an alternative AV solution until you all sort it out.  As a die-hard ESET customer, that's a painful conclusion to arrive at and I will be keeping an ear to the ground for word of when it may be safe to use ESET again.

[Cyda 0]

The crashes were caused by a hardware failure, ie. they couldn't have been caused by ESET. 

 

And yet the problem is easy fixed by uninstalling the ESET software, so the hardware suddenly fixed it self? This system has been solid as a rock for 12 months and the first & only crash is cured by removing NOD32, don't try to tell us that it is not the cause of the problem. Yeah, blame it all on our systems.

I must say, since your very first comment to the OP, your attitude stinks. I am due to renew the mutiseat licence for NOD32 at the company where I work, and I think you're attitude has me wondering if I should look elsewhere for my AV protection.

Edited June 23, 2015 by Cyda

[Marcos 5,070]

And yet the problem is easy fixed by uninstalling the ESET software, so the hardware suddenly fixed it self? This system has been solid as a rock for 12 months and the first & only crash is cured by removing NOD32, don't try to tell us that it is not the cause of the problem. Yeah, blame it all on our systems.

The fact that uninstalling ESET makes the problem go away doesn't mean that ESET is actually the culprit; we've seen it numerous times in the past. Analyzing the dumps revealed that there's definitely an issue with the 3rd party software that is causing it and ESET is just innocently involved as a catalyst. It is a matter of fact ESET was not performing any non-standard operations when the crashes occurred . Moreover, if you google for "gigabyte bsod -eset" you'll get more than 600 000 results of BSOD issues connected to Gigabyte that are not related to ESET.

Below is the outuput from debugger. There's no chance that ESET's drivers could cause a hardware failure which is shown in the dumps:

 

WHEA_UNCORRECTABLE_ERROR (124)

A fatal hardware error has occurred. Parameter 1 identifies the type of error

source that reported the error. Parameter 2 holds the address of the

WHEA_ERROR_RECORD structure that describes the error conditon.

Arguments:

Arg1: 0000000000000000, Machine Check Exception

Arg2: fffffa800f693028, Address of the WHEA_ERROR_RECORD structure.

Arg3: 00000000be000000, High order 32-bits of the MCi_STATUS value.

Arg4: 0000000000800400, Low order 32-bits of the MCi_STATUS value.

 

As I have already stated, we are going to contact the makers of the software and offer them our assistance in troubleshooting and fixing the issue. We'll keep you updated.

[grinr 0]

Thanks Marcos for the feedback, it is appreciated.  

[Erik R 1]

Could somebody else confirm that you have a motherboard with z97 chipset too? I wonder if that's the common denominator as it's been users with Gigabyte motherboards affected so far.

 

EDIT: I'm running a Maximus VI with a Z87 chipset. Not a VII with the Z97 as originally stated.

 

I'm running an Asus Maximus VI Formula which has the z87 chipset. I'm experiencing this issue as well. I have Asus AI Suite 3 installed, but it's an old version and hasn't been updated in months. (Maybe a year or more??)

 

Just curious why software that has been on my computer for a year and a half and not updated for many months suddenly started causing a conflict with ESET this week?

 

I'm running ESET NOD32 v7.x on Windows 8.1 Pro 64bit with Media Center.

 

(I have tried installing NOD32 v8.x but there is an issue with my Ceton InfiniTV CableCARD tuner that neither Ceton nor ESET have been able to resolve. Hence, why I'm still running v7.)

Edited June 24, 2015 by Erik R

[grinr 0]

Update:

 

After uninstalling NOD32 AV, I tried installing BitDefender.  BSOD, same error:

 

Stop 0x00000101 "A clock interrupt was not received on a secondary processor within the allocated time interval"

 

So, this made me curious and I decided to update my AI Suite software (as per Marcos' suggestion.)  The newer version from Feb 2015 got halfway through and blew up on the USB driver install - BSOD again, this time a different error that disappeared too quickly for me to see it. Booted to Safe Mode, windows logs were not helpful so I tried rebooting to Normal mode.  BSOD again, this time showing "asmtxhci.sys" as the culprit.  Back to Safe Mode and looked it up - it's the Asmedia USB driver.  As I couldn't get back to normal mode because of insta-BSOD on login, I ran a system restore to before the AI Suite installation.  That worked and I got my desktop back.  So I download the latest driver for Asmedia USB (v116230) install it without issue, then try installing the AI Suite again.  This time, no crash, no problem.

 

I tried again to reinstall BitDefender.  No problem, installed fine.  Uninstalled it and tried to reinstall ESET NOD32 AV.  It fails but because it didn't uninstally properly, so I get the uninstaller app and deal with that.  Reboot again and install NOD32 AV without issue.

 

30 minutes and so far so good.

 

I hope this is helpful.

Edited June 24, 2015 by grinr

[Hegge 1]

Update from me:

 

After reading grinr's post i did a update of all motherboard drivers and the Gigabyte App Center and reinstalled Nod32 (from the same offline installer dated 22th June that caused the error before) and now the problem seems to have vanished. 30 minutes and counting and no BSODs.

 

Thanks grinr and Marcos. =)

[grinr 0]

Update from me:

 

After reading grinr's post i did a update of all motherboard drivers and the Gigabyte App Center and reinstalled Nod32 (from the same offline installer dated 22th June that caused the error before) and now the problem seems to have vanished. 30 minutes and counting and no BSODs.

 

Thanks grinr and Marcos. =)

 

Glad it helped.  I'm curious about what exactly changed (and when) that caused this to "spontaneously" occur.  An update to ESET? An update to the system software (APP center, AI Suite)?  Windows update?

 

Why would USB driver update (for me) resolve the issue?  I've been trying to isolate this but with no success.

[JamesR 52]

Hello,

 

For any Gigabit users recieving BSOD's, can you try the following to uninstall System Information Viewer from Programs/Features?  System Information Viewer will be labeled as SIV.

 

Steps for those with ESET already installed and recieving BSOD's:

 

1. Boot to Safe Mode

2. Open an administrative command prompt and run the following 2 commands to allow unisntalls (we will undo this later):

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" /VE /T REG_SZ /F /D "Service"
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer" /VE /T REG_SZ /F /D "Service"

3. Navigate to "Control Panel" then "Programs and Features"

4. Locate SIV and uninstall it

5. Back in your administrative command prompt, run the following 2 commands undo what was done in step 2

REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer"
REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer"

6. Reboot your computer and verify if all is well.

 

 

Steps for those who do not have ESET installed:

 

1. Navigate to "Control Panel" then "Programs and Features"

2. Locate SIV and uninstall it

3. Install ESET and update

 

 

If this works to resolve the issue, please reply to this post.

[Erik R 1]

Asus Maximus VI Formula z87 motherboard....

 

Tried updating all the Asus software and motherboard drivers. Still crashed within a few minutes of logging onto Windows. Removed Asus AI Suite 3 and all of its components and everything seems fine.

[grinr 0]

Asus Maximus VI Formula z87 motherboard....

 

Tried updating all the Asus software and motherboard drivers. Still crashed within a few minutes of logging onto Windows. Removed Asus AI Suite 3 and all of its components and everything seems fine.

Do you know what version of AI Suite was installed?

[Marcos 5,070]

We have likely found the cause of the issue in software that directly accesses hardware ports and does mapping in a way that we think is not correct and also according to Microsoft in scenarios when also another driver does mapping in a recommended way this may lead to unpredictable system results. We have made a workaround in Antivirus and antispyware protection module 1162 (currently available on pre-release servers and for all v9 beta users) to prevent this from happening when such drivers are installed.

 

Please confirm or deny that the issue is fixed with Antivirus and antispyware protection module 1162.

 

Should the problem persist, please supply us with a new memory dump (compress it before uploading). Also carry out the following test, if possible:

- uninstall v8 and restart the computer

- install v8 but don't activate / update it

- disabled Advanced memory scanner in the advanced setup -> HIPS

- restart the computer

- update v8

- let us know if disabling AMS solves the issue.

[filip.maliarik 0]

Hello Guys,

 

In one of our cases reported from other source, it seems that SIV (shown as “SIV” in System Installed Software in SysInspector) application is responsible for the crashes.

Can you try to uninstall it from the system temporarily and check, whether BSOD stops to occur?

[bilabong007 0]

Can confirm that uninstall of siv solves it

[Rukus 0]

We have likely found the cause of the issue in software that directly accesses hardware ports and does mapping in a way that we think is not correct and also according to Microsoft in scenarios when also another driver does mapping in a recommended way this may lead to unpredictable system results. We have made a workaround in Antivirus and antispyware protection module 1162 (currently available on pre-release servers and for all v9 beta users) to prevent this from happening when such drivers are installed.

 

Please confirm or deny that the issue is fixed with Antivirus and antispyware protection module 1162.

 

Should the problem persist, please supply us with a new memory dump (compress it before uploading). Also carry out the following test, if possible:

- uninstall v8 and restart the computer

- install v8 but don't activate / update it

- disabled Advanced memory scanner in the advanced setup -> HIPS

- restart the computer

- update v8

- let us know if disabling AMS solves the issue.

 

My system (Asus z87) still crashes following these steps. I'll pm you the Log Collector file.