Sophos Central Endpoint and SEC: Computers fail/hang on boot after the Microsoft Windows April 9, 2019 update. Please follow knowledge base article 133945
Learn about the Benefits of Multi-Factor Authentication (MFA). Turn your MFA on now!
We'd love to hear about it! Click here to go to the product suggestion community
On a new software build of windows 10 on a T450 Lenovo, we found that at the end we installed Sophos Endpoint Intercept X 2.0 and it significantly slowed down the computer. All aspects of the computer became slow. On first bootup, connecting the Wifi - slow. On login, the CPU would pin at 100% for long periods of time with high memory usage. All applications would be slow to open, printing would be very slow. This is a new laptop i5, 8 GB RAM, 256 SSD.
We would remove the Intercept X and the computer would return to normal operation. Fast bootup, fast login, apps, etc...
Now for this customer, then use Trend Micro as their primary AV. We have Sophos Intercept X added on for the extra protection. We did not have issues previously until the Intercept X Version went up to 2.0. Has anyone else noticed a large performance hit with Intercept X 2.0?
In reply to Ted Bundy:
Hi Ted Bundy,
Do you have a ticket number so that we can have a look?
Otherwise, I suggest you reach out to Support and file a case for further review and troubleshooting.
Also, to determine which version of Intercept X is installed, double click on the Sophos icon in the System tray --> About , and look for "Sophos Intercept X" under Products. You will see the version listed there.
In the registry, if you create a new DWORD called ServicesPipeTimeout under the key:
and set the value to 60000 decimal, i.e. 60 seconds from the default of 30 seconds (30000 as mentioned in the email) does everything work when you reboot?I'm just curious if that even helps if they were given more time.Regards,Jak
In reply to jak:
Did this work for anyone with the problem?
In reply to Robert Planche:
Yep, i tried it on a PC and the audio service did eventually start, it made the logon extremely long & slow though. I wont be deploying this out as a fix as I would rather sopos fix the issue. But if your desperate, then it may be a workaround until sopos stops blocking.
Tried it myself and agree the system boot time is way too long. I also noticed this is only occurring on systems with spinning HD's and not systems with SSD's. They need to fix this problem asap ;)
I would like to move my (small) organization to Sophos Endpoint with Intercept X, but the performance with this release was too slow as described in this thread. It seems the time to resolution on this is way too long.
Is that generally the speed of working at Sophos, or is this just complicated? If it is general I will look elsewhere.
In reply to Pieter van Kampen:
We have Intercept X activated on all machines and don't see any impact. At least nobody complains about slow performance. Maybe because we use SSDs everywhere now?
In reply to Jelle:
Yep if you have ssd drives you seem to be ok. But if you still have old spinning disks then look out! I agree the support is terrible. It goes to level 1 for ages, then level 2 for ages, then they acknowledge that it is a real problem & it finally goes to level 3. That's when they will fix it. They don't realise that enterprises cant work like this. It's too long to wait.
We've had a call with Sophos about this for quite some time with a lot of back and forth gathering logs. We have now received this update and workaround from them:
This is a sequence of events leading to services timing out and not starting 1. A service is launched, e.g. SysMain, with command line "c:\windows\system32\svchost.exe -k localsystemnetworkrestricted -p -s SysMain" 2. Svchost.exe has "Code Integrity Guard" mitigation enabled in Audit mode. This feature comes from Windows Defender settings; there is a specific override for svchost.exe. 2.This feature checks that the binaries loaded/injected into the process are signed by Microsoft, but does not block them, since it is in audit mode only. 3. Hmpalert.dll (our driver) is injected into svchost.exe process by hmpalert.sys driver. 4. Because of "Code Integrity Guard", Windows checks the signature of hmpalert.dll, using functions in code integrity dll (ci.dll). 5. Windows checks both the embedded signature, and the signature in catalog (.cat) files – this causes ALL .cat files (thousands of files) to be opened. 6. Catalog file check happens in the context of one of the services (whichever was started first); all other services are waiting on the first one to finish the signature check. 7. The check can take a long time (due to opening thousands of files). In customer's procmons, the check was taking more than 1 minute. 8. If the check takes longer than 30 seconds, the service will time out (and all other services waiting for it). We are now looking into how we can improve this behaviour from our side - but are you able to please test the below workaround and see if this helps: 1. Open "Windows Defender Security Centre" 2. Go to "App & Browser control" 3. Scroll down and click on "Exploit protection settings" 4. Click on "Program Settings". 5. Wait for a list with a bunch of executable names to pop up (could take more than 10 seconds) 6. Scroll down until you find "svchost.exe" 7. Press "Edit" 8. Check if "Code Integrity Guard" is enabled in "Audit only" mode. If it is enabled, turn it off (uncheck "Override system settings"). 9. It might help to also disable "Arbitrary code guard" (if it is in "Audit only" mode), but it shouldn't be strictly necessary. 10. Click on "apply" to save the changes. 11. Reboot the machine. Note that we are not making the system less secure, since these mitigations were in audit only mode. If this workaround helps, it believe it should possible to deploy these settings across the organization (see https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/import-export-exploit-protection-emet-xml ).
It seemed to work for us on a couple of machines I've tested on and am looking to roll this workaround out to the rest of the org.Hope this helps you guys.Cheers, Rob.
In reply to Shire of Mundaring:
After a PS command to disable this, would this be correct?
Set-ProcessMitigation -Name svchost.exe -disable AuditMicrosoftSigned
Suspect this is the same issue as https://community.sophos.com/products/sophos-central/f/sophos-central/105766/sophos-blocking-wireless
Had a call with Sophos to disable device control, but had no affect. Re-installing Sophos seems to have sorted the issue, but will investigate more to see if its Intercept X.
Certainly experiencing a massive slowdown on machines recently.
UPDATE: After going though the system event log, I can confirm that the WLANSVC service failed to start along with several others. Have now reported to Sophos and asked to escalate. Disabled exploit mitigation and protect processes in the threat protection policy for now to see if that helps.
Seems to co-inside with installation of windows updates. I'm guessing on slower laptops (without charger connected) the performance hit is too much and the services are failing to start in time.
Anyone else seeing those machines also having a black screen on login for upwards of 10 minutes?
Finally posted an official workaround, nearly a month after the suggestion answer post: https://community.sophos.com/kb/en-us/132998
Lets hope it doesnt take a month to finally fix it.
I also face the same issue and impact on the users machine but after uninstalled this patch it effects the system and the CPU utilisation now become 100%.
In reply to Piyush Kumar:
This bit me in the *** hard this week....
After successfully testing and tuning our Sophos Intercept X deployment in IT and to our Test Group, I deployed out to our Corporate HQ.
What I learned:
1) Sophos Intercept X appreciates a good SSD and 16GB DDR3 RAM.
2) Microsoft doesn't care that you have good AV. Your AV must work with their AV or your users with do ALOT of waiting for screens to deliver the info. (See #4)
3) Don't blame Sophos for every problem. It may be the problem, but use good troubleshooting skills and come up with the solution independently.
4) If you have Windows 10 machines on your network...or ever will...develop a GPO/logon script/etc for disabling the "Code Integrity Guard" in 1803+.
My Customer Service and Buying team went from lynch mob to party after GPO deployment....the Executive Team even called off the recruiters!
Just my thoughts....Cheers!