4 Replies Latest reply on Apr 16, 2013 9:36 AM by dmease729

    Clarification required on McAfee profiler output - how counts are determined




      I have a few queries on the results I have recently obtained from McAfee Profiler, in an attempt to determine why mcshield.exe CPU usage shoots through the roof when certain operations are performed on protected servers.  From first look at the output, it would seem like I have fairly conclusive proof of what executables are involved, with a fair idea of where the I/O is, however I am confused over a number of things.  The majority of scanned operations look to come from MYEXE.EXE and MYEXE2.EXE (sanitised output), as can be seen from 'top 10 processes', below.  The majority of scan operations also appear to be focused around FILE1.DLL and FILE2.SDB (again, sanitised), as per 'top 10 files', below.  I can confirm that on the top 3 files for the top 10 processes (again, below),

      against MYEXE.EXE, the 12474 count is against FILE1.DLL and the 7451 count is against FILE2.SDB.  Looking at the top 10 processes with read/write count below, I can deduce that the majority of these accesses are READ operations.  My initial questions are:


      1) What is the count against?  Each time the process in question asks to read the file or each IRP_MJ_READ system call produced as a result (larger files will result in more of these calls).  I am (hopefully) assuming the first one.
      2) If the assumption is made as above, why is the read count so high when there appear to be no writes to the target file?  Given the numbers skew, I would find it hard to believe that a large number of other processes are writing to the target file and those actions are not in the 'top 10' - this would indicate to me that the on-access scanner is scanning on each read when the file hasnt changed, which goes against what I believe it should be doing with regard to caching.


      My general recommendations (without the answer to the first 2 above) would be:


      - treat myexe.exe as a 'trusted process' - add to the low-risk process exclusions and simply disable scans on reads and writes (or exclude more than with the default processes - in this case, we could simply add the relevant DLL and SDB files as further exclusions).  This would rely on myexe.exe being a relatively 'secure' exe, with little or no known vulnerabilities and little or no total exposure to possible exploitation
      - do same for myexe1.exe


      And finally, a general question:


      3) I have output from another server that shows that the 8 of the top 10 files have an XYZ extension.  The server and application owners have confirmed that all instances of XYZ files are contained in a directory that is currently excluded (subdirectories also included).  So from that,
            3a) Does McAfee profiler only show what has actually been scanned (so nothing that is excluded should be shown).  I would hope that this was the case
            3b) After noting that the files are in 8.3 notation, does enabling 8.3 notation on a server affect the use of exclusions at all (Again, I would hope not, as the ePO install on 2008 servers requires this!). 


      At this present moment in time, I cant think of any further suggestions - could anybody possibly answer my two questions above, and provide comment?


      Help, as always, appreciated!










        • 1. Re: Clarification required on McAfee profiler output - how counts are determined

          I would suggest reporting your findings to McAfee Support to work through some potential wrinkles in product behavior you may be hitting on.

          Sure, we could find workarounds for you or configuration tweaks to produce the expected behavior but I think there may be some code-related issues at play here that should be quantified... and maybe you have the data-set or test case that will allow us to do that?


          The profiler is designed to show you the scanner's behavior; it should be an accurate reflection of what the scanner is actually doing (it integrates witih mcShield.exe to access its internal statistics). So, in that light some of what you're reporting is a bit concerning. Is it the product or is it the tool? We haven't invested much time into the Profiler tool to validate it's working 100% (not since we released it), but we're certainly interested in maintaining it if there's a problem identified with it.

          • 2. Re: Clarification required on McAfee profiler output - how counts are determined

            I had always thought that this was an unsupported product - I have looked through the Point Product list on the SR page and cannot find any mention of it - I have raised under VSE, we will see what happens :-)

            • 3. Re: Clarification required on McAfee profiler output - how counts are determined

              Using VSE is correct.

              The Profiler isn't a product; it's just a tool... one we'd like to keep around if it's proving useful.

              • 4. Re: Clarification required on McAfee profiler output - how counts are determined

                Quick update to the above.  On one of the systems in question on a recent profiler capture, I saw that the top file for the top process had a count of 64342 against it (profile over 2 hours).  On looking at the last modified date for that file I see the date of 14/07/2009. ... ... ...  So I am guessing that this was 64342 read operations, which is a little worrying?  I would suspect from this that the count is aligned to the individual IRPs, and also that given the size of the file in question (664KB) that either the on-access scanner is not caching as it should, or profiler is misreporting.


                UPDATE: Just seen your comment on using VSE on the SR - cheers for confirming


                Message was edited by: dmease729 on 16/04/13 09:36:29 CDT