How many handles? I also use that version, and while I haven't done a trace, I do have Handles added to Task Manager, which should be the same thing. The system has been up 11 days, and the figure is only 1580 for that process. Something else on your system might be interacting with it in some way.
Later versions do leak to this site, but I think they're not released officially via Intel for a reason, so beware.
After 12 hours the IAStorDataMgrSvc.exe is at 1700+ handles.
I dumped the process and do not see anything else in the stack that is interfering with the process.
I have updated the drivers to the latest before this posting. The drivers are not the issue it is the user mode management piece that is slowly bleeding my computer to death.
The leak is manifesting itself within a process that was created and is owned by Intel. This is who needs to come to the table and address the issue.
If Intel does indeed come to the table they and point the finger a someone else the need to provide hard data why it is not their responsibility.
I'm reminded of the most famous scene in "Crocodile Dundee."
Unless it grows to be a lot higher than 1700 (add another digit), I wouldn't be concerned. Post back tomorrow and let us know what it is then.
My Outlook.exe right now, which I've had running for 8 hours, is close to 2000.
I've seen notable handle leaks before, and they reach much greater heights in much shorter amounts of time. One I remember vividly was some support software that came with Broadcom, and it was over 20K. Skype had the problem once upon a time as well.
It's a handle leak. 100%
Any process over 1500 handles should be investigated for leaks. I have seen processes run at 24000+ handles but never build. It the leaking that robs you machine of resources.
Considering that when the service is cycled it is at ~250 and the handle count continusly builds over time.
I will post the handle count again tomorrow.
Are you sure that it's the increasing (which it's doing, but sloooooowly) and not the number itself that matters? Offhand I'd be much more concerned about a task solidly sitting at 24K than one that's approaching 2.5K over nearly two weeks, but I haven't looked into all this for a while. So you're saying if something jumps right to a high number, then resources aren't being consumed to any notable degree as compared to what this service is doing?
I remember in the case of the Broadcom NIC software, it was the "Paged Pool Memory" that increased dramatically along with the handles, and that had a terrible effect on some functions of the machine. MS has a tool called poolmon.exe that I recall using to watch it.
I am running 10.6.0.1002, and it behaves similarly. I have to agree, this is a problem. Maybe not deserving of the phrase "...bleeding my computer to death...", but still a problem.
It appears that thread handles are not being disposed correctly. After just 5 hours of uptime, IAStorDatMgrSvc is showing 3,414 handles on my machine. It keeps creating threads (and handles for each), but when the threads complete the handles are not released.
This causes the process' working set memory to continually increase as well.
Not a huge problem for someone who reboots every few days, but it could be problematic for a machine that is expected to run for weeks without reboot. I hope Intel finds/fixes it.
Here is how it stands.
After restarting the machine last night at 8:25:32 PM CST I observed the handle count of the IAStorDataMgrSvc.exe to be at 253.
Log Name: System
Date: 2/19/2012 8:25:32 PM
Event ID: 6009
Task Category: None
Microsoft (R) Windows (R) 6.01. 7601 Service Pack 1 Multiprocessor Free.
Less than 8 hours later the handle count is 2155.
The analysis of the thread creation looks to be a possibility. I see the thread count alternate between 10 and 11 threads.
If left unchecked this would eventually resource starve a machine.
I have a case with Intel support on this issue. I will post the interactions.
1 of 1 people found this helpful
Maybe, maybe not, but enough facts aren't in evidence yet, and restarting the machine didn't help your case. I'm at 2200 in about 12.5 days. Working set memory 21MB, peak 25MB, but I don't think it's the process's RAM that's at issue anyway. Not exactly a 3-alarm situation.
Update: One hour later, no reboot: 1,773....
1 of 1 people found this helpful
After watching this a while, it appears that IAStorDataMgrSvc does a periodic cleanup/release of handles. At least that is what I see happening on my machine. YMMV.
I noticed this once while just looking at current handle count in TaskMgr. So I setup a perfmon session to monitor it over time. It shows the service slowly increasing handle usage -- until it gets to around 3400. Every time it gets close to 3400, it quickly drops back to about 1600. Then it starts slowly building up again, gets close to 3400, and quickly drops back to 1600. I watched this several times. (Snapshot attached showing one example.)
When I dump the process, there are tons of thread handles for threads that no longer exist. Hence my earlier comment that the service is is creating threads, but not releasing the thread handles as each thread completes. But it does seem to periodically release the old handles.
Just for comparison, MS Outlook grabs over 5,000 handles at startup, and ccsvchost (Norton AV) routinely holds 3,500 or more.
As long as it periodically releases the handles and keeps itself under a reasonable threshold, I don't see it creating any long-term problem with resource usage. You may want to setup perfmon to capture activity over several hours, and see if it acts the same way on your machine.
Enough facts to convince a Sr. Microsoft engineer to suggest opening a case with Intel.
Any time there is a leak that can be seen in Task Manager it should be addressed.
What OS, Service Pack, and SKU are you running? Is your boot drive a RAID 0 set? Are you using SSD? There are many variables and many different code paths. In my case I have a resource leak. The reason why is not know but since it is in Intel code that's who should make the first effort in determining the source of the failure. Just because you do not see the issue does not mean it does or does not exist.
It unleaks though, as I amended in my earlier post and as Alan just mentioned. Is yours purely a one-way ticket?
I've had some dealings with support at MS too, and they very much like recommending you to the vendor in question whenever it's not purely MS-related, in this case rightly so. I hope Intel doesn't refer you to MS.
This is a clean W7 x64 SP1 from late last year. 8GB RAM. I am using SSD, but just as a normal SSD (i.e. not a caching drive). No RAID.
If it maintains control of the handles and periodically releases them (as it appears to do on my system), then it is not a really a "leak." It might not be the most efficient design, or there might be a really good reason for a periodic reclamation vs incremental reclamation.
Take this from a senior software engineer that worked somewhere with much tighter standards than Microsoft. And keep in mind, support staff at CompanyA are always supportive of you opening a case with the staff at CompanyB. And vice versa. :-)
That said, you have a different system and may indeed have a problem -- I don't know. But I suggest (again) a perfmon trace of IAStorMgrSvc handle consumption that spans several hours to see whether there is constant growth (which would indicate a leak) or cyclic growth/reduction within bounds -- which would indicate that the application is maintaining record of handles and releasing them in a managed way.
Either way, good luck and let us know what you find.
I am in the process of doing a Perfmon for at least 24 hours that you and Alan had suggested and will post the results. We will see if this is the same as what you both have seen. If it is managing itself then I will just leave it. Really I hope this is the case.
Thanks for your input and guidance.