exsecars.log

This issue has been solved. See solution.
bjohn's picture

I'm seeing these two entries in exsecars.log repeating every minute after the RU5 upgrade.

09/27 18:16:05 [2764:2992] Get CPU counter failed. Error code: 0xc0000bc6

09/27 18:16:05 [2764:2992] Get memory counter failed. Error code: 0xc0000bc6

Anyone else?

Aniket Amdekar's picture

Hi, What is the OS on that

Hi,

What is the OS on that machine for which you are getting this error. If UAC is applicable for that OS, and delete the client from SEPM. Now, right click on the shield icon and click on update content. The client will re-register and send the complete info.

I think the UAC could be blocking the client from sending information about RAM and CPU to the SEPM.

Best,
Aniket

bjohn's picture

This on the SEPM itself,

This on the SEPM itself, running Win 2008. UAC is turned off.

Am I the only one that has this?
Although it's not a major issue, it looks like the logs are being written to every minute.

Aniket Amdekar's picture

"This on the SEPM itself" are

"This on the SEPM itself" are you referring to the Client or the location of the log.

Bacause in my openion the SEPM is trying to qury the info about RAM and CPU of client and getting error 0xc0000bc6.

Also, what is the heartbeat interval?

Best,
Aniket

Erik Kuipers's picture

I see the same behaviour on

I see the same behaviour on one of our SEPM's after having it upgraded to RU5.
It also seems that clients are not able to upload their logs anymore.

The side effect is that the Site Status report shows as "POOR" for this server because SEPM "thinks" it ran out of diskspace!


Erik Kuipers's picture

Solved for me! It turned out

Solution

Solved for me!

It turned out that the issue was that the Default Application Pool in IIS had ground to a halt due to a corrupt .tmp file in the c:\inetpub\temp\apptools directory (W2k8 x64)

After stopping the app pool from Server Manager->IIS, I deleted the *.tmp files.
Then I started the Default App pool and the clients started to upload their logs again.

Not long after that the site status showed "GOOD" again.