windows 10 spring update

[voyageur2180 0]

I really think there is a serious problem with win 10 spring v 1803.

the release to the spring  creator update as been removed………….and if you try with the windows update tool……….after a short time , it say…( you got the lates version…...

[WhiskeyRiver 1]

6 hours ago, itman said:

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:

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.

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

[WhiskeyRiver 1]

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:

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.

 

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

[itman 1,659]

11 hours ago, WhiskeyRiver said:

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

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

[WhiskeyRiver 1]

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.

[jamess3973 1]

There was serious issues with KB4103721 as well. For some reason my Computer took about 20-25 minutes to complete the reboot installation process. But all is well after the install.

I'm also on SSD but it's Kingston, so no issue with v 1803.

[Marcos 5,074]

We're going to report the issue to Microsoft since loading dlls using a standard API function is failing with ERROR_NO_SYSTEM_RESOURCES (Insufficient system resources exist to complete the requested service).

[WhiskeyRiver 1]

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.

[itman 1,659]

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:

Quote

The reason for the ERROR_NO_SYSTEM_RESOURCES(1450) is that on x86 (32-bit) or IA64 (64-bit) systems, the maximum buffer size is just under 64MB. For X64 systems, the maximum buffer size is just under 32MB. The maximum unbuffered read and write size limits are imposed by the design of the IO manager inside the Windows executive. When an application reads or writes files that are opened with FILE_FLAG_NO_BUFFERING, the IO Manager locks the application's buffer into physical RAM and then maps the virtual addresses into physical addresses to pass to the disk device by making a memory descriptor list (MDL). The buffer size limitation comes from the maximum size MDL that the IO Manager will create. The reason for the difference between platforms is the way the maximum buffer size is calculated from the memory page size and pointer size.

Please Consider the following scenario:

This limitation occurs when the file is opened with FILE_FLAG_NO_BUFFERING.  When you try to create a large file in Microsoft Windows XP by moving the file pointer to the end of a file. Then you call the SetEndOfFile function. In this scenario, the SetEndOfFile function fails with error 1450 "ERROR_NO_SYSTEM_RESOURCES".

https://social.msdn.microsoft.com/Forums/silverlight/en-US/e4414c2e-664d-4ad6-9c93-c08aa5306239/possible-causes-for-errornosystemresources-error-during-fwrite?forum=vclanguage

Edited May 14, 2018 by itman

[WhiskeyRiver 1]

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:

https://social.msdn.microsoft.com/Forums/silverlight/en-US/e4414c2e-664d-4ad6-9c93-c08aa5306239/possible-causes-for-errornosystemresources-error-during-fwrite?forum=vclanguage

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.

Edited May 14, 2018 by WhiskeyRiver

[WhiskeyRiver 1]

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.

[itman 1,659]

Another possible "culprit" might be the memory integrity feature introduced in ver. 1803. My old hardware doesn't support it. My understand standing is if your hardware is compliant, VBS will be enabled automatically.

The key component requirements of memory integrity are:

1. UEFI BIOS

2. Virtualization enabled in the BIOS

3. TPM 2.0 support

4. Secure Boot enable I believe - might not be required for memory integrity protection only

5. 64 bit CPU

Refs:

https://www.windowscentral.com/how-enable-memory-integrity-protection-windows-10-april-2018-update

https://techcommunity.microsoft.com/t5/Windows-Insider-Program/Windows-Defender-System-Guard-Making-a-leap-forward-in-platform/td-p/167303

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs

Edited May 14, 2018 by itman

[Peter Randziak 1,130]

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.

 

[WhiskeyRiver 1]

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.

 

Edited May 15, 2018 by WhiskeyRiver

[Peter Randziak 1,130]

Hello @WhiskeyRiver ,

good, thank you for your willingness to help us with this issue.

Will be waiting for a message from you.

Regards, P.R.

[WhiskeyRiver 1]

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

 

 

Edited May 17, 2018 by WhiskeyRiver

[WhiskeyRiver 1]

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.

[itman 1,659]

13 minutes ago, WhiskeyRiver said:

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.

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? 

[WhiskeyRiver 1]

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.

Edited May 19, 2018 by WhiskeyRiver

[Marcos 5,074]

6 hours ago, WhiskeyRiver said:

I suspect the eset programmers solved it once they confirmed that turning HIPS off cured it.

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.

We didn't change anything with regard to the issue and are currently anticipating more information / resolution from Microsoft.

[WhiskeyRiver 1]

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.

[itman 1,659]

1 hour ago, WhiskeyRiver said:

The v1803 updates KB4103721, KB4103729 and KB4100347 are the updates I see applied to all three of these three machines.

I am on Win 10 x(64) 1803. I received:

• KB4100347 - I use x(86) MS Office. Doubt this fixed the issue.
•  KB4103729

I did not receive KB4103721 which might be where the x(86) fix lies. And my build number is 17134.48:

Quote

Security updates to Windows Server, Microsoft Edge, Internet Explorer, Microsoft scripting engine, Windows app platform and frameworks, Windows kernel, Microsoft Graphics Component, Windows storage and filesystems, HTML help, and Windows Hyper-V.

https://support.microsoft.com/en-us/help/4103721/windows-10-update-kb4103721

Edited May 21, 2018 by itman

[WhiskeyRiver 1]

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.

[itman 1,659]

4 minutes ago, 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.

That was "supposed" to be fixed in KB4103721:

Quote

Addresses an issue that may cause an error when connecting to a Remote Desktop server. For more information, see CredSSP updates for CVE-2018-0886.

 

[WhiskeyRiver 1]

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.