Analyzing the McAfee MFEHIDK event log warning

When McAfee VirusScan Enterprise 8.8 patch 1 and higher is installed on your Citrix workers, the warning MFEHIDK is written to the system log four times every ten minutes. In this article, the main focus lies on analyzing the McAfee MFEHIDK event log warning using Process Explorer.
To my knowledge, a solution or workaround does t exist. Only McAfee is able to provide a solution. Continue reading to find out why.

The issue

The issue is quite simple; when McAfee VirusScan 8.8 patch 1 or higher is installed on your Citrix worker, the system log is flooded with warnings. Every ten minutes, four warnings with the source name MFEHIDK and event ID 516 are written to the system log.

Analyzing the McAfee MFEHIDK event log warning with Process Explorer - Event viewer McAfee mfehidk warnings

As a good administrator you try to keep your event logs clean, but you are not able to get rid of these McAfee entries. The following paragraph explains why these warnings are generated.

The reason

First of all, let me start by saying that this issue is not related to the scanning of files and has nothing to do with file or folder exclusions or the configuration of trusted processes.

The issue is described in the following McAfee article:
https://kc.mcafee.com/corporate/index?page=content&id=KB71083.

As per McAfee; "IMPORTANT: Event ID 514/516/519 does not indicate an issue with the VirusScan Enterprise (VSE) product; it relates to a new VSE security feature.
Event 516 occurs for legitimate reasons to raise awareness for the Administrator that McAfee code may be compromised."

A warning is written to the event log when this McAfee security feature finds potentially compromising code in one of it's own processes. In the screenshot above, the executable reporting the potential security issue is naPrdMgr.exe (which belongs to the McAfee VirusScan software). Compromising code can either relate to unsigned/unverified DLLs or to custom hooks (DLLs) which add themselves to the process chain (so-called DLL injection).

Checking for unsigned/unverified DLLs

Let's open the tool Process Explorer to take a closer look at the process naPrdMgr.exe.

Note:
Process Explorer is one of the original SysInternals tools (which now belong to Microsoft) and can be downloaded here:
https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

After starting Process Explorer, go to View \ Show Lower Pane in the top menu. This will add a second window pane. Now go to View \ Lower Pane View and select DLLs. When you select a executable in the top pane, you will now see all DLLs that are loaded for the executable in the lower pane.

Note:
You have to start Process Explorer as an administrator (run as administrator), otherwise you do not see any entries in the DLL pane!

In the upper pane, select the process naPrdMgr.exe (under winnt.exe \ services.exe \ svchost.exe). In Process Explorer, you see a large number of DLLs from different vendors attached to this process (mainly from McAfee, Microsoft and Citrix).
For each of these DLLs, check the values in the column Verified Signer. The correct value is (Verified) %CompanyName%. Any unsigned or unverified DLL could be the reason for the MFEHIDK event log warning. You can pretty much ignore any unsigned or unverified Microsoft DLL. At least all of the Citrix DLLs should be verified and signed.

Analyzing the McAfee MFEHIDK event log warning with Process Explorer - Process Explorer verified signer

Note:
If you do not see the column Verified Signer in the lower pane you have to add it. You can add columns by selecting the grey bar with a right-mouse click (located at the top of the lower pane). Select the only available option: Select Columns. Add the column called Verified Signer.
If you do not see any information in the Verified Signer column, go to the top menu and select Options \ Verify Image Signatures. Now you should see some information for each DLL.

Checking for custom hooks

Now that we have established that all non-Microsoft DLLs are signed and verified, we have to look at any custom hooks (DLLs) that may be loaded into the naPrdMgr.exe process chain. Hmm, which product do we know that uses a lot of custom hooks? Right, Citrix XenDesktop.

As you can see in the screen below, multiple DLLs from different vendors are part of the naPrdMgr.exe process chain. The DLLs within the red square are the loaded Citrix DLLs. To focus on the Citrix DLLs, simply sort the list based on company name (Citrix Systems, Inc.).Analyzing the McAfee MFEHIDK event log warning with Process Explorer - Process Explorer overview loaded Citrix DLLs

Microsoft DLLs are part of the operating system and they are accepted by the McAfee security feature. McAfee DLLs are accepted as well of course. Citrix DLLs however, are not accepted by the McAfee security feature. Let's perform a little test to see if this hypothesis is true.

The test

Note:
Do not perform this test on a machine in production! Use a test machine instead.

As described in the Citrix article How to Disable Citrix API Hooks on a Per-application Basis (http://support.citrix.com/article/CTX107825), it is possible to disable all custom hooks for a single process by excluding this executable in the registry. In our example, we want to exclude the process "naPrdMgr.exe".

Create or modify the following registry value(s):

  • Key: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook
  • Value Name: ExcludedImageNames
  • Type: REG_SZ
  • Value: naPrdMgr.exe

On 64-bit systems, repeat this step for the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook.

After rebooting the machine, you will still see the MFEHIDK warnings in the event log. Why does this happen when you just excluded all Citrix custom hooks?

The reason is that Citrix uses a main or "master" custom hook to load all other custom hooks. This hook is called "mfaphook.dll". In the screenshot below you can clearly see that this DLL is the only one that remains:

McAfee MFEHIDK warning in event viewer explained - Process Explorer overview loaded Citrix master DLL

This test still does not conclusively tell us that the Citrix custom hooks are to blame for the McAfee warnings.

So one final test is needed. We will now disable all (Citrix) custom hooks. Go to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows and change the DWORD value LoadAppInit_DLLs from 1 to 0. Changing this value will prevent any custom hooks (from any software) to be loaded.

Now reboot the machine. After the reboot, open Process Explorer and check the naPrdMgr.exe process chain once again. You will see that no Citrix DLLs are loaded. Also, the system log remains clean. No new McAfee MFEHIDK warnings are generated.

Of course, this was just a test to establish the cause of the warnings. It would be very unwise to prevent all (Citrix) custom hooks from being loaded. If Citrix XenDesktop cannot load its custom hooks, than the HDX features no longer work.

The result

As you can see, analyzing the McAfee MFEHIDK event log warning with Process Explorer explains the flooding of the system log on your Citrix workers. Besides the flooding of the event log (four warnings every ten minutes), I am not aware of any negative impact on system performance.
Unfortunately, there is no solution or workaround to stop this behavior. Only McAfee can solve this issue. I hope that in one of their future patches McAfee will include the Citrix DLLs to their internal list of trusted code.

Share this post:
Dennis Span on EmailDennis Span on LinkedinDennis Span on Twitter
Dennis Span
Dennis Span
Dennis Span works as a Senior Citrix Architect for a large insurance company in Vienna, Austria. He holds multiple certifications such as CCE-V, CCIA and CCEA. In 2017, Dennis became a Citrix Technology Advocate (CTA). Besides his interest in virtualization technologies and blogging, he loves spending time with his family as well as snowboarding, playing basketball and rowing. He is fluent in Dutch, English, German and Slovak and speaks some Spanish.

Leave a Reply

Your email address will not be published.

*