There are a few utilities that are useful for reviewing injected dll's within any process. Perhaps the two most popular, are Process Monitor and Process Explorer. I took a look at the Procmon capture uploaded to SR# 4-19462417181, and there is a Citrix dll injecting into McShield.exe, but it appears to be one of Citrix's parent dll's, and as such we cannot prevent this injection (would have to remove the Citrix software). It can be trusted, however, using ENS policy configuration.
There are also 8 Citrix dll's injected into a McAfee Agent process, masvc.exe. One of these dll's is the same parent dll as the one injected into McShield. Unfortunately, I cannot upload a screenshot, but if you still have a copy of that Process monitor capture, they can be identified by:
Opening the capture
Finding the process masvc.exe
Right+click on the process name and choose properties
Click on the Process tab
In the lower pane, you will be able to see any loaded dll's within that process. At this point, I normally arrange the lower pane view by clicking the company name, so that we can easily see who owns what.
That being said, I dug into these reported issues more, because I understand there are ongiong concerns here. Everything reported/reviewed/posted/submitted thus far, points to scan configuration. Without a MER, or the policy export assigned to the system named VDA03, I cannot give certain direction on confirming that, and then necessary changes to resolve the issue. I do not believe the dll injection is the reason for the issue. I believe this was mentioned previously, because it is possible for dll injection to lead to a multitude of problems. However, if the dll injection was the issue, then disabling the On-Access Scanner would not resolve the problen. If we are confident that disabling the OAS resolves the issue, then I would want to review the current configuration of the OAS. If we can do this through a MER result it would be ideal, because we can confirm configuration through the registry keys (helps remove McAfee Agent policy collection and ePO assignment issues from the equation). Whatever is set in the registry is what the product is using, regardless of what might be assigned.
We will be hard pressed to determine what might have changed, unless we have configuration information from a system using the previous 10.5 version of ENS, where the issue did not occur. What we can do, is review the current configuration using 10.6, and then go from there.
If you would like to let us know when the MER is uploaded, I can certainly take a look and then provide an update.
We still have systems under 10.5 that are working fine.
As already posted, 10.6 is now working as well - since we added the High/Low Process scanning for the Citrix Profile process. Again, not sure why it failed to work during the initial attempt at High/Low settings.
We are working at this point so as long as there is no concern about this resurfacing due to lack of understanding the issue we will consider it resolved.
Apologies, but I was more referring to Xaba's post, since it would seem the issue continues.
For the specifc issue you have outlined, if a policy change corrected the problem, then of course we would want to completely vet anything that has to do with policy configuration, assignment, enforcement, etc. There could be numerous reasons why the correct policy was assigned, but not actually being honored on the system(s). You had mentioned that your issue was worked by support, but that the support technician didn't provide root cause, even though they seemed to have redone the policy configuration, and that resolved the issue. If there is an SR# you can provide me, even if it is closed, and if that SR has a MER from a problematic system prior to support redoing the low-risk policy, I might be able to tell you why, now, the policy is working correctly.
It would also help to have a MER from a system that is running 10.5, as a method of performing a local policy comparison. If that data set exists within the service request, then I would be more than happy to continue to review your, luckily now resolved, issue.
That was understood, I was just offering our resources. We would need somewhere to send the MER to for Xaba's case - probably a stretch as to whether it would be helpful or not.
We know the concept of why the issue occurs, what isn't defined is what changed in 10.6 that made the issue surface. We can let it go if it is information that shouldn't be shared (too much detail in the internal workings). At this point, I'm done putting time into it unless it will help Xaba.
Apologies, let me clarify.
I am offering to review data from your environment, for you specific service request. Nothing has changed between the mentioned ENS versions that would make us have to (now) ignore UserProfileManager disk activity. This Citrix application is a common exlusion we have implemented for quite some time. If this was an issue due to code in the product, then I wouldn't expect low-risking a process to alleviate the symptoms. While upgrading ENS 10.5 to 10.6 could have been the catalyst, there is nothing (at least not yet) to show that the code upgrade itself is the cause...I am offering to find that cause, as it relates to your SR, but without the correct data sets, we are left with providing what we already know about the scanners and their interaction with this Citrix process.
Understood if more pressing matters need attention. We will make sure to circle back and provide an update once the data from @xaba_sg is obtained and reviewed, but while the symptom might be identical, the root cause could very well be different.
I don't need to troubleshoot further.
There is no other excuse for the issues we experienced. Either the McAfee version or the definitions caused a change in the Citrix environment - there is no other option/ nothing else was updated. We have 2 images that servers boot from - one has remained on 10.5.1 the other was let upgrade to 10.6.1. Each reboot, the 10.6.1 image would start as 10.5.1 and run normally until the upgrade pushed to it. We updated the base image to 10.6.1 in case it was an install without reboot issue but the problem remained only worse as it was slow from boot on. As noted, we tried the registry entries - no improvement, then the High/Los process with the profiler entry - also no change. A few days later, at the request of support, we tried the High/low process settings again and it worked - no idea why. The 10.5.1 image systems have continued to work fine - as long as we don't allow an ugrade to 10.6.1 (or with the proper 10.6.1 settings. These are locked images - no other updates can get to them without our intervention.
I collected 3 sets of logs (with Citrix Policy exclusion for Low Risk process)
1) Without Registry Key
2) With Registry Key
3) With OnAccess Scan disable
as previously mentioned, if the onaccess scan is disabled, the clients connect in 6 seconds, without any problem.
I have also uploaded the policy in use.
P.S.On the proc monitor log i cant find masvc.exe process.
Your policy shows you still have scanning enabled for your low risk processes. I did mention this three weeks ago.
<Setting name="bScanReading" value="0"/>
<Setting name="bScanWriting" value="1"/>
As @akatt also mentioned, you need to disable scan when read and write for your low risk processes. Have you tried this yet?
1) I do not configure process to completely exclude the scan (a few years ago this setting infected 7 servers).
2) these exclusions were not needed with 10.5.x, so Mcafee should to do a fix. For us, making exclusions is a workaround, not a definitive solution.
If for now, the only solution is to disable scanning on all Citrix processes (Read and Write), I will continue to use Viruscan 8.8.
This is not a new requirement. It's also not our requirement, but it's one from Citrix. Citrix has always advised that their processes must be completely removed from scanning. This can only be achieved by disabling scanning for low/ high risk processes.
This is documented in their guidelines and was no different for any ENS or VSE version:
Citrix Guidelines for Antivirus Software Configuration (https://support.citrix.com/article/CTX127030)
Citrix Consolidated List of Antivirus Exclusions (https://www.citrix.com/blogs/2016/12/02/citrix-recommended-antivirus-exclusions/)