WhiskeyRiver

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.

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.

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.

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.

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.

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.

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.

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.

Here's another new one itman. RDP remote session is broken in v1803. Studying a workaround now. The hits just keep on coming.

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.

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.

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.

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

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.

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.

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.

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.

I'm not certain there's anything you can do about the desktop manager. Other than using a basic theme.