We see it all the time. It’s been random although we have somewhat narrowed it down to when we are in the Take Action screen and click OK - when the action is being committed to the BES Server it happens.
If it was just the console, it wouldn’t be so bad, but we have users calling in left and right. For now they are just clicking past the errors but it’s annoying.
Is there any way of getting a client log and time of occurrence so we can see what it was trying to do? For the console case, what fixlet are you trying to deploy as an action?
This hasn’t been seen before so it may be very driven by content.
I did send in my client logs and screenshots of the error to support (Case # 00054330). We are trying to collect a minidump for them now, as they couldn’t see anything in the logs.
We have now determined this error occurs on both servers (2003) and workstations. We can’t find the ryme or reason yet though. So far we’ve seen it on 1 server (out of 300) and about 20 workstations (out of 1500). There may be more occurances on servers, but haven’t gotten a chance to check them yet. We also may not be getting reports from end users for all of them (as some users will just click OK past it so they can continue working, and not report it).
When it happens in the console it’s with all kinds of content. We’ve seen it with the console on Vista and Win7. Seems to happen more if you click off the status windows while the action is being sent to the server.
Event log show these errors:
Faulting application name: BESConsole.exe, version: 8.0.584.0, time stamp: 0x4c5ca0d8
Faulting module name: BESConsole.exe, version: 8.0.584.0, time stamp: 0x4c5ca0d8
UPDATE: We were using a task called “BESClientUI is Not Running” that restarts the UI if it’s not running. We think this was causing the crash. When we stopped this action from running, it seemed to clear up the errors on our endpoint agents. We had been using this action from an older version we were on that had an unstable BESClientUI.
Interesting… we see this just popping up on our end as well. This is after about 30-45 mins of an initial install.
Comparing the Eventlog with the BES client log, the last thing to happen is:
At 19:20:44 -0600 - actionsite (http://:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded setting “_BESClient_ActionManager_UIEnableMode”=“local” on “Fri, 31 Dec 2010 14:52:51 +0000” for client (fixlet 113)
Command succeeded runhidden cmd /C net stop besclient && net start besclient > NUL 2> NUL (fixlet 113)
At 19:20:44 -0600 -
ActionLogMessage: (action 113 ) ending action
At 19:20:44 -0600 - actionsite (http://:52311/cgi-bin/bfgather.exe/actionsite)
Not Relevant - BES Client Setting: BESClientUI Enable Mode (fixlet:113)
At 19:20:44 -0600 -
ShutdownListener
At 19:20:45 -0600 -
Client shutdown (Service manager stop request)
At 19:20:47 -0600 -
Starting client version 8.0.627.0
FIPS mode disabled by default.
According to the Eventlog, the Service was sent a stop control, the crash happened, then the service stopped, so the restart of the service is causing this on a few servers.
I’ve been advised by support this is a known issue (bug # 38832) which no resolution yet. I have tested deploying the same Baselines on the 8.1.551 platform which seems to work okay, however this was with SQL 2005 instead of 2008 which I have running in production.
Can anyone whose exhibited the same issue, confirm what version of SQL they are running, and also any gotcha’s with upgrading to v8.1 db/console so early… ? I suppose my question is, how buggy is 8.1.551 ?
I can confirm that our issue was resolved with the 8.1 upgrade. But our issue seems slightly different, albeit resulting in the same error message. FWIW, we are running on SQL 2008.
I can honestly say that at this point we have not experienced any new bugs with 8.1
Running bes client 8.1.551.0 on windows xp and getting Program: C:\Program Files\BigFix Enterprise\BES Client\BESClient.exe R6025 - pure virtual function call"
