windows 10 spring update

[WhiskeyRiver 1]

UPDATE: I have disabled HIPS on one of the 32-bit machines. It didn't immediately fail but the jury is out. It may take several hours before we know if that's the problem. If it hasn't failed in a few hours then I will leave it overnight and post again tomorrow.

[itman 1,799]

"My gut" is telling me that Microsoft somehow changed Win 10 memory compression in the 1803 Upgrade; especially in regards to x(86) version. My old motherboard never supported Win 10 memory compression from Day 1. Never been impacted by lack of it and as a result, never thought about it much. I do however run x(64) OS with 8 GB of RAM.

I suspect that NOD32 is somehow being negatively impacted by these possible memory compression changes. One way to find out is to disable memory compression and see if the NOD32 problems permanently go away. You do so by opening an admin level PowerShell window and entering the following command:

• Disable-MMAgent -mc

To reenable memory compression enter:

• Enable-MMAgent -mc

Disabling memory compression will now force Win 10 to use the page file instead.

Here's a reference on Win 10 memory compression: https://www.makeuseof.com/tag/ram-compression-improves-memory-responsiveness-windows-10/ . When the author benchmarked system performance w/memory compression disabled, the impact was for all practical purposes none.

-EDIT- BTW, SuperFetch service is running on my build. So no need to disable it per the article instructions if the PowerShell method is used to disable memory compression.

Edited May 10, 2018 by itman

[WhiskeyRiver 1]

Had not thought of that. If that's the problem it explains an awful lot about 1803 32-bit issues. I have other clients having similar problems with other antivirus products. They're the very few that don't take my advice. lol

I'm going to single out another 32-bit machine and disable memory compression. I'm going to leave the HIPS disabled one alone so I can report both results.

Thank you itman. I got a feeling you're awesome.

[itman 1,799]

Also there is a way "to break" the 4 GB RAM limit on Win 32 bit OSes. I can't vouch for it since I never used it. Of note is the article doesn't specifically mention Win 10 but does mention 8.1. Also, only those with advanced technical skills should attempt it:

https://www.makeuseof.com/tag/unlock-64gb-ram-32-bit-windows-pae-patch/

-EDIT- Yes, the patcher was updated for Win 10: http://wj32.org/wp/2016/02/01/pae-patch-updated-for-windows-10/

Edited May 10, 2018 by itman

[WhiskeyRiver 1]

Yeah.... That trick's been around awhile. Later editions of Windows Server  2003 had the address extension installed by default. In my situation, these are older Core Duo machines with 4GB of RAM installed so that's all I have to work with. They work just fine for the job they do so as long as I can run them I will. They all have nice Samsung 850 Evo drives and they're mostly only used for Jr. Exec's mobile email and the rest for Auto techs to run vehicle diagnostic suites. Trust me when I tell ya those mechanics can tear up anything you give them. Even Toughbooks.

Edited May 11, 2018 by WhiskeyRiver

[WhiskeyRiver 1]

So.... Disabling HIPS seems to stop the errors. Not a very desirable fix.

What I've done now is taken Nod32 back to the retail update channel and disabled the Superfetch service. I just didn't have time to screw with it so I took the easy way to disable the memory compression. If that yields a positive result then I'll turn the service back on a disable the memory compression.

These old machines sure boot like a slug with Superfetch turned off.  We're partying like it's 1999. lol

[Marcos 5,443]

It should be enough to temporarily disable protected service in the HIPS setup. By disabling HIPS completely, you also disable self-defense, Advanced Memory Scanner, Exploit Blocker and Ransomware shield.

[itman 1,799]

I stand corrected. My PC is indeed using memory compression. Appears Microsoft no longer controls it via System process. Hence, Process Explorer shows it as a hardware device malfunction. Only way to view its particulars is via Task Manager - Performance tab:

 

Ref.: https://www.howtogeek.com/319933/what-is-memory-compression-in-windows-10/

Adding up Commited + Cached memory = 3.4 GB. Currently the only non-Microsoft apps I have running are Eset IS ver. 11.1.54 and IE11. Of note is Eset(ekrn and equi) is currently using 85 MB but peak usage shows 300 MB per Process Explorer. Also, only 6.4 GB or 8 GB of memory is available for use; or 80%. On a device with 4GB of memory that means only 3.2 GB is accessible.

So it may very well be that Win 10 x(86) 1803 Upgrade is the culprit.

Edited May 11, 2018 by itman

[WhiskeyRiver 1]

Oh, 1803 IS the culprit. These machines all worked fine (I hear everyone laughing) on v1709. I just did all the Windows Updates on the toilet so I didn't cr*p my pants.

Edited May 11, 2018 by WhiskeyRiver

[WhiskeyRiver 1]

The results are in on disabling Superfetch. Virus scanner failed overnight. So I'm just gonna go with Marco's last suggestion. The only answer seems to be in manipulating HIPS. I may just fall back to 6.1.7601 on these 32 bit machines and shut off all the updates. Microsoft keeps defeating all my telemetry tricks.

 

[itman 1,799]

I will also add that my posted Win 10 1803 memory usage is not atypical of a stock installation since I have disabled most of Win Store background processing via System Settings options. Ditto for Win 10 telemetry activities. So that could be another option for x(86) users to explore; disable as much as possible in non-core OS processing.

There is still one overriding question however. It appears only NOD32/Endpoint x(86) users are being affected and not Internet/Smart Security users?

Edited May 11, 2018 by itman

[WhiskeyRiver 1]

I don't know but that's an interesting question. I couldn't change these machines that run the automotive apps though. It doesn't take much to interrupt the communications between the computer and the hardware interface for something like Ford IDS. These devices are almost stone-age technology. You might think that your new car is the latest in technological wizardry and I suppose to some degree it is. The actual link between these devices and the vehicle ends up being RS232 running 9600 baud. It's almost as ancient as POS support where a substantial number of card-swipe devices still connect to PS/2 connectors. I support a lot of those installations too.

Oh... I forgot. I only use local accounts. I've never even looked into background processing for the Win Store on those. But I'm going to in a few minutes. 

Edited May 11, 2018 by WhiskeyRiver

[voyageur2180 0]

I think is about time to the company take the problem and résolved…………...I have other thing to do……………

 For now  I will use windows defender.till Eset found the problem.

 

[itman 1,799]

Another possible temporary fix with obvious system processing performance impacts are listed below:

A description of the 4 GB RAM Tuning feature and the Physical Address Extension parameter

https://support.microsoft.com/en-us/help/291988/a-description-of-the-4-gb-ram-tuning-feature-and-the-physical-address

Gigabyte Tuning: BCDEdit and Boot.ini

https://msdn.microsoft.com/en-us/library/bb613473.aspx

 

 

[WhiskeyRiver 1]

Wouldn't these security products be running in the 2GB reserved system area? And wouldn't reducing that area to 1GB exasperate the problem? I don't know, just asking?

[itman 1,799]

2 hours ago, WhiskeyRiver said:

Wouldn't these security products be running in the 2GB reserved system area? And wouldn't reducing that area to 1GB exasperate the problem?

Ekrn and ekrnEpFw(driver) are session 0 processes. As such, I believe your statements are correct.

I did notice something about ekrn.exe that is of interest - its high page fault count:

I believe these are what is referred to as "soft" faults:

Quote

A Soft Page Fault happens when a process requests a page which is not located within it's working set, AKA the range of addresses available to the process. The page is usually sitting in RAM as part of the "standby" list in Task Manager (cached files).

https://superuser.com/questions/1219219/page-faults-strange-memory-behavior-and-page-files-particularly-but-not-speci

The only other process running that has page faults in this range on Win 10 1803 is dwm.exe. Which BTW is also a memory hog with physical memory usage peaking at 344 MB. Assuming both ekrn.exe and dwm.exe both peak out at system start up time, close to 700 MB of memory is being used by just those two processes.

 

Edited May 11, 2018 by itman

[itman 1,799]

Here's an idea.

Open up Windows Defender Security Center -> Exploit Protection -> Program Settings. Add a rule for ekrn.exe and disable Bottom-Up ASLR in it. This will prevent allocated memory location randomization for it.

See if this stops the NOD32 hang-ups.

[WhiskeyRiver 1]

I have the security center disabled with a registry entry on this particular machine (Home Edition.) And just to make sure, I deleted the run key and then set the service startup to 4 in the registry. I could roll it back but I don't want to. I rather like where I'm at with Nod32 and Malwarebytes Pro on these machines. It's easier on the Windows Pro machines with group policy but even then I delete the run key and set the service startup to 4 in the registry. I kinda like controlling my own destiny. Yeah, I can hear the laughter in the background - Nobody really controls their own destiny with Windows 10.

Edited May 11, 2018 by WhiskeyRiver

[itman 1,799]

@Marcos, here is something else for Eset to check-out.

In my Win 10 1803 installation, high-entropy is a system setting and enabled by default in Windows Defender Exploit Guard. That setting didn't exist at the system level in Win 10 1709. Further, there is no reference to the high-entropy setting in Microsoft's most recent publication on WDEG here: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/customize-exploit-protection .   

Now high-entropy is applicable to my installation since it is x(64). However if it is being set on for x(86) by default, who knows what the result may be.

Edited May 11, 2018 by itman

[WhiskeyRiver 1]

We're right at 5 hours runtime since I disabled the protected service in HIPS per Marcos's suggestion. It hasn't failed yet which is a very very good indicator that the problem is solved for now. It almost surely would have failed by now. Way to go Marcos!

[itman 1,799]

4 minutes ago, WhiskeyRiver said:

I have the security center disabled with a registry entry on this particular machine (Home Edition.)

As far as I am aware of, disabling WD Security Center would have no effect on system or default app settings for WD Exploit Guard. WD Security Center is just a GUI interface to WD Exploit Guard.

[WhiskeyRiver 1]

3 minutes ago, itman said:

@Marcos, here is something else for Eset to check-out.

In my Win 10 1803 installation, high-entropy is a system setting and enabled by default in Windows Defender Exploit Guard. That setting didn't exist at the system level in Win 10 1709. Further, there is no reference to the high-entropy setting in Microsoft's most recent publication on WDEG here: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/customize-exploit-protection .   

Now high-entropy is application to my installation since it is x(64). However if it is being set on for x(86) by default, who knows what the result may be.

I just haven't had the time to flesh out all the new stuff but I'll get to it. Client's have been burning down my phone all week.

Here's a new one for ya: One of my clients has a really upscale Dell XPS laptop with a Intel Pro 6000p M.2 solid state drive. I worked on that stupid thing for 3 hours this morning. v1803 upgrade killed it. Come to find out, Intel and Microsoft have released a bulletin on this. The fancy drive is not compatible with v1803. There is no current fix for it and no ETA for a fix. The guy has $3000 in this laptop. Thank God we're not him. I guess I'm going to sell him a Samsung drive and hope the fall update doesn't kill that.

 

[WhiskeyRiver 1]

11 minutes ago, itman said:

As far as I am aware of, disabling WD Security Center would have no effect on system or default app settings for WD Exploit Guard. WD Security Center is just a GUI interface to WD Exploit Guard.

I know you can manipulate everything in group policy. I believe you can navigate to Computer configuration -> Administrative templates -> Windows components -> Windows Defender Antivirus and pretty much have your way with it. I shut off real time protection right there.

The home edition machines need further study.

Edited May 11, 2018 by WhiskeyRiver

[itman 1,799]

29 minutes ago, WhiskeyRiver said:

I know you can manipulate everything in group policy. I believe you can navigate to Computer configuration -> Administrative templates -> Windows components -> Windows Defender Antivirus and pretty much have your way with it. I shut off real time protection right there.

Note that Windows Defender Antivirus and Exploit Guard are to separate and distinct entities. Disabling WD Antivirus does not disable WD Exploit Guard.

WD Exploit Guard settings can be modified via:

1. Group Policy

2. PowerShell commands

3. Registry by adding:

Quote

Using Registry Editor

1. Open Registry Editor (regedit.exe) and go to the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\

2. If the MitigationOptions key is not there, right-click and add a new QWORD (64-bit) Value, naming it as MitigationOptions.

A mask for the MitigationOptions values is given here: https://www.wilderssecurity.com/threads/moving-beyond-emet-ii-windows-defender-exploit-guard.396007/#post-2750526 . Note these are system level override settings. As such any app related settings would apply to all processes.

Edited May 11, 2018 by itman

[itman 1,799]

26 minutes ago, WhiskeyRiver said:

Come to find out, Intel and Microsoft have released a bulletin on this. The fancy drive is not compatible with v1803.

Yeah, they have been web postings about SSD issues on v1803.