At our workplace we run VSE version 184.108.40.2060. This seems to run without problem for most people....except for me. I seem to have this issue that pops up about every month or so where UDaterUI starts to hog more and more memory until the blue screen of death happens.
I attach a screenshot of the task manager processes. Take a look at the handle count of UDaterUI.exe. It keeps rising at a steady rate every second.
Upon forcefully ending the UDaterUI.exe application, memory use plummets to more normal levels.
As satated, it only seems to happen every month or so (last incident on 16/01/2013). Otherwise it seems to work fine.
I can't find anything on the interwebs about an excessive handle issue on UDaterUI.exe. There has been talk about excessive I/O reads but I don't think it's related to this.
If any of you have any ideas on what is going on, it would help me out greatly.
We have watched the same growth of Handles UdaterUI.exe , randomized over all the environment.
Only restart helps.
McAfee Agent 220.127.116.1135,
VirusScan Enterprise 18.104.22.1689
Host Intrusion Prevention 22.214.171.1241
The Problem came up, when migrating from HIPS 7 to HIPS 8
- upgrading Agent or HIPS doesnot help.
Welcome to the forums.
Look at the Paged Pool number on UDaterUI, as well. I have seen this before and though it might be different for you, I was able to fix this problem by updating my Network Adapter Drivers, and NDIS drivers. I used the adapter manufacturer's site (Intel, Broadcom, etc.) for updates, not the OEM (such as Dell, HP, etc.)
The timing sensitive interaction of HIPS, McAfee Agent, and network interface might explain the problem if the network adapter drivers or NDIS, are out of date.
Post back if this helps.
i can't imagine that it would help now to update our Network-drivers that always worked fine and mainly signed by Microsoft.
I guess we are watching here a failed start of the cma-Agent.
if we turn off Access-Protection and kill both: UdaterUI.exe and Frameworkservice.exe
than we see a XP-System working normally again.
After that restarting by the Command: Frameworkservice /ServiceStart
the Agent comes up normally and it works without restarting the PC. (but this is no alternative for end-users)
@acv_critter: take a look in you Log.:
FrmSvc Starting Subsystem <User Space Controller>
e #572 FrmSvc Fehler beim Starten des Teilsystems '<User Space Controller>'. Ergebnis: -1701
I #572 FrmSvc Starting Subsystem <Management>
I #712 Manage Mangement plugin watch worker thread started
I #572 Manage CManage::Start() Initialize() -- failed result=-1701(0xfffff95b)
So, are you seeing the Exact problem that acv_critter reported? (Page Pooled and Handles?)
The point of posting to a public forum is to get perspectives for which 'I can't imagine,' might help.
My experience in this area was exactly that, 'experience.' An application developer updated their software on our server. What should have been a standard update caused problems as acv_critter described. Went back and forth with the developer who claimed that they made no changes that would explain this behavior.
After exchanging many dumps, debug information, and extensive testing, I found that though the developer did not change their code, they did update the development environment. The updated compiler used new, standard libraries, which changed the network interface code. This forced the need for an updated NDIS and network driver on an otherwise Highly stable production server. It appeared to be a timing issue, making the diagnosis easily masked by using faster hardware. It wasn't until I updated the network drivers (which also forced an update to NDIS) that the system was made stable again. (Of course, the developer accepted No responsibility for this issue.)
I have found that brand new systems, usually have outdated drivers, right out of the box. Just because you think that the drivers are new, does not make it so.
I am not suggesting changing drivers capriciously, but rather in a test, to see if it helps. One can always revert back if no benefit is seen.
In your environment, per your post, is the problem Solved by simply restarting: Frameworkservice /ServiceStart
or does the problem slowly build up again after UDaterUI.exe kicks in again?
Error "1701 The binding handle is not the correct type" does indicate a problem with Handles, so I would be interested if acv_critter is having the same issue. However, this does not lead us to the cause, it is just a symptom. (I am not sure if -1701 is the same message as 'Net' HelpMsg 1701, but I am making that assumption.)
If the updated HIPS or the McAfee Agent was 'Tuned' for better performance, this could possibly be causing these issues.
My questions would be to McAfee:
What differences are there between HIPS, McAfee Agent, and UDaterUI.exe and how Handles are opened and closed?
What changes would explain these behaviours reported here?
What versions, patches, and hotfixes, of each are required to work reliably together?
What version of NDIS is required/recommended for proper operations?
Should QoS be enabled/disabled?
Thanks for the info you have provided. Do you have any other diagnostic info or testing you can provide?
Thanks for the reply,
Ron MetzgerMessage was edited by: rmetzger (spelling error, additional questions to McAfee) on 1/21/13 3:41:57 PM EST
We are very deep into getting Process-Dumps with the ProcExp.exe of UdaterUI, Explorer and Framworkservice.
In the UdaterUI we do see the symptom. there ist another instance that is triggering the handles going up.
If i stopp the FramworService in SERVICES the operating System says: the Service is allready going down.
than the FramworService stops an the problem ist gone.
If restart the FramworService in the same session, you can work normal with the computer.
the next step is to catch up a complete MEMORY.DMP.
McAfee Tier III will take a deep look into it, to find out in what a messy situation the services are.
Please keep us updated. I've had a ticket open with support for a couple of months as we've tried to figure out the cause of this. We've tried countless things. What is particularly odd is that the problem comes and goes. We haven't seen it in over a week, at least (though I expect it to return).
One thing I recently observed is when I remote into the machine and the agent interface does not load, udaterui doesn't have an issue. When I load the agent (cmdagent /s) the issue begins. I noticed this with a server where the agent hadn't communicated in several days.
DaveMessage was edited by: Daveb3d on 2/8/13 2:20:43 PM CST
You say the problem happens about once a month. But which is it:
A. During the month, the number of handles udaterui is using is slowly but steadily increasing. Finally, after a month of this, it reaches a threshold where you can't use the computer.
B. During the month, number of handles udaterui is using stays low (ex. < 200). But then suddenly one day it jumps up to be very high (ex. > 10,000).
We've done a reinstall of the McAfee enterprise software on my computer. I will monitor for the next month and let you know if UDaterUI rears its ugly head again.
Cheers for your input and discussion.
Here's an email thread I've been having with Daveb3d. It might give you some more food for thought.
I emailed to him:
Thanks for posting. Do you haveany ideas about my previous question:
>Yousay the problem happens about once a month. But which is it:
>A.During the month, the number of handles udaterui is using is slowly butsteadily increasing. Finally, after a month of this, it reaches a thresholdwhere you can't use the computer.
>B.During the month, number of handles udaterui is using stays low (ex. < 200).But then suddenly one day it jumps up to be very high (ex. > 10,000).
I could write a diagnostic version of udaterui which would log whenever it creates athread. It should never create them frequently, but maybe there's somethingthat is making it happen more often. If the problem is happening continuously(as in A), then we could put the diagnostic on a computer and get immediateanswers.
We'vehad machines have it twice in one week, but the answer would beB. The issue will start and within an hour the handleswill skyrocket to the point where network activity stops. The only way toresolve it is to restart the framework service or kill the udaterui process.
Here is a bit more for you that might (or might not)help: I came across a server that hadn't communicated in for a fewdays. I logged into the server remotely, so the agent interface did notautomatically load. When I loaded it with cmdagent /s I immediatelysaw the error (as it scrolls through the agent log that it isn'trunning). I checked udaterui and it was only at the point ofopening this that the handles began to increase. Incorrelation to this, a workstation may be on overnight, but the issue doesn'tseem to show itself through a network failure until somebody logs intoit.
What is particularly interesting is we'll sometimes go lengthsof time without having the issue reported by users. Desktop supportrecently asked me if I fixed it because they haven't seen it within the pastcouple of weeks, but I haven't done anything.
Here ismy reply:
This is very interesting. You said:
>I logged into the server remotely, so the agent interfacedid not automatically load.
Quite right. That's because UdaterUI doesn't automaticallyrun for remote sessions.
>When I loaded it with cmdagent /s I immediately saw theerror (as it scrolls through the agent log that it isn't running).
What exactly do you mean by "as itscrolls through the agent log that it isn't running"? Some sort of errorappears in the Agent Monitor display? Or…?
>I checked udaterui and it was only at the point of opening this thatthe handles began to increase.
Right. The handles are insideudaterui and allocated by udaterui (but I don't know why). If udaterui isn'trunning the problem doesn't occur.
>In correlation to this, a workstation may be onovernight, but the issue doesn't seem to show itself through a network failureuntil somebody logs into it.
UdaterUI only starts when someone logs in, therefore thismakes sense.
It sounds like you're saying that when UdaterUI starts, theproblem starts. It isn't a slow build. It could be that the problem only occursonce a month for some people because they only log on non-remotely once a month.