1 2 Previous Next 13 Replies Latest reply on Dec 14, 2011 5:36 PM by wwarren

    VSE 8.7 Patch 5 Event ID 514 mfehidk errors

    passmaster16

      Hi,

       

      I just opened up a case with McAfee for this issue, but in the meantime, I thought I'd post here as well.  After upgrading our VSE clients from 8.7 SP3 to 8.7 SP5, we're seeing a proliferation of event 514 (mfehidk) warnings in the application event logs.  Process **\SVCHOST.EXE pid (pid#) contained unsigned or corrupted code and was blocked from performing a privileged operation with a McAfee driver.  The messages appear to occur shortly after bootup.  We've attempted to identify third party hooks using procmon and procexp per https://kc.mcafee.com/corporate/index page=content&id=KB71083 and https://kc.mcafee.com/corporate/index?page=content&id=KB71812 but have been unsuccessful.  Attempts to upgrade msi.dll were also unsuccessful.  We're running McAfee agent 4.5.0.1810 but upgrading to 4.5.0.1852 did not make any difference. 

       

      McAfee support is advising us to upgrade to VSE 8.8 but from reading these forums, I'm not convinced that 8.8 would resolve our issue.  I suspect that something on our machines is trying to hook into the McAfee driver.  The problem is we haven't been able to determine what it is.  While the error appears to be benign, our customer would like to know what's causing it.  Any insight would be appreciated.

       

      Thanks in advance!

       

      on 12/7/11 10:28:39 AM CST
        • 1. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
          wwarren

          You'd need to show us the DLL View of ProcExp when having SVCHOST.exe selected - and it would need to be the same instance as described in the Event (since there are many instances of SVCHost running at any given time).

          • 2. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
            passmaster16

            I exported the list of dlls of the svchost process specified in the event log warning.  While there are a few Novell dlls (yes we still use novell ) the majority of them seem to be Microsoft.  Of course since this issue appears to occur at startup or shortly thereafter, I'm not certain if some of the dlls drop out of procexp so this list may be incomplete.  See xls attachment

             

            Thanks!

            • 3. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors

              upgrading to 8.8 won't make any difference, in fact that is when we started receiving these errors.  I too opened a support case many months ago...we identified the dll's and I was told that virusscan was operating correctly and there was nothing to be done.  In order to fix the problem, I needed to contact all the third party vendors to tell them to rewrite their code to play nice with the Mcafee executables.  Yah, that is going to happen.   In a more recent case, someone at support said they were going to revise something to minimize these jazillions event log entries.

              • 4. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
                passmaster16

                Thanks, right now I'm dealing with tier 1 support and they're just giving me the runaround.  I don't have a problem if it's a third party app generating the warnings but I need to prove to the customer that the messages are benign in nature.  Our customer is concerned because we didn't encounter the problem until upgrading from VSE 8.7 P3 to P5.

                • 5. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
                  wwarren

                  passmaster16 wrote:

                   

                  I exported the list of dlls of the svchost process specified in the event log warning.  While there are a few Novell dlls (yes we still use novell ) the majority of them seem to be Microsoft.  Of course since this issue appears to occur at startup or shortly thereafter, I'm not certain if some of the dlls drop out of procexp so this list may be incomplete.  See xls attachment

                   

                  Thanks!


                  The messages stems from the Novell DLLs. They obviously have some code that triggers an interaction of sorts with VSE code, which in turns causes us to do a validation check - and since it's a 3rd party, we don't trust their code = Event 514 or 516.

                  The sister KB article has additional information to help you in finding a resolution, you really only have one choice:

                  https://kc.mcafee.com/corporate/index?page=content&id=KB71083

                   

                  The Novell code has to be trusted in order for the events to not occur (assuming that's your goal) - the KB explains how to go about having McAfee trust your 3rd party app. Otherwise, you can just ignore the events.

                  • 6. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
                    wwarren

                    passmaster16 wrote:

                     

                    Thanks, right now I'm dealing with tier 1 support and they're just giving me the runaround.  I don't have a problem if it's a third party app generating the warnings but I need to prove to the customer that the messages are benign in nature.  Our customer is concerned because we didn't encounter the problem until upgrading from VSE 8.7 P3 to P5.


                    Perhaps have that customer read the KB71083 article I shared. It's contents are perfectly relevant, and informative as to why this issue occurs only since going to VSE 8.8 or VSE 8.7i P5.

                    The behavior is not going to change, for reasons explained in the article.

                    • 7. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
                      passmaster16

                      Thanks for the insight.  So McAfee will trust any Microsoft or McAfee DLLs by default but will not trust anything else?  It would be nice if McAfee had a tool that could tell us exactly which DLL file is trying to hook into VSE.  Using procexp is basically a process of elimination.  I'm assuming the primary reason why McAfee started logging these events in the first place is to notify us if malicious code was attempting to interact with VSE.  I think we can convince our customer that these particular warnings are caused by the Novell DLLs, but their concern will be the fact that we always have these events so it would be tough to separate a legitimate warning from this "noise".  As you already mentioned, per KB71083, if we wanted to suppress the Novell based warnings, we'd have to export the certificate, generate an exe, then run that exe on every single machine, and we'd have to do that for each Novell DLL that is listed in procexp.  Since the messages occur on bootup, I'm not certain that we're seeing the actual processes that are causing this issue.  Couldn't there be additional processes that are dropping off prior to getting logged in and viewing them in procexp?

                      • 8. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
                        wwarren

                        passmaster16 wrote:

                         

                        ...Couldn't there be additional processes that are dropping off prior to getting logged in and viewing them in procexp?


                        Plausible but unlikely. I'm yet to come across an app like that. If not "Process explorer" then "Process Monitor" would be even more effective, and would be able to catch any dynamically  loading/unloading DLL.

                        But, you've already shown the Novell DLLs are present in the affected process cited in the event. So, that needs to be eliminated first anyways - if something remains it can be looked at again.

                         

                        Support can help with providing a SuperDAT package to make it easier importing the .cer file for the 3rd party you wish to trust. It'll just need escalation through to Tier 3 (me).

                         

                        As for multiple .cer files because of multiple DLLs, that all depends on the app. If they've used the same signature in their signing of files, we only need the one. But yes, if a separate digital certificate exists for each DLL, send them all in and we can have them all be trusted.

                        • 9. Re: VSE 8.7 Patch 5 Event ID 514 mfehidk errors
                          passmaster16

                          I've tried using both process monitor and process explorer to isolate the suspect dll, but  I couldn't really see any more in procmon than I already knew from the event log and procexp.  I see the Network Location Awareness service opening or querying mfehida.dll, but I don't know what specific dll is causing it.  Since it's a Microsoft service and using Microsoft libraries, I would assume it would be trusted.  I did not see anything Novell related that seemed to be referencing mfehida.dll in procmon. At any rate, I was going to try removing all the Novell components off a test machine and see if the error persisted. 

                          1 2 Previous Next