BESClient.exe maxing CPU @ 100% during the workday!

(imported topic written by SDSuperiorCourt91)

Hopefully I get to finish this before my PC starts running at 100% CPU due to BESClient.exe is running. Every day the BESClient.exe runs starting approx. 9:45-10 and runs my CPU to 100% for 15-25 mins. I’ve contacted our vendor and the only answer he can give me to solve this issue is to “re-image” my machine. He doesn’t know what’s causing it, he attempted 1 solution and set the priority level for BESClient.exe to low, but the issue still remains. My question(s) to the forum is this:

(1) Does BESClient.exe run at a scheduled time everyday?

(2) If ‘yes’ to above question, how does one change the schedule to run the updating/scanning process at a later time as to not impact my work schedule?

(3) If ‘no’ to question (1) then can the BESClient be uninstalled/reinstalled and reconfigured?

This is getting extreemly frustrating and I need a solution other than “your machine needs to be re-imaged”.

Thanks for any replies.

Jimmy

(imported comment written by StacyLee)

I have seen a seen a similiar issue in the past in my deployment with 1 group on campus. The answer to your questions:

(1) Does BESClient.exe run at a scheduled time everyday?

—NO, it runs all the time but is suppose to use 2% or less CPU and is suppose to go less than that or in a sleep state if another process on the system is using a large amount of CPU to avoid contention. (more on this later)

(2) If ‘yes’ to above question, how does one change the schedule to run the updating/scanning process at a later time as to not impact my work schedule?

—Above answer is NO,

(3) If ‘no’ to question (1) then can the BESClient be uninstalled/reinstalled and reconfigured?

—There is not really anything to reconfigure.

This is getting extreemly frustrating and I need a solution other than “your machine needs to be re-imaged”.

**BigFix can correct me if I am mistaken or things have changed recently.

  1. Is this happening on all your computers or just a subset?

  2. If a subset is there anything special about those computer?

  3. Do your computer run anything around those times as a scheduled job?

  4. Do you have AV Scans, Spy ware scans, security scans, defrags or other things that could be running at the same time?

We used to run symantec AV and of it we saw the BESClient Service run up to 100% CPU at certain times. The solution for us was to upgrade to a newer version. However things you could try is exclude realtime scanning of the BESClient directory. We no longer use Symantec and we don’t exclude the directory and there are no problems.

In fact any other process you have running that scans the computer you should either disable or exclude the BES Client directory from being scanned. It may not be the solution for you to disable this but at least this will give you some troubleshooting steps that could help lead to what could be causing your CPU spikes.

Try stopping all non essentials services and see if it does it, a clean image that is not part of your Golden image.

Regards to my comment on question 1. We were wondering why 1 group of computers had a low success rate on patching and we found out that they ran an aggressive defrag between 12 am -6am that ran constantly. The defrag too so much CPU that the bigfix client went to sleep and did not patch machines. Once we shifted the defrag times it was fine.

hope that helps.

(imported comment written by BenKus)

Hi Jimmy,

That certainly sounds strange and unexpected. The way we would normally troubleshoot a situation like this is to look at the agent logs and see what it was doing for this timeframe…

No one from BigFix should be telling you to re-image your system as a way to troubleshoot/fix a problematic solution. I took a look at our case history to try to figure out what happened here, but I can’t find any record of your case… Was it a BigFix support person you were working with or was it some partner?

Feel free to email me directly with details/emails about your case and I will follow-up on it for you.

Ben

(imported comment written by SDSuperiorCourt91)

Stacy Lee

I have seen a seen a similar issue in the past in my deployment with 1 group on campus. The answer to your questions:

(1) Does BESClient.exe run at a scheduled time everyday?
—NO, it runs all the time but is suppose to use 2% or less CPU and is suppose to go less than that or in a sleep state if another process on the system is using a large amount of CPU to avoid contention. (more on this later)

(2) If ‘yes’ to above question, how does one change the schedule to run the updating/scanning process at a later time as to not impact my work schedule?
—Above answer is NO,

(3) If ‘no’ to question (1) then can the BESClient be uninstalled/reinstalled and reconfigured?
—There is not really anything to reconfigure.

This is getting extremely frustrating and I need a solution other than “your machine needs to be re-imaged”.

**BigFix can correct me if I am mistaken or things have changed recently.

  1. Is this happening on all your computers or just a subset?
  2. If a subset is there anything special about those computer?
  3. Do your computer run anything around those times as a scheduled job?
  4. Do you have AV Scans, Spy ware scans, security scans, defrags or other things that could be running at the same time?

We used to run Symantec AV and of it we saw the BESClient Service run up to 100% CPU at certain times. The solution for us was to upgrade to a newer version. However things you could try is exclude real-time scanning of the BESClient directory. We no longer use Symantec and we don’t exclude the directory and there are no problems.

In fact any other process you have running that scans the computer you should either disable or exclude the BES Client directory from being scanned. It may not be the solution for you to disable this but at least this will give you some troubleshooting steps that could help lead to what could be causing your CPU spikes.

Try stopping all non essentials services and see if it does it, a clean image that is not part of your Golden image.

Regards to my comment on question 1. We were wondering why 1 group of computers had a low success rate on patching and we found out that they ran an aggressive defrag between 12 am -6am that ran constantly. The defrag too so much CPU that the bigfix client went to sleep and did not patch machines. Once we shifted the defrag times it was fine.

hope that helps.

Stacy,

Thanks for the response. I’ll answer the 4 questions you listed above and put in something I found that I might be able to use to discover what is running when besclient takes over.

  1. Its only 2 pcs out of 2500 (my manger had same issue, our vendor couldn’t figure it out so the just re-imaged her machine, she lost a considerable amount of time and work)

  2. We all have the same standard image, I don’t have any special software.

  3. Nothing that I know of (explanation below)

  4. Nothing is “scheduled” to run in the background.

#3 explanation, I spoke with the other co-worker that has the same problem. He has downloaded a program by the name of processexporer.exe. He uses it to kill the besclient.exe in the morning when he comes to work and then restarts his machine when he leaves. He’s in the same situation I am in they (our on site vendor saic- not bigfix) want to re-image his machine instead of attempting to figure out what is causing the issue. So I’m going to follow some of the steps you have here, I’m going to run processexplorer.exe and kill the besclient.exe process before its normal start run time of 9:45-10:00 and keep the program up to see what else is running in the background, see if I can determine what’s causing the issue. I’ll write back with my results later. Thanks for your help.

(imported comment written by QXVH_Charles_Brown)

Hello SD,

Not sure how you are set up, but is your BESClient able to register with your relay or main server qucikly? If it is not able to register it could cause cause an elevated CPU for a period of time.

Also, we have seen the BESClient re-register over and over if it encounters a network event.

The example her is that the machine is connected on a wireless card and that signal keeps going in an out.

(imported comment written by SDSuperiorCourt91)

cbrown

Hello SD,
Not sure how you are set up, but is your BESClient able to register with your relay or main server qucikly? If it is not able to register it could cause cause an elevated CPU for a period of time.
Also, we have seen the BESClient re-register over and over if it encounters a network event.
The example her is that the machine is connected on a wireless card and that signal keeps going in an out.

Cbrown,

Thanks for the reply, I’m not the administrator and so I wouldn’t have the access to change any setup options. I’m also not using on a wirless connection. I’ll keep that in mind for the future if I hear of anyone having that type of issue.

(imported comment written by SDSuperiorCourt91)

UPDATE:

Today I used processexplorer.exe and killed the BESClient.exe process. I then used the same program to watch what programs are running at the time that BESClient has been pegging my CPU. I discovered that Services.exe during that time period spiked in CPU usage. Anywere from 20-60%. So I’m assuming the Services.exe has something to do with the issue. I’ll pass this information on to my adminstrator and see what he has to say. Also if you might have some insight, please post.

(imported comment written by BenKus)

Hmmm… It looks like your computer is broken and needs re-imaging… :slight_smile: Just kidding… but it does sound like something about your computer is problematic and it is tricky to track down…

And to confirm, the “vendor” you are referring to (the one that told you to re-image) was not BigFix, but instead your internal IT provider that uses BigFix to manage the systems, correct? A

One of the things that makes it a bit difficult to troubleshoot is that your BigFix Admin might be running all sorts of activities that we don’t know about it so if we can work with them to troubleshoot, it would help the most.

Ben