WhiskeyRiver
-
Posts
42 -
Joined
-
Last visited
Posts posted by WhiskeyRiver
-
-
17 hours ago, itman said:
@WhiskeyRiver, FYI
Microsoft Releases KB4100403 to Fix Windows 10 Intel & Toshiba SSD Issues
Nobody's happier to see it than me. Well, maybe my neighbor who manages an IS department that has a couple of dozen Surface Pros deployed. I wonder if they've slipstreamed the fixes into their downloadable ISO?
-
Well... Not surprising now that I think about it. On most of these machines I've already tinkered with them ahead of time. I know I'm going to install Nod32 so I zing in a few registry changes:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender]
"DisableAntiSpyware"=dword:00000001[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection]
"DisableRealtimeMonitoring"=dword:00000001[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\Network Protection]
"EnableNetworkProtection"=-I'm still working on my first cup of coffee. Surely the cobwebs will vacate shortly. In the meantime I'm distracted by the little guy in my head asking stupid questions like "is Batman a transvestite?"
-
Not running. That part worked. I guess. WD is generally not running when the Nod32 errors occur. Hadn't thought about that before.
-
17 hours ago, itman said:
I just found this "tidbit" in regards to the next Win 10 release:
If it does anything besides pitch an annoying security center box in R4 i can't confirm it. I still had to disable security center or it can be clicked right back on. I had to:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SecurityHealthService - set start to 4
and
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run - delete the string value labeled SecurityHealth
So far I haven't tinkered this particular machine too much. The famous antivirus initialization error was evident when I found it this morning. I didn't know I had this many 32-bit installs still out there.
-
2 minutes ago, itman said:
I just found this "tidbit" in regards to the next Win 10 release:
I will apply it and report back.
-
I did that already. All three of the laptops I reference early in this thread were brand new hard drives with v1803 installed from scratch. As soon you install Nod32 and reboot the antivirus starts failing.
That Avast problem... It even breaks restore points so you're caught in a loop if you try to go back. I always straighten existing machines out... Clean them up... Make sure there's no viruses or rootkits... Clear all restore points and make a new one... Then do the upgrade. I haven't had that particular problem where I couldn't return. But I only use eset products and malwarebytes so I'm atypical.
-
1 minute ago, itman said:
I am still "mulling" over this one. Does this just disable PPL protection of ekrn.exe and/or additional Eset self-protection mechanisms?
Also, I assume Eset is still using is elam driver to load ekrn.exe early in the boot process?
Doesn't work for all of them. The one I was trying to dump the memory on had the protective service disabled.
-
That last one... Avast breaks the rollback too apparently. Re-Install is the only answer for them.
-
8 minutes ago, Marcos said:
We've already got enough memory dumps so no further dumps are needed. As a workaround, you can try disabling Protected service in the HIPS setup and rebooting the machine. The only 100% solution known to date is upgrading Windows 10 RS4 x86 to x64 version.
Okie-Doke. Glad you have what you need.
I'm looking at a shelf with 10 Dell i560 desktops, all dual core Intels, all with 4Gb RAM, all were running 32-bit Windows, all of which got retired by either v1709 or now v1803 for various reasons, starting with the Scepter and Meltdown patches. It's a damn shame. All were replaced with new machines, I7 processors and 16GB RAM running 64-Bit Windows. Somebody's making good money from these Microsoft errors. I'm not a conspiracy nut but in this case...
Oh, one of my other groups are reporting that 64-Bit Windows machines with AVG and Avast updating to v1803 are blue-screening on the reboot.
These are trying times. -
Good Gawd. I can't get a memory dump from this computer by remote. The computer is so slow... And I'm trying to do it by remote. It's in too trafficy an area and someone keeps coming by, trying to use it and resetting it. Apparently the dump is taking hours. I can't induce a crash dump because I'm not there. Frustrating.
-
BAM! Caught one in the wild. Exact scenario we've been talking about. All three updates. Producing the Virus Scanner Initialization Failed message right now. Loading the NET developer tools on it so I'll have a memory dump later today.
-
9 minutes ago, WhiskeyRiver said:
I was just playing with that new group policy. Enabling Computer Configuration -> Administrative Templates -> System -> Credentials Delegation allows you to select migitgated, vulnerable or just disable the policy. This is a RDP session to a server that allows the user to look up all property records at every county court house in Oklahoma. I think I'm going to call them and see what they say because manipulating the three options doesn't help.
Problem was on the server end. They had to change their group policy to force updated clients. They're running Win2008 R2 if that helps anyone.
-
10 minutes ago, itman said:
That was "supposed" to be fixed in KB4103721:
I was just playing with that new group policy. Enabling Computer Configuration -> Administrative Templates -> System -> Credentials Delegation allows you to select migitgated, vulnerable or just disable the policy. This is a RDP session to a server that allows the user to look up all property records at every county court house in Oklahoma. I think I'm going to call them and see what they say because manipulating the three options doesn't help.
-
On 5/11/2018 at 3:16 PM, WhiskeyRiver said:
Here's another new one itman. RDP remote session is broken in v1803. Studying a workaround now. The hits just keep on coming.
-
On 5/19/2018 at 10:56 PM, Marcos said:
We didn't change anything with regard to the issue and are currently anticipating more information / resolution from Microsoft.
The v1803 updates KB4103721, KB4103729 and KB4100347 are the updates I see applied to all three of these three machines. One of those changes has fixed the problem apparently.
-
2 hours ago, itman said:
Guess no more "dustbowls" there? Amazing what intelligent agriculture practices can achieve.
So what you are saying is that nothing was done Eset-wise to that installation and NOD32 is running w/o issue? Wonder if the May 1803 Cumulative update did correct the problem? If so, I guess it needs to be determined if all having NOD32 memory issues on x(86) have applied the May update.
One other question, was NOD32 installed prior to or after the 1803 upgrade?
Exactly. The problem cured itself on two of them. I suspect the eset programmers solved it once they confirmed that turning HIPS off cured it. I installed the v1803 final release from the fast ring on all three of those laptops on the same day. They were all on my workbench for bad hard drives and I was replacing them with SSDs. I had the final release of v1803 from the fast ring so I deployed it on these non-mission critical machines. The problem began immediately on all three of those 32-bit machines. eset customer support (frank - thanks) logged onto to one of them and spent a good deal of time (couple of days) trying to solve it but nobody knew what was wrong. So one of the laptops got extensive scrutiny and was finally solved by putting it the pre-release eset update channel after the programmers had their way with it. The other two solved themselves with updates from the regular update channel and maybe the almost immediate (for Microsoft) cummulative Windows update. It might be some combination of the two or it might be eset solved the whole thing. But the problem went on for quite a few days. I'd say it's ironed out now for anyone that's fully up to date with Windows updates and the most current version of Nod32. It's worth noting that two of the laptops were older pre-UEFI machines and one was a newer UEFI machine and all were Intel processors and chipsets from various eras.
-
On 5/15/2018 at 9:14 AM, Peter Randziak said:
Hello guys,
especially those who faced the issue "Virus scanner initialization failed" @voyageur2180 @Romas @DougiS @WhiskeyRiver
We received a response from MS and we need full memory dumps, from a state, when the issue occurs to investigate it.
Would you be please able to create them for us?
In case you have any issue with it or need support with creating them just let us know.
In case you have a full manual crash dump, when the Virus scanner initialization failed, pack it, upload to a safe location and send me and TomasP a private message.
Thank you in advance, P.R.
I traveled all the way to Oklahoma yesterday to visit my client who had the last v1803 32-bit problem child computer. Unfortunately, that computer had already corrected itself with all the current v1803 Windows Updates and Nod32 Updates. No longer having an issue.
Did you know your product works in Oklahoma? Who knew? They have everything now. Electricity, running water, indoor toilets, computers and internet. Life is pretty good in Oklahoma. -
On 5/15/2018 at 9:14 AM, Peter Randziak said:
Hello guys,
especially those who faced the issue "Virus scanner initialization failed" @voyageur2180 @Romas @DougiS @WhiskeyRiver
We received a response from MS and we need full memory dumps, from a state, when the issue occurs to investigate it.
Would you be please able to create them for us?
In case you have any issue with it or need support with creating them just let us know.
In case you have a full manual crash dump, when the Virus scanner initialization failed, pack it, upload to a safe location and send me and TomasP a private message.
Thank you in advance, P.R.
I have examined two of my remaining problem childs. Both are running Windows 10 Home (32-bit), 10.0.17133 and Nod32 v11.0.159.9. Both have HIPS enabled and neither of them is producing any errors. Updates on both are set to pre-release. Both of these were having the "Virus scanner initialization failed" for several days after I upgraded them to v1803. I had the insider ring final version of v1803 for a week or so before it went live so I encountered the problem very early. I will contact the owner tomorrow and see if he will allow me to put one back on the regular update channel. The last problem child is 50 miles away from me and I will be going there on Friday.
A sidebar: memory dumps are easy to make in W10. You learn that pretty quickly if you have a lot of software to support. lol
-
7 minutes ago, Peter Randziak said:
Hello guys,
especially those who faced the issue "Virus scanner initialization failed" @voyageur2180 @Romas @DougiS @WhiskeyRiver
We received a response from MS and we need full memory dumps, from a state, when the issue occurs to investigate it.
Would you be please able to create them for us?
In case you have any issue with it or need support with creating them just let us know.
In case you have a full manual crash dump, when the Virus scanner initialization failed, pack it, upload to a safe location and send me and TomasP a private message.
Thank you in advance, P.R.
I'll be glad to try. The issue on the 32-bit machine in question has been resolved and has been deployed and is out of my purview but I have a couple of clients still having issues. I will see if I can get access to one to further your research. Unfortunately, both of these machines are some distance from me.
-
17 hours ago, WhiskeyRiver said:
I appreciate it.
On the off topic - An update. 2½ inch form factor Intel 520 series SSD drives - they're apparently not v1803 compatible either. I pulled a brand new one out of the box and cannot clean install v1803. I then restored an Acronis backup image I'd made just this week of a similar installation. Boot... 30 seconds... Reboot... 30 seconds... Reboot... Continuously. Even in safe mode. Add another fatality.And now this: Woody Leohnard reports this morning that v1803 is not compatible with Toshiba SSDs either. For whatever reason, they overheat, apparently to the point of permanent damage.
-
15 minutes ago, itman said:
Does make one wonder if Microsoft changed the max. buffer size in Win 10 1803 x(86) in which case it won't be just NOD32 having issues:
It's not just eset products. I have confirmed with another tech that problems are also occurring with Avast and AVG on 32-bit v1803 installations.
-
Here's a new Monday morning v1803 / Nod32 weirdity.
Windows 10 v1803, fully updated, Nod32 11.1, also fully updated. This combination causes the search function to fail in Microsoft Outlook 2007. Removing Nod32 allows the search function to return to normal.
It's not something I need to fix as I was in the process of replacing the computer in question with a new 64-bit Windows v1803 and the current Microsoft products. Nod32 works just fine in the 64-bit world. There's undoubtedly someone out there trying to run that combination though so I thought I'd report it. -
On 5/12/2018 at 9:24 AM, itman said:
FYI - here's the Microsoft article on how to do it via Group Policy settings: https://docs.microsoft.com/en-us/windows/security/threat-protection/override-mitigation-options-for-app-related-security-policies
I appreciate it.
On the off topic - An update. 2½ inch form factor Intel 520 series SSD drives - they're apparently not v1803 compatible either. I pulled a brand new one out of the box and cannot clean install v1803. I then restored an Acronis backup image I'd made just this week of a similar installation. Boot... 30 seconds... Reboot... 30 seconds... Reboot... Continuously. Even in safe mode. Add another fatality. -
11 hours ago, itman said:
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:
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.
I'm not certain there's anything you can do about the desktop manager. Other than using a basic theme.
windows 10 spring update
in ESET Internet Security & ESET Smart Security Premium
Posted
Haven't had a chance to look. Busy day. If the SSD fixes aren't slipstreamed then I still can't deploy a new installation using an Intel drive. I will check to see what they've got up. Thanks.