WhiskeyRiver

Members
  • Content count

    40
  • Joined

  • Last visited

  1. 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?"
  2. Not running. That part worked. I guess. WD is generally not running when the Nod32 errors occur. Hadn't thought about that before.
  3. 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.
  4. I will apply it and report back.
  5. 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.
  6. Doesn't work for all of them. The one I was trying to dump the memory on had the protective service disabled.
  7. That last one... Avast breaks the rollback too apparently. Re-Install is the only answer for them.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Here's another new one itman. RDP remote session is broken in v1803. Studying a workaround now. The hits just keep on coming.
  14. 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.
  15. 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.