After updating in the last couple of days to the current VirusScan Plus and attempting a "full scan" I stopped it once Task Manger eventually showed the System process having well over 2,000,000 handles open. handle.exe -s reported that the big 2,000,000+ count was for thread handles, even though System only had 185 or so active threads (as I remember). It appears that thread handles are being created and not being released but at least the threads are being stopped. (Some .NET vintages require forcing finalizations periodically to avoid this for its internal thread usage but I've not demonstrated that .NET is at fault or that the specific possible workaround would fix anything.)
The 2,000,000+ thread handle count was for having processed somewhat less than 700,000 files spread across 2 partitions. The count increased during processing of both partitions, the smaller one with far fewer files completed before the scan started on the bigger partition. It was working on the big partition with 2,000,000+ files when I stopped it. If I only had the smaller partition mounted I'd not have noticed the issue.
The PC in question has Windoes 7 Pro x64 SP1 and 16GB of RAM and so does not force garbage collection for running low on memory in this context. (I was not running anything else explicitly.) Depending on memory pressure to clean out thread handles is not be a good thing if that is effectively what is happening.
The progress rate of the scan was slowing greatly, apparently from overhead from the continued accumulation of non-released thread handles. My guess is that it would have run more than 24 hours more after having run 8 hours+ already as of when I stopped it.
Pausing the scan stopped the accumulation of thread handles during the pauses, as did stopping the scan and waiting before trying again. But the count did not go away either. And soon after trying again or resuming the count was increasing again.
I've no clue if the scan itself is directly requesting the thread handle creations vs. if it is more indirect. But only during the scans does it happen based on what I've seen.
Hopefully McAfee can fix or work around the leak issue so that I (and others?) can scan more than the small parition completely.
Technical questions like that are best left to the experts at Technical Support as they can troubleshoot it directly. It's free by phone or online chat and linked under Useful Links at the top of this page.
That said, I haven't seen that behaviour here in Win 7, Vista or Win 8.1. Just check that everything is up to date, especially IE as McAfee uses IE for display and function, even if your defualt browser is something else.
For 7 it should be IE11. Settings best at default and make sure the add-ons are also up to date.
Can you please provide more information on the issue that you are facing?
I started a full scan. Before starting the scan the total handle count was ~38300. When Scan was running total handle count increased to ~39200. I did not see a huge handle count number.
I have not yet gotten back to experimenting with this. Good to know that the System Process does not get the large handle count for other folk's context. It gives hope that I can isolate something that makes a difference for if the issue happens or not --once I get back to investigating this.
It was interesting that it was the System Process and not a McAfee process that got the large handle count (that turned out to be thread handles). The actual/active thread count was reported as vastly smaller than the handle count.
I will post here again when I have more information. But it may be a while before I can spend the time.
I have isolated the context in which the handle count in the System Process continually increases:
BOOTCAMP partition (NTFS file system) booted with the Macintosh HD partition mounted as HFS and Macintosh HD is actively being scanned.
BOOTCAMP has a Windows 7 Professional x64 context for its NTFS file system.
The scan of the BOOTCAMP partition/NTFS file system itself does not result in the problem. But once a scan progresses to the HFS partition/file-system the handle count increases as described.
(I was apparently wrong before about the increase happening during the NTFS scan as well.)
Running that NTFS partition under Parallels and scanning the Macintosh HD HFS file system does not have the problem. But Parallels does not make that file system visible directly as HFS to Windows.
So overall the problematical handle count increase seems to involve Apple's implementation of HFS for Windows.