Endpoint Protection

All,

I'm seeing this error on one of my GUP logs ...

11:47:58.525 [1784:2524] CSylog::SetOverwriteLogTimeInterval: Error difftime returned a negative value.
 

Can someone tell me what its referring to?

I'm trying to research the error but just haven't gotted the time to as yet.

Any help would be appreciated.

Thanks.

Is the clock time set correctly?

What version here?

The time & date is correct.

Version 12.1.5

What log is this in? Is the GUP functioning as expected?

Yes it is.

SEP\12.1.5\Data\Logs\debug

We too have a 12.1 RU5 GUP that has exhibited this error earlier today. Funnily enough, it stopped once it moved to the more serious issue we have which is as follows:

"GUProxy - not enough memory for 595022576"

This issue has been confirmed overnight by Symantec support as a defect in RU5, scheduled to be resolved in RU6.

Essentially the GUP loses the ability to retrieve the large Full VirusDefs packages from the SEPM, due to some form of memory issue the SEP Agent (acting as a GUP) experiences. Note it has nothing to do with system RAM or memory resources of the server, of which there is plenty, the issue is internal to the Symantec code.

However, we've asked Symantec to confirm the issue was not also present but more dormant in RU4MP1 or ealier, and perhaps (as a theory) now only triggered more easily due to the ongoing increase in the Full VirusDefs size.

We base this on another member here who had this same issue in August 2014, which is a month before RU5's release, suggesting they could not have been using anything more recent than RU4MP1.

symantec[dot]com/connect/forums/gup-update-errors

Steven thanks, i'll make sure the clients being served from the GUP have current definitions. So we'll just have to await RU6 to have this resolved basically.

Hmm, that's your call to wait for RU6 (it only JUST went beta), and it's still best you open your own support ticket, as it also helps them gauge the impact of such defects.

If you want my two cents, downgrading your GUPs to RU4MP1 (the release prior to RU5) might be the safer option than waiting for RU6.

Alternatively, we've also recently been told to try a possible workaround with RU5, that we're still trialling. Essentially, they've informed us what appears to trigger this defect is the fact the bandwidth value when you configure a GUP is set to Unlimited by default. (this is the bandwidth between the GUP and SEPM)
Turns out they tell us it's NOT actually unlimited, it does have a limit that I assume they're setting in their code (this is a wild guess), so epic fail right there as their product documentation says otherwise. Not the first time I'm sad to say.

They've advised to set a reasonable limit. So we've gone with 1 Gbps, because none of our remote WAN links are close to or more than that speed for these kind of services, so we felt it a good place to start. You could also set it to the max NIC speed of the GUP server I guess.

Not literally 'wait' because that i wont do. I did in fact speak to a support rep and they repeated most of what you have stated here. The GUPs were already set to 1 or 2Gbps from inception, what i'll look at is tweaking the port or nic speed and see what the outcome is.

Are you able to available the logs for analysis? 

Is there any bandwidth limitation inside the Liveupdate policy for the GUPs?

The only tweaking i did was to up the bandwidth between sepm and gup to 2G from 1. The errors went away before i did that on 1 gup, and on the other gup, afterwards. So its inconclusive if that helped at all, i will just have to monitor and make adjustments to see if that works in the future if it happens again.
 

the option in GUP settings:

You can find here: http://symantec.com/docs/TECH96419

Please mark the answer you think helped you solving the issue and set it as resolved. 

Lucas, check my previous post.
 

Or better yet see my previous post, in that the information has been confirmed by Symantec support as false.

That said, we discovered yesterday that the "limit GUP bandwidth to a large limit" workaround, can still fail causing the memory issue to reoccur in RU5.

We're awaiting further advice from support, but my money is on us having to likely downgrade our GUPs to RU4MP1.

Hey Steven,

I have same problem here.. Keep us updated!

Thanks

Stood up a new server to be my GUP, and saw this error.  I tried changing the bandwidth limit from Unlimited down to 1GBps, and that had no impact.  Incidentally, I went and looked at my old GUP server (moving from physical to virtual), and it is having the same issue - that explains the increased load on the management server.  I hope that Symantec gets this corrected soon - how does something like this not get vetted/tested prior to rolling out?  It worked properly in previous versions - extremely frustrating.  

2015/03/06 12:03:40.567 [1132:3564] GUProxy - not enough memory for 624998512,after geting://X.X.X.X:8014/content/{07B590B3-9282-482f-BBAA-6D515D385869}/150305032/Full.zip

Is there ANY update from Symantec on this!?

Rolled back my GUP machine to 12.1.4112.4156, and GUP is back to performing like a champ:

2015/03/06 15:19:49.476 [2380:2972] GUProxy: accepted socket 3812 for X.X.X.X port 49235
2015/03/06 15:19:49.476 [2380:2900] GUProxy: Begin to handle accepted socket 3812
2015/03/06 15:19:51.492 [2380:2900] GUPROXY - GUProxy HTTP in - GET /content/{07B590B3-9282-482f-BBAA-6D515D385869}/150305032/xdelta15
2015/03/06 15:19:51.492 [2380:2900] GUPROXY - GUProxy File - /content/{07B590B3-9282-482f-BBAA-6D515D385869}/150305032/xdelta150305032_To_150306003.dax
2015/03/06 15:19:51.492 [2380:2900] GUProxy content cached - sending to client
2015/03/06 15:19:51.788 [2380:2900] GUProxy send content to the client all right.
2015/03/06 15:20:15.618 [2380:2976] Succeed to save the gup.dat's header
2015/03/06 15:20:15.618 [2380:2976] Succeed to save the gup.dat's cache entry array

Dont see why we should be downgrading .. but ..

I couldn't agree more....but...its what works.

"Please upgrade to a previous, more stable edition" 

I have same problem and support detected this bug.

Be fixed in 12.1.6 and the workaround is downgrade to 12.1.4112.4156.

Hope it helps.

Regards

llano,

Any idea when 12.1.6 will be available?

When I asked this question in Feb, May 2015 was the earliest estimate.  I went ahead and downleveled all of our servers to 12.1.4112.4156 after that. 

Thanks for the information - incidentally; best method for finding out when a new release is published would be...??

We have a global deployment with our management server on: 12.1.3001.165
and we see the same behaviour on most of our GUP's. (not enough memory...)

So upgrading the management server to 12.1.4 should solve this? do I need to upgrade the GUP's too?

my work around is to do a smc -stop on the GUP. delete all content from "SharedUpdate" folder and restart server. after this, it starts to download a full.

Hi,

SEP 12.1 RU6 is now released and it has a fix to the above mentioned issue.

GUP fails to retrieve content from SEPM with error: “GUProxy - not enough memory”

Fix ID: 3652490

Symptom: The Symantec Endpoint Protection client cannot download the full definition contents (full.zip) when multiple concurrent full.zip downloads are in progress from the Group Update Provider.

Solution: Added support for multiple concurrent full.zip content downloads from the Group Update Provider

Referene: New fixes in Symantec Endpoint Protection 12.1.6

http://www.symantec.com/docs/TECH230558

Upgrade to SEP 12.1 RU6 to resolve this issue.

Thanks!

Hi,

SEP 12.1 RU6 is now released & it has following fixes related to GUP.

GUP fails to retrieve content from SEPM with error: “GUProxy - not enough memory”

Fix ID: 3652490

Symptom: The Symantec Endpoint Protection client cannot download the full definition contents (full.zip) when multiple concurrent full.zip downloads are in progress from the Group Update Provider.

Solution: Added support for multiple concurrent full.zip content downloads from the Group Update Provider.

After a GUP upgrades to 12.1 RU5, ccSvcHst.exe crashes and creates multiple dump files

Fix ID: 3692462

Symptom: The process ccSvcHst.exe crashes and creates multiple dump files after upgrading the Group Update Provider to 12.1 RU5.

Solution: Updated the code to handle string buffer resize exceptions to avoid process crash.

Clients are incorrectly identified as GUPs

Fix ID: 3639309

Symptom: Clients are incorrectly defined as Group Update Providers when the client hostname contains repeating letters.

Solution: Fixed the string comparison algorithm to correctly determine a string pattern match.

Referene: New fixes in Symantec Endpoint Protection 12.1.6

http://www.symantec.com/docs/TECH230558

Installation and Administration Guide:

http://www.symantec.com/docs/DOC8645

12.1.6 just released

Symantec Endpoint Protection 12.1.6 Release Notes

http://www.symantec.com/docs/DOC8626

New fixes in Symantec Endpoint Protection 12.1.6

http://www.symantec.com/docs/TECH230558

Did my upgrade this week - GUP is working as it is supposed to - yay!