1 2 Previous Next 13 Replies Latest reply on Mar 14, 2008 10:27 AM by lorennerol

    VS 8.5i patch 4 excessive handles used Win2k3 64bit

      I am working with Microsoft PSS on an issue with a Win2k3 64 bit server that is leaking memory and bluescreening. We've found that FrameworkService.exe *32 is using far more handles (as shown in task manager) than it should- as many as 20,000. A review of the same software running on a 32 bit install of Win2k3 doesn't show this (handles in the low hundreds), but a check of another low-use 64 bit machine shows almost 10,000 handles in use.

      Anyone else seeing issues with 8.5i in a 64 bit environment?

      L

      Edit to add: I rebooted this server tonight. Before doing so FrameworkService.exe was using 53,000 handles. It sure would be nice to hear from McAfee/NAI on this issue.
        • 1. RE: VS 8.5i patch 4 excessive handles used Win2k3 64bit
          We are having great difficulties with 64-bit servers running Exchange 2007. The Hub Transport and Edge Transport servers get extremely slow -- to the point that simply logging onto the server can take 10 minutes or more. Strangely, there is no memory, CPU, disk or network overconsumption going on (a lot of spikiness on page faults, though). When we shut down the McAfee services the server suddenly regains life. This happens about once a week. We have had great difficulty with McAfee support on this.

          Please feel free to contact me if you'd like more information. I'll look at the handle counts next time I see the problem.
          • 2. RE: VS 8.5i patch 4 excessive handles used Win2k3 64bit
            Same symptom here: Server gets progressively slower, until it's essentially non-responsive. If I let it go it will bluescreen. I already had to remove Groupshield from it due to excessing processor utilization and it looks like VirusScan will be next. I've been using McAfee AV software for over a decade; it's sad that's the quality has gone downhill so significantly in the last year.

            The handles issue is present on 64 bit servers without Exchange 2007- I've checked two of them.

            :mad:
            • 3. RE: VS 8.5i patch 4 excessive handles used Win2k3 64bit
              Here is the final response from Microsoft PSS:

              "I have reviewed this case and I think that I have found what is most likely causing the performance issues for your server. There is a handle leak with the process FRAMEWORKSERVICE.EXE. This process is started by the “McAfee Framework Service” service on your system. For the moment, I would postpone any changes to the system related to the reported “Server Sluggishness” and contact the vendor for assistance with this handle leak."

              McAfee? Anyone reading this who can comment on a fix, patch, or workaround, or do I need to replace your product?
              • 4. RE: VS 8.5i patch 4 excessive handles used Win2k3 64bit
                tonyb99
                You need to actually contact mcafee not post on here if you want them to look at this, this is user led support.

                what version of the epo agent is installed (generating the frameworkservice)
                3.6.???
                • 5. RE: VS 8.5i patch 4 excessive handles used Win2k3 64bit
                  favorini
                  Any updates on this? Any chance patch 5 fixed it? What patch are people running on Win2003 x64 machines? Are any of the 8.5i patches stable on this platform?
                  • 6. No fix with patch 5
                    Patch 5 does not fix the problem. The first box I put it on was right up to 23,000+ handles in use within days.
                    • 7. RE: No fix with patch 5
                      favorini
                      Bummer. Did you get any answer from McAfee on this? Did it first start with Patch 4 or was there a problem with Patch 3, too?
                      • 8. RE: No fix with patch 5
                        I never contacted them directly. Someone else said they had and just wasted a bunch of time and energy getting the usual "No one else has reported this problem. It must be something in your environment" run-around.

                        I don't know when the problem started, or if it started with one of the patches.
                        • 9. RE: No fix with patch 5
                          ICHAPMAN
                          Aren't you looking in the wrong place - FRAMEWORKSERVICE.EXE is a component of the CMA.

                          AFAIK The CMA is 'normally' used to manage VirusScan (and other products) from the McAfee management systems like ePO and PPP. Having said that in a standalone environment VirusScan 8.5i will also install the CMA to handled updates etc.

                          Anyhow, my real point is that I don't believe the VirusScan Patches actually address issues with the CMA - they are purely the VirusScan system itself. The CMA is normally listed seperately on the McAfee Updates (My Support) site.

                          What version of the CMA are you running?. If you have the McAfee CMA Shield showing you can right-click and select About to get the version, or if not I think you can look at the version of FRMINST.EXE or UDaterUI.EXE to get a version number. Certainly on my system the version number of these files shows the same as the About screen.

                          The current version appears to be 3.6.0.574 (CMA 3.6.0 Patch 3), released 28-11-2007 (from the readme).

                          Looking at the McAfee Knowledgebase, CMA 3.6.0 Patch 1 (3.6.0.546) addressed a similar issue:
                          (https://knowledge.mcafee.com/SupportSite/search.do?cmd=displayKC&docType=kc&exte rnalId=612771&sliceId=SAL_Public&dialogID=25328548&stateId=1%200%2025330092)

                          7. ISSUE:
                          A handle leak was discovered in the Common
                          Management Agent on Microsoft Windows 64-bit
                          machines. When the 32-bit framework service
                          attempted to retrieve the Process ID of a 64-bit
                          process, it abandoned approximately three
                          handles per call.

                          RESOLUTION:
                          The offending routine has been modified to close
                          all opened handles.



                          Finally - my aplogises if this was information you already realised / had checked. I'm just trying to be helpful!.

                          Regards

                          Iain
                          1 2 Previous Next