WhiskeyRiver

Thank you sir. I'm gonna put that info to immediate use.

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.

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!

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.

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?

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.

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.

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.

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

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.

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.

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.

I'll try that and report back. Thanks!

I should add one more thing to ponder. I have a client with a 32-Bit Windows 7 machine. He's having the same issue. I haven't seen the machine yet but it's apparently the same error message.

KB4103721 is in stalled on all of the 32-bit v1803 machines. EDIT: I should point out to others that KB4103721 shows up as 2018-05 Cumulative Update.

I have had both the 32-bit final release and the 64-bit final release of v1803 issued to the ring for two weeks. I have upgraded about 10 64-bit machines and 5 32-bit machines. Every single 64-bit machine is just fine. Every 32-bit machine - the antivirus is broken. I even did a clean install of v1803 on a new hard drive and did nothing but install Nod32 antivirus. Instantly broken. Nothing fixes it. Not playing with virtual memory size. Not completely disabling Windows Defender through Group Policy on the Pro machines. Not disabling Defender with registry entries on the Home Edition. Nothing fixes it. I even let a Eset technician log onto to one of the 32-bit machines. He did quite a few things, including placing Nod32 in the pre-release update channel. These machines always work for a short period of time. Nod32 fails on some instantly. On some within an hour. Some might work for several hours but the fatal error always arrives. EDIT: The pre-release version of Nod32 is not the answer either. It started pushing error messages a few hours after install. At this point, I'd take any new suggestion anyone has. I'm not a newbie and I'm not afraid to tinker. I've been a network engineer for a very long time so whatever might work I'm willing to try. I've been using eset products for a dozen or more years so I know the product pretty well. In the meantime, I'm going to give eset techs another crack at one of these. To recap: 64-bit = 100% success 32-bit = 100% failure