Jump to content

Era agent 6.2.11.0 causing computers to freeze


Recommended Posts

  • ESET Insiders

This seems strange.

I have just tried to install the it on a fully updated Win7 X64 SP1 system, and I have not seen the message you suggests.

Link to comment
Share on other sites

You tried to install 64bit package on 32bit system and 32bit on 64bit OS, right? This might be reason for error "The update is not applicable to your computer", only other reason I can think of is that it is distributed by MS already and should be visible in the list of installed packages... Weird anyway.

Edited by martyz
Link to comment
Share on other sites

  • ESET Insiders

Hi everybody

 

I have heard from our local Eset team, that they are actively working to fix this issue, and have just received a potential fix for testing.

 

So it seems that things are not as bad as the Eset team reports in here.

Link to comment
Share on other sites

  • Administrators

Although there is a potential workaround in ERAS, it's important to remember that it's a bug in Windows Filtering Platform that can manifest at any time as long as protocol filtering is enabled and http communication is scanned. The more CPUs or cores a computer has installed, the higher probability that the issue will manifest. The workaround in ERAS is meant to minimize the chance that the issue will occur due to ERAS communication but there's nothing that could be done in protocol filtering to prevent issue and installing the hotfix will still remain the only 100% solution.

Link to comment
Share on other sites

  • ESET Moderators

Hello rekun, I sent you a PM - if you are interested in trying out the potential fix in your environment, you can respond to it and I will send you the necessary files.

Thanks

Link to comment
Share on other sites

  • Administrators

Windows Server 2012 should already address the bug in Windows Filtering Platform that causes the issue. Windows 2003 does not use Windows Filtering Platform whatsoever. We have made an experimental dll that doesn't utilize a full-duplex communication (performance improvement) and thus prevents the bug in WFP from manifesting.

Link to comment
Share on other sites

We are using Windows 7 x64 w/SP1 and all updates installed and receive the message "This update is not applicable to your computer".   I did download the correct x64 hotfix

Link to comment
Share on other sites

Is anyone else able to comment on whether this new agent version fixes the freezing or as like rekun above still having the same issue?

We have Server 6.2.171.0 and Agent 6.2.190.0 installed and we are still experiencing the freezing issue.  We have not yet deployed the hotfix.

Link to comment
Share on other sites

Are you sure the hotifx isn't already installed?

 

I've just started a roll out to 150 machines for one of our existing customers migrating to Eset and during my pre-installation check found that 35 of the PCs already had the hotfix installed!

 

I'm trying to work out now how they got it installed, maybe it comes with some other software, we wouldn't have installed it before because before Eset we weren't aware of the hotfix existing!

Link to comment
Share on other sites

The hotfix is not installed in my case and yet I'm not able to install it. I'm running a correct version of the hotfix ("Windows6.1-KB2664888-v2-x86.msu" on a 32bit system and "Windows6.1-KB2664888-v2-x64.msu" on a 64bit system), but very time getting "The update is not applicable to your computer" error. About my system:

 

C:\>systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
OS Name:                   Microsoft Windows 7 Professional
OS Version:                6.1.7601 Service Pack 1 Build 7601
 
C:\>wmic qfe | find "KB2664888"
 
C:\>wmic qfe get hotfixid | find "KB2664888"
 
C:\>

 

As you can see, it's a Windows 7 SP1 machine, it doesn't have the hotfix installed but the hotfix doesn't want to install. I tested on a few machines and getting the same results everywhere.

 

Could ESET or anybody who managed to install the hotfix, run the above commands on the computer where the hotfix was installed and post here the output as well as full file name of the executable that was used to install the hotfix, please?

Edited by terrum
Link to comment
Share on other sites

No issues here.  Pushed it to the affected clients from ERA using Martyz's command line.

 

C:\>wmic qfe | find "KB2664888"

hxxp://support.microsoft.com/?kbid=2664888    COMPUTERNAME  Hotfix                        KB2664888               DOMAIN\USER              10/27/2015                                      

 

C:\>wmic qfe get hotfixid | find "KB2664888"

KB2664888  

 

Installed from:

Windows6.1-KB2664888-v2-x64.msu

 

So far, it appears the hotfix has addressed the freezing issue in our environment.

Link to comment
Share on other sites

According to the kb, hotfix updates netio.sys to 6.1.7601.21991 (on SP1, x64). On my system the version is higher - 6.1.7601.22648, so I guess this is why the hotfix won't install. Most likely at some point another update has installed this newer version of the file. I don't see the freezing issue in my environment as well.

Link to comment
Share on other sites

Here is what I have done to alleviate the problem

1. Run M$ Hotfix KB2664888

2. Restart Machine

3. Update ESET Agents to 6.2.190.0

4. Update ESET Endpoint to 6.2.2021.0

 

What does the patch do?

It updates the file netio.sys

 

What was causing the freezing?

When the ERA agent was upgraded to 6.2.200.0, the new version incorporated a different kind of API.

This new API on the server end has a fatal communication issue with client Windows 7 PCs running an old version of NETIO.SYS.

NETIO.SYS is a Windows device driver located in C:\Windows\System32\drivers folder.

It is used to support Windows hardware device driver Network I/O subsystem. 

 

The ESET agent on the PCs make use of the NETIO.SYS driver when communicating over the network.

NETIO.SYS has a function within called FwpsStreamINjectAsync.

This function injects TCP data segments in a TCP data stream. 

The theory is that FwpsStreamInjectAsync doesn’t work with the new API on the server, and when communication occurs between the server and PC, that function on the PC issues a IRQ (interrupt request) that is handled by the APIC (Advanced Programmable Interrupt Controller) for CPU which stops running program to allow, say communication of data from NIC card to get CPU time. 

We don’t know exactly what operation is issued to the function that caused problems, perhaps a divide by zero or something that causes the IRQ to leak and lock system.

 

 Once you apply the patc​h (AND RESTART THE PC!) the netio.sys file will be updated (date should be 4/4/2014, version 6.1.7601.22648)

 

.

 

We have had no issues a​fter that.

 

Good Luck

I only have 500 more to​ patch.

Link to comment
Share on other sites

jimwillsher:  both mine and my "freezing" test computer have that update (KB2957189) installed, but my version is 6.1.7601.22648 and the test client is 6.1.7601.18327

 

Also, when I run "wmic qfe get hotfixid | find "KB2664888"" it does not find that this hotfix has been installed.

Edited by sksksk
Link to comment
Share on other sites

Thank you, that's the answer to my question!

 

 

jimwillsher:  both mine and my "freezing" test computer have that update (KB2957189) installed, but my version is 6.1.7601.22648 and the test client is 6.1.7601.18327

 

Also, when I run "wmic qfe get hotfixid | find "KB2664888"" it does not find that this hotfix has been installed.

 

You don't see anything in return to "wmic qfe get hotfixid | find "KB2664888"", because the hotfix is actually not installed!
 

According to the KB, two service branches exist - GDR and LDR, perhaps for some reason, your first computer got the LDR version of the netio.sys and the second computer got GDR, though I have no idea why would that happen. What you can try now is uninstall 2957189 from the second computer and re-install it again. Or, if that makes no difference, after you uninstalled 2957189, get the 2664888 hotfix installed first and only then re-install the 2957189. This is just a guess, it may or may not help to update netio.sys on your test client to 6.1.7601.22648.

 

Oh, and don't forget to take a full backup of you system before you start :)

Link to comment
Share on other sites

Typically, you get GDR updates from Windows Update, and you get LDR updates when you go rummaging for specific hotfixes. In other words, LDRs are fixes that may not be fully tested but which are there to fix specific problems.

 

Think of it as LDR being hotfixes and GDR being "general windows improvement" fixes that come periodically via Windows Update as Optional Updates.

Link to comment
Share on other sites

hi,

 

a fix on the ERA server could fix freeze an all era agent on computer and server ? or i didn't understant what to do with the dll or so file ?

 

thank you,

Link to comment
Share on other sites

This issue should have been clarified to all users before they updated ERA instead of nonchalantly stating it should be installed on the Remote Administrator Server in the Setup Guide.

 

Anyway this is what we used to Push the Hotfix:

hxxp://itaudiotech.blogspot.com/2013/05/how-to-deploy-microsoft-hotfixes.html

some of the details are wrong but it works. Setup for x86 and x64 if needed. Creates long initial boot times and requires 3 reboots, 1) deploy variable, 2) install update, 3) reboot after update installed. Suppose you can push before variable and eliminate one reboot.

 

After the Hotfix is installed do this command from Powershell to verify installation of fix:

 

PS x:\> get-hotfix  -id kb2664888

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...