BESClient "hung"...but not really

Hey all,

We’ve been seeing some odd behavior, and I am wondering if any of you have seen similar. We have had 100-ish systems that we were seeing the last report time that was out further that we wanted it to be (these are remote employees), and at first assumed it was an issue with them slacking on the job LOL! When we started digging into these systems we are seeing the BESClient process running, but it is like no one is home.

Checking logs shows the last entry on the last day it reported in, but then nothing. It’s like the process hung, as nothing in the logs indicate issue with it not being able to send reports or anything related to finding relays, etc. It’s odd… we have to kill the BESClient process and it restarts and works fine - checks in, sends reports, and can fixlets on them again.

These are all windows desktop systems, and we keep them up to date with patches and versions. I have no turned on any debugging on any client, as restarting the client fixes the issue and it has been very random. I’ve had to MacGuyver a “fix” to use Bigfix’s api in powershell to get systems who are offline, then use that data via our antivirus’ API and run kill commands on the BESClient process… it works, but not sure why the client is behaving this way. Any ideas or reports of this happening to you all?

What version are the clients? I heard reports some while back that evaluating Windows Defender analyses was hanging the client when the WMI calls involved would hang the process, but I think it was fixed several versions ago.
If it’s happening repeatedly, turning on BES Client debug logging is helpful to tell us what content it was evaluating when it stopped processing.

1 Like

We are on 10.0.1 on everything across the board. I’ll try the defender analysis first; I hate to turn debugging on everywhere with these crap-tastic computers our users have. :confused: It’s so random that it would need to be on everywhere just to catch it…unless I am missing something.

This sounds almost exactly like the issue we’ve just faced and had to raise a P1 for.

Admittedly we know what caused ours to do it but it sounds like your agent state is in the exact same state ours was.

@cmcannady is this potentially the same issue here?

@FatScottishGuy, it’s difficult to say as we’d have to get BESClient and debug logs from both environments to compare in order to determine with any confidence. That said, I don’t have the Windows Defender site in my lab and can’t currently add it to check the analysis in question for descendant folders of folder relevance causing issues.

1 Like

@FatScottishGuy - sent you a PM. @cmcannady, I checked that yesterday, and the analysis are not enabled. :frowning: I had high hopes for it too.

Quick update:

I found a system having this same issue and looked at the logs. The last log entry on it was:

At 13:06:06 -0500 - BitLocker Management (Labs) (http://sync.bigfix.com/cgi-bin/bfgather/bitlocker)
Relevant - Bitlocker - Candidate for Drive Encryption (fixlet:5)
At 13:06:06 -0500 - Windows Defender (http://syncbf.xforce.ibmcloud.com/cgi-bin/bfgather/windowsdefender)
Relevant - Windows Defender - Update Signature Definitions from Cloud (fixlet:2)

Every instance I have seen this has had that Bitlocker Management site enabled, and I am thinking it may be the culprit. We have had zero instances of this on any windows server in the datacenter, and the relevance for that site specifically had it set to Win10, which is where we have been experiencing the issue. It’s been random, so not sure why we are seeing it like we are, but it caught my eye.

There was also a Bigfix Manager for Windows defender that was enabled, but no analysis were enabled, so I unsubscribed everything from there as well. Going to see if this helps, and will update what I see for anyone else who might have similar issue.

1 Like