Video Screencast Help

tmp files issue in XFER folder

Created: 11 Jun 2008 • Updated: 02 Mar 2009 | 101 comments
I'm encountered two issues with the ProgramData\Symantec\SAVCorp\7.5\xfer folder.  I've only seen this on two Vista SP1 machines, one Business, one Ultimate both 32-bit, both Domain members but unmanaged.
First, SEP repeatedly detects risks in the xfer folder.  I thought this folder had to do with Quarantine, so why would SEP detect the obvious?
Second, and possibly related to the first, the folder grows beyond all belief.  I noticed this on the Business client when a 25GB partition had less than 1GB of free space, when it should have only been half full.  The xfer directory in this case had grown to roughly 9GB with over 300 thousand files.  It was so large that it was a pain to empty.  Trying to view Quarantine caused the program to hang.  It took several minutes to even browse th folder, as the hundreds of thousands of files caused explorer to take nearly 10 minutes to enumerate the files.
The Ultimate client had even more issues, with over 600 thousand files and 20GB of space taken up!  The only way to get back to some semblance of normalcy was to uninstall SEP (which cleared out the Quarentine files) and then reinstall.
Part of the reason is my fault, since I hadn't set the purge options for Quarantine.  Strangely, on my managed clients, without even setting an option it defaulted to deleting items older than 30 days.  The unmanaged clients didn't even have the 30 day option set.  Both now have the 30 day and 50MB options set, which should prevent the issue going forward (other than detecting risks in the xfer folder).
Any thoughts as to what's going on, particularly with the first issue?

Comments 101 CommentsJump to latest comment

HackSacken's picture

Did you ever get/find a solution for this?  I find myself in a similiar issue as you have posted.

JigsawMax's picture

I'm also having this exact problem on  a couple of client computers (XP Pro XP2).

Anybody have a solution for this problem?


africo's picture

(skip to bold below to get the quick answer, or read for the reasons our xfer folder was problematic)

in our environment this was caused (on a few hundred computers) by the (crappy) installer.  the rip-and-replace installer ripped and replaced, but there was no way to automate (as far as i could tell) the answer to the question:

There are items in quarantine.  Would you like to delete these items?

this prompt is at the end of the installation.  when we rolled out the product to 3500 machines in the field, we couldnt log into all of them that had quarantined items and click "yes", nor could we script a keypress vbscript style because the window wasnt up if no one was logged in.  so the next day, all the computers that we werent able to click that "yes" button on were logged onto and used.  and guess what the users did?  most pressed "no"!

so the quarantined items which remained in that xfer folder were no longer seen as quarantined by SEP, were seen as threats on the computer, and were still protected by the symantec engine as if they were quarantined and read-only and thus cannot be deleted.

i was forced to uninstall SEP, delete everything in the xfer folder, and then reinstall SEP.

that's the only fix i've found, so good luck!

JigsawMax's picture
Yikes... Well, thanks for the quick answer, africo. I'll give that a shot.
HackSacken's picture
Yes, thank you for the quick response. Much appreciated. 
I really don't know how our XFER folder came to be a problem.  The victimized server was one of our Citrix servers so a lot of variables come into play. 
I have partially fixed the problem by stopping all the SEP services and removing the folder and its contents.  However, when attempting to view items in quaratine, SEP now hangs.  I'm thinking I will have to do what you did and remove the software and re-install.  Thanks again!
Lincster's picture
Has anyone come up with a good solution to this issue?
It is starting to pop up on me quite frequently and I cannot seem to resolve it.
I have tried uninstalling the client, but that never seems to finish and bombs out.
I have been just reimaging the Hard drive for the people, but with 1000 clients that is not gonna fly.
Alter_Schwede's picture



same problem to clients here. In folder "Dokumente und Dateien\all users\Anwendungsdaten\Symantec\symantec Antivirus Corporate Edition\7.5\xfer" there were about 25GB! in over 805.000 files!

Less than 1 GB free diskspace was left. (Windows XP SP2)

I logged in as admin and deleted those files. It took over two hours to view and delete those files.

Does anybody of Symantec know about these horrible things?



Hurricane Andrew's picture

This can be prevented by making sure that you enable the quarantine purge options either via direct configuration of the client in an unmanaged environment or via a policy in a managed environment.

"Hurricane" Andrew

Dover, Delaware

Lincster's picture

I have had some success fixing the issue by doing the following.

1. Change the permissions on the xfer directory so that you can actually delete them.

2. Once the permissions have been changed delete the files and directory.

3. At that point I have seen the issue go away and not come back.

4. But to be safe I uninstalled sep 11 and deleted all folders associated with symantec.

5. then I resinstall SEP.


I have noticed this only happens on machines that are upgraded from 10.  Fresh installs have never produced this issue for me.

Alter_Schwede's picture

Yes, I will report that to our supporter, and hope that he will set those settings.

Thank you.



Lynchman's picture

We are having the same issue. We have over 1000+ clients that were upgraded from 10 to 11. We are currently running 11.0.2010. I have set our Quarantine server to purge all sample items. It seems some are showing up as samples but others aren't. It's sad to think that SEP thinks tmp files from a previous version are potentially a risk.


Any help would be appreciated.

HLKurt's picture

I am sure the solution of 'uninstalling and reinstalling' will work just fine, but getting to uninstal in my problem.  Since the xfer directory is now at 20gb, I have completely run out of space in order to do an uninstal.  Symantec says '...there is not enough space to unintall, please free up space'...


So, this is what I did.


Instead of using a window to delete some 300,000 files, I opened a command prompt, made my way to the c:\documents and sett...xfer...\ and did a good ole fashion c:\del*.*  I now (and its still growing) have 17.9gb of free space, which will allow me to uninstall Symantec and reinstall it.


And yes, I upgraded this machine from 10 to 11.

DowLohnes's picture

Has anyone seen anything related to this in the Symantec KB? I have looked but have been unsuccessful at finding any notes about it. We ran into our first instance of it after having the client rolled out for a couple months now.

Mr cool's picture

Greetings .............


I have the same issue in my network that tmp file is increasing in xfer folder

I tried all the methods listed in replays

But still the folder is growing

I need to clear the folder in every 3 days

If anyone have a good solution , let it me know

I m very much struggling with that




Paul Murgatroyd's picture

what version of SEP are you running?

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed:

Mr cool's picture



We are using Symantec Endpoint protection 11.0.2000.1567



Paul Murgatroyd's picture

I'm pretty sure this is fixed in MR4, I would try upgrading a couple of clients and see if the issue persists

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed:

Stew-IMS's picture

You're "pretty sure" it's fixed in MR4?  Can we get some clarification on this?  I'm experiencing this problem on multiple machines in my enterprise and cannot extend to you the level of frustration this has caused myself and my users.


Is it fixed or not?

JAF-HelpDesk's picture
Stew-IMS wrote:

You're "pretty sure" it's fixed in MR4?  Can we get some clarification on this?  I'm experiencing this problem on multiple machines in my enterprise and cannot extend to you the level of frustration this has caused myself and my users.


Is it fixed or not?


I recently upgraded from 10 to 11 (MR4) and I am having this problem on at least one system (WinXP Pro w/SP3). Enpoint repeatedly detects some of the TMP files as Trojans. (Over 800 in the most recent scan! Yikes!!... and there are over 5000 TMP files in the folder)


So in answer to your question - NO it does not appear to be fixed.


I have reset the quarantine policy to 7 days to see if this will make a difference. I'll let you know if that works.

dotnetcrash's picture

The hard drive on one of my machines was completely filled. I thought it was people downloading music and movies, but windirstat revealed that i had 9 gigs of tmp files (!!!) all created (i think, i deleted them) at the same time. there were aprox 800 000 files.

I  had to pull out the hard drive to get the files off, but i will now try and reinstall symantec to see if it fixes the issue. Seems to have only happened to one pc out of the hundreds we have. All the others have an "xfer_tmp" directory instead of just "xfer". Hopefully the issue will stay localized to one machine.

THe location of the files is @ \Documents and Settings\All Users\Application Data\Symantec\Symantec Endpoint Protection\xfer

vinni's picture


a customer of ours has the exact same problem on one of their clients (XP SP2).
I've already tried reinstalling after a clean deinstall (SEP 11 MR4) - but to no avail.

Dan_CBMM's picture

Here in my company we are experiencing the same problem.

Last week I noticed that xfer folder had  3 GB, so l deleted the folder. I've checked today, the folder is full again.
We use SEP 11 MR4

Any solution??


Prever's picture

Hi all

I have like 100+ work station and I have the same problem only in 1 station, right now is near to 10 GB and increasing.
There is a real and final solution to his problem?

Thank's a lot

Sirius Systems's picture

This issue really needs to be addressed by Symantec.  I've taken over the network for a law firm and one of their workstations was killed by this.

Paul Mapacpac's picture

Hi any updates with this issue? We currently experiencing this. We are on MR4 MP1a

CMarcera's picture

We are also now having this issue at our plant. Any resolution to this problem yet? Currently trying the uninstall of SEP solution mentioned in the beginning.



Control Center version:

Java version: 1.5.0_11

MySQL version: 5.0.15 

mon_raralio's picture

HLKurt's suggestion is the most ideal since it does not involve reinstallation.
If that doesn't allow removal of the files, does starting in safe mode with no network and then stopping the service help?

“Your most unhappy customers are your greatest source of learning.”

Scott K.'s picture

This is still a problem with our MR4 MP4 clients. For example, during last night scan SEP found 12 "Trojan Horse" or "Downloader." These were all temporary files in c:/Documents and Settings/All Users/Application Data/Symantec/Symantec Endpoint Protection/xfer/.

I would like a solution other than uninstall, deleted everything in the xfer folder and then reinstall SEP. Is there away to handle this better from within the Semantic Endpoint Protection Manager?

mon_raralio's picture

@HurricaneAndrew: Have you resolved this yet?

@ScottK.: HLKurt already have a suggestion that doesn't involve any reinstallation of the software

I'd like to test it out but haven't gotten any alerts from that folder in the past few days.

“Your most unhappy customers are your greatest source of learning.”

DaMoo's picture

I have a client that has some 146,000 files in the xfer directory using over 1GB of space.
ver 11.0.4000.2295.

I'd be fine if I could just limit the (size of)/(item count in) this folder.

Neo28's picture

We had this issue last year when we were using MR3. I was able to resolve that issue by uninstalling, deleting all folders related to Symantec, especially the xfer folder, and then re-installing. The issue has come back, different PC, and we are using MR4. It was constantly telling the user that these hundreds of files were being quarantined and made the PC practially unusable. The only thing I could do was uninstall the SEP client.

 This is very furstrating, as every one participating in this thread knows. Symantec really needs to work on this.

Tlokein's picture

Opened a case, was told it was fixed in MR4 MP2 (but they could not provide supporting documentation...hmmmm).

I've upgraded two of the client PCs that do this pretty consistently after a weekly scheduled scan, will know tomorrow if it works or not since the scan runs tonight.  Will update here....

Even if this works, it amazes me that this bug could exist for almost a year (or longer???) before being fixed, esp. since its an AV product blocking its own files!

Tlokein's picture

I upgraded two PCs to MR4 MP2 that have this happen every week after a scheduled scan, problem is still occurring.  I have updated the ticket, so far no response.

I was suspicous when they told me it was fixed in this release but could not provide any evidence or documentation that it was fixed (this isn't the first time I've been told an issue was fixed in the next release and it wasn't). 

Initially they said it was b\c I didn't manually uninstall the older version before upgrading.  We have over 1,000 PCs on this server alone, that's simply not an option.

mon_raralio's picture

The cause of not uninstalling the older version is unacceptable. The manual clearly states that SAV 10 can be migrated to SEP 11.
Maybe just add a procedure to empty all quarantine of all clients before migrating.

“Your most unhappy customers are your greatest source of learning.”

Paul Mapacpac's picture

Any Symantec Employee care to join this discussion? What can our workaround for this.. not to store quarantine? Hi guys any ideas?

Tlokein's picture

I agree completely, and said as much to Sym support.  Also asked the tech why does it say "removing previous versions" in the installer on the client when you do a v10 to v11 push (from the SEPM console) if it's not removing?  The tech suggested I script the uninstall if I didn't want to do it manually, which I refused on the grounds that its not my job to write uninstall routines for their product.

At least its better than another case I had for a problem that occurred upgrading to v11.  The tech actually told me I could just not upgrade and stay at v10.  I found this to be a completely unaccepatable response. 

I told the tech I'd let our Symantec account rep know that support was recommending we don't upgrade to the product he worked very hard to sell us.  ;-)

I was also told when I opened a case for this that they had never heard of the issue and this was an isolated incident.  Being that this thread has been running for over a year now and others have reported opening cases as well I find that hard to believe.

I'm beginning to wonder if there are fundamental issues with this product that support simply cannot resolve.

mon_raralio's picture

Well, the least they or the tech support you're talking to was to send you the script to run. And maybe refer it to a higher level support. But, I guess that would work against them when it comes to their performance evaluation.
Your experience is blog worthy. :D

“Your most unhappy customers are your greatest source of learning.”

Paul Mapacpac's picture

How about running cleanswipe to run silently (if I am not mistaken there's a parameter for this) then deploy SEP.

mon_raralio's picture

Not everyone can have that. You have to make a call to Symantec for them to give it to you. And not all cases "require" that program.
And I doubt they'll just let you post it in the downloads.

“Your most unhappy customers are your greatest source of learning.”

tekkid's picture

This is happening in MR4 MP2 as well.   It's really annoying...

srn612help's picture

Thank god this is only happening on one machine so far but it's a terminal server and wrecking havoc on it.

Is the only option to uninstall reinstall???

dotnetcrash's picture

so your soultion zaw phyoe, is to delete the temporary files... awesome. why didnt I think of that!!!

why am i subscribed to this thread still? it obviously isnt getting fixed.

personally, i havent noticed it happening again after i reimaged that particular machine. would be nice to have a REAL fix though, just incase it happens to a server or something.

Tlokein's picture

I have at least 3 PCs that have been reimaged and the problem came back.

We've had SEP go so beserk creating and deleting files we've had to cold boot the PC (couldn't even stop the service(s)).

If this starts happenning on the production floor causing cold boots to PCs running product...well, I don't even want to think about that right now....

RajeshKanuri's picture
i have just found the solution for similar problem ( even that is not the permanent one.. Symantec Service guys should look in to this issue.

Rajesh Kanuri

RajeshKanuri's picture
i have just found the solution for similar problem ( even that is not the permanent one.. Symantec Service guys should look in to this issue . .
Terabyte Computers's picture

It's still not fixed in 11.05 just released the other day either.  The article above,, does allow you to remove the files, but this is a real pain for a lot of systems.  Symantec needs to fix this immediatly.

ifishgroup's picture

Until they come up with a solution that fixes the problem permanently, I created a fix that uses a batch file to delete the directory in silent mode and used Windows scheduler to kick off the job every morning.  Rudimentary but it works.  Here are the steps:

1.  Create a batch file in Notepad (rename the <filename>.txt to <filename>.bat
2.  Copy and paste the following line into the body of the file (note:  the location of your specific flavor of antivirus will change the path).  I named my file NAVCleanup.bat and saved it in the root of the C: drive

      rmdir "C:\Documents and Settings\All Users\Application Data\Symantec\Symantec Endpoint Protection\xfer" /s /q

3.  Schedule a task in Windows Scheduler by going to Control Panel\Scheduled Tasks and Add Scheduled Task.  The wizard will walk you through adding the file, scheduling the interval (I run daily) and which account to run the task as.  Note:  The account used will have to have sufficient permission to delete the directory.

This was a nuisance but I don't have a lot of time to do this manually.  Hope it helps.


Terabyte Computers's picture

The problem with this is you have to either deploy to every PC or just ones with the problem and most small biz's won't know how to remotely schedule a task.  This is for Symantec to fix and there's no excuse for them not having done so already.  It's just pure laziness,  pure and simple.

Katyan1's picture

We had the same problem today.  See this link for the solution

Hope it helps

dotnetcrash's picture

yeah wait till it comes back. had to do 4 more pcs today.

you'll be back mr "see this link for solution"

Bored Silly's picture

We've used SEP since it's initial release (I know...I know...never be on the bleeding edge) and this problem has been present from the beginning.  We switched from McAfee to SEP so that disproves the theory about it only happening as a residual effect from migrating off of SAV 10.x.  We have 10,000 SEP clients and there's roughly a dozen different systems at any given time that will deal with this. My theory is that Quarantine doesn't properly delete the older contents when you cap the Quarantine to a certain size when it's dealing with a chatty virus that downloads tons of malware (like Downloader, Vundo, or certain Trojan Horses). 

Here's why I think that:

* On my systems it only happens after the Quarantine folder fills up to it's configured limit (in my case 50 MB's) while SEP is trying to clean a chatty virus.

* If you manually delete all of the contents of the Quarantine folder, the files in xfer will start to disappear and the Quarantine folder will slowly start to fill up again.

* If you select all the files in Xfer and try to open up Properties from the file menu, all of the files will disappear and start to process into the Quarantine folder.  For every 1 temp file processed from the xfer folder, you will get 2 objects in Quarantine (a folder with some file(s) and a single file).

The two workarounds I've used are:

1) Turn off Quarantine and configure SEP to delete the files if they can't be cleaned.  (Obviously, many companies don't allow this given the risks).

2) Map a drive to the remote system, from a command prompt CD to the xfer directory, then run a del * command. 

I hope a solution is found soon.

Paul Murgatroyd's picture


I just want to let you know where we are with this.  We have genuinely fixed the issue in certain circumstances, but accept its not completely fixed and are working to understand why.  It is also compounded a little due to the fact that in some instances we are actually seeing REAL threats being detected in these files.

We have one of our highest level engineers working on this at the moment, but we do have a couple of questions which would assist us greatly:

1. When you see the issue, how is it being reported?  Is it in realtime, or through a scheduled scan?
2. Is it reported more than once (ie does it come back on the same machine, and how many times)?
3. Do you have client logs that you can upload for us to take a look at?

Many thanks, further updates here as I get them.

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed:

tvleavitt's picture


I'm running Endpoint Protection 12.0 SBE. About 40 workstations. Most users login with Limited Accounts.

I ran into the situation of being flooded with tens of thousands of bogus quarantinee and virus alert notifications of files in the xfer .tmp folder. I called Symantec a while back, and the suggested solution was to create a centralized exceptions policy and then export it out to the clients. Was told this is a known problem, and an upcoming fix would be made available shortly.

To answer your questions, Paul:

How do I find out what verison RU5 is?

1. Don't know. I'm pretty sure about scheduled scan. Don't think I'm getting complaints about realtime, but I'm not sitting on the PCs when this comes up, and don't know if there's a way to tell after the fact.

2. I think it comes back. I haven't counted, and I do have the centralized exceptions in place (problem re-emerged during brief period when I accidentally turned it off in the process of creating another).

3. I probably have client logs (at least for the latest incident, which filled up a hard drive with 48.7 GB of .tmp files in the xfer folder).


r d f's picture

The overwhelming amount of bugs in ePolicy Orchestrator drove us away from McAfee.  Anyone else thinking of jumping the Symantec ship to Network Associates because of this bug don't bother.  You have been warned!

One machine started exhibiting this behavior today (at least I became aware of it today).


We recently within the last 2 months moved from ePolicy Orchestrator to SEP.  I used ePO to remove all existing versions of McAfee AV and manually removed the ones that ePO couldn't uninstall.  The ePO was removed from the server and SEP Manager was installed.  I pushed out the installations of SEP to the clients by the Manager.  Only a few machines could not be installed remotely by the manager.

Problem Machine

The problem machine was both a successful uninstall of McAfee by ePO and a successful install of SEP by SEP Manager.  I believe that SEP quarantined this particular "risk" that was labeled "Infostealer.Ldpinch" about a month ago on this same machine.  The first scheduled scan after installing on this machine.  I believe McAfee totally missed this "risk".


I opened SEP Manager and the Action Summary listed several hundred viruses being quarantined, about 40 viruses blocked, and about 40 Security Risks quarantined.  All of these came from the same pc mentioned above.  Pulling up the action summary report for the quarantined viruses all the files are .tmp files in the "c:/Documents and Settings/All Users/Application/Data/Symantec/Symantec Endpoint Protection/xfer/<filename>.tmp".

Blocked viruses summary had the same path and .tmp files as above.

However, the security risk quarantined summary listed dll files in the c:/System Volume Information/_restore{xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}/<filename>.dll.  Did it miss these files on the last scan a month ago?  Full scans are scheduled weekly on Monday night.  This user leaves the computer on 24/7.

I had all clients set to the default quarantine cleanup settings.  Delete after 30 days with no size limit.  I just changed that to delete after 7 days and limited the size to 250 MB.  Hoping this will clear at the machine and limit 10-30 GB of space being used like other posters of this thread have experienced.


  • This computer found a security risk the first scheduled scan after SEP was installed.
  • The computer had McAfee AV installed before the SEP installation and was removed before SEP was installed.
  • The SEP realtime scanner scanned the xfer folder today and reported viruses in the .tmp files
  • All quarantine settings were set to the default settings in the SEP Manager policies when this event happened.
  • This computer is managed by the SEP Manager

Other Thoughts

I am not exactly for sure of the dates but it seems like the xfer folder got scanned about the point the quarantined files should have been purged.

Hopefully this information will help in tracking down the annoying bug.

Gustaves's picture

Hi everybody. I am looking at this issue.

I have a VM that shows some of the issue.

I would appreciate if some one can look in the their quarantine as the problem starts to occur. You will see quarantine of many files from the xfer folder. Please look before that and see what was detected with the same threat name..Please upload a screen shot of the details of the quarantine entry.

Additionally it would be helpful if someone can verify that when you see a list of files quarantined from the xfer folder, that every few quarantine entries the entry is missing a file name.

More news as it happens.

JasonB@NORTEC's picture

On our XP systems I see it detect as "Trojin Horse" (See Bellow), it also appears only after a scedualed scan for me. SEPM shows about 22435 Quarentined items accross our network. All of which I can confortably say are tmp files ni teh the Xfer folder.


r d f's picture

Per my previous post I changed the quarantined cleanup setting to delete after 7 days.

Today 7 days later the computer that I am having problems with the scanning of the XFER folder is reporting over 4500 quarantined files to the SEPM.  So it seems to scan the XFER folder during the purge operation.  It is reporting the exact same virus "Infostealer.Ldpinch" as before.

I will not have physical access to this computer until union contract negotiations have concluded.

I plan on removing SEP from this machine and manually removing the XFER folder.

I will see about getting a sceenshot then.  I have no time frame for the negotiations so it could be 1 week, 2 weeks, ect.

Gustaves's picture

Thanks for the tip on the purge, RDF. I am trying various things on my machines here to get this to happen.

Regarding the comment above about hanging when you open the quarantine view, it isn't hung, it just takes a really long time to open a quarantine view when there is so much stuff in the folder.

Gustaves's picture

Hi everybody,

Here is a work-around and my update on the issue.

The likely work-around is to disable rescanning of the quarantine items when new definitions arrive. I have not yet seen here the scenario where the files get leaked, but the only time they are created is during rescan of quarantine items.

To easily disable rescanning of quarantine items on SEP 11.x set the registry key

[HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\AV\Quarantine]

Once that is set you can clean up the quarantine folder as outlined above and things will stay under control.

What is happening is that during scanning of the files in the quarantine, either when new definitions arrive, or when you open the Quarantine dialog to rescan the files, we extract a temporary copy of each quarantined threats to rescan it. When we do that we are leaking a temporary copy of it in to the Xfer folder. There are a couple of reasons that might happen and I am still tracking this down.

Initially the only items in the quarantine are the originally detected threat. As we leak copies of the threat in to the xfer folder they are detected by scheduled scans or indexing, and are quarantined. This gradually feeds on itself.

The copy in the quarantine folder has a secure wrapper around it so that isn't detected as a threat. The copy left in the xfer folder is not wrapped.

Detecting the file in the xfer folder is only a symptom that we leaked the file. The actual problem is the file getting leaking in to the folder sometime earlier.

Any logs from the beginning of the problem are appreciated. Those precede the accumulation of the files in the xfer folder.


DowLohnes's picture

Does the 11.0.5 update address this issue, and/or has Symantec been able to isolate what causes this to occur on some clients?

JasonB@NORTEC's picture

11.0.5 doesn't address the problem, at least not based on my experence.

Symanticus's picture

Hi All,

I'm now using SEP v 11.0.5002.333 the problem still exist, but anyway, I'm the only one who suffer this in the company so i go this directory C:\ProgramData\Symantec\Symantec Endpoint Protection\xfer and turn off the SEP service and delete.


/* Infrastructure Support Engineer */

Mike Khalil's picture

Assuming you never really want to quarantine anything and just want to get rid of it, do the following:

1. Open Notepad

2. Paste the following 4 lines into a text file:

rd /q /s "%AllUsersProfile%\Application Data\Symantec\Symantec Endpoint Protection\Quarantine"
md "%AllUsersProfile%\Application Data\Symantec\Symantec Endpoint Protection\Quarantine"
rd /q /s "%AllUsersProfile%\Application Data\Symantec\Symantec Endpoint Protection\xfer"
md "%AllUsersProfile%\Application Data\Symantec\Symantec Endpoint Protection\xfer"

3. Save the text file as "%ALLUSERSPROFILE%\ClearQuarantine.bat"

4. Create a Scheduled task that runs the following command at least once per day. Set the task to run as the user "NT AUTHORITY\SYSTEM" with no password:

%WINDIR%\system32\cmd.exe /c "%ALLUSERSPROFILE%\ClearQuarantine.bat"

5. Run the task for the first time.

6. Curse Symantec under your breath for writing buggy software that often doesn't honor your correctly managed settings, and fills your hard drive with quarantined viruses no matter what you do, unless you use a ridiculous (but effective) hack like this.

Steelejaxon's picture

Has there been any progress on this? I am finding examples of this issue on several of my machines.

EddieFernn's picture

My environment started experiencing this issue today.

Out of 15K clients only a little under 100 are doing this...
I hope the other clients dont catch on...

skriske's picture

Normal 0 21 false false false NL X-NONE X-NONE MicrosoftInternetExplorer4 Normal 0 21 false false false NL X-NONE X-NONE MicrosoftInternetExplorer4

Yes it looks like a silly problem, ( according to the Symantec  solution thought ) until you find out that one of your workstation has 749.360 tmp files in de Xfer folder and SEP scan crashes and it takes a half of a day to clean it up, etc.

Looking forward to a mature solution,

merry xmas

Ceroy's picture

Still no solution other than maually or scripting the deletion of temp files??  I have been dealing with this for 6 months waiting for a solution. 

JasonB@NORTEC's picture

Just noticed on one of my Machines the tmp files appearing in the "%windir%\Temp" folder.

hanspete's picture

Lost a workstation again today! The computer was extremely slow and harddisk was working like hell!
Had more than 190.000 files in the xfer folder!

Was surprised and disappointed that this problem still exists after months of users reporting the problem!

We already lost 2 workstations 4 months ago – all three losses caused a lot of problems for the users and required  support from IT personnel.

If there is still no solution to this issue - we will stop using the Symantec product! We do not want to use an antivirus-product that causes threads like a virus instead of protecting our company!!

Schleede's picture

We are having this issue in our enterprise. We have close to 10,000 workstations that we rolled in the last 4 months. We have never run anything older than 11.0.5002.333 on the clients. We are getting about 60+ clients doing this in our environment, and it has generated about 20,000 event spikes on a few hosts. We have had so many events from this, that we were not able to run reporting, until event compression ran.

We think this may be caused by the indexing service on the clients during a definition update. Unfortunately doing a fix on every client would be very difficult for our environment.

Does anyone have a fix for this yet? We are contemplating putting up a quarantine server to move these files off the client.

At this point, we are going to expedite this through symantec. I think that the above posts are right on with the problem.

Also, one of the articles states that we can disable scanning on the quarantine while new defs are installed. Is this a policy that can be pushed by the main console, or is this the registry setting on the client. (as per the post above?)

TangoJ's picture

Symantec programmers.
Please get up off your butts and start fixing some of the problems that us Admins are expierencing. I am sick and tired of this xfer temp issue, receiving alerts on my Blackberry that no one can read since you decided to use a format that Blackberry users can not read( I guess you do not know that most businesses use Blackberries) and waiting on the phone for hours for your support people to try and help you.  I do admit that Norton antivirus is probably the best in the market, but all of these problems are making Security admins look bad in front of their users and bosses.  I also keep getting alerts that some computers def's are 30 days out of date, but when I check the alert no computer is named.

If you can not fix the problems with the staff you have then hire some people that can!'s picture

Excuse the long winded post, but here our situation, and a theory I have. 

We have the same issue in our organisation.  It only appears to affect machines where the users aren't local admins.  It's not very widespread because SEP 11(.0.4041.26) only gets pushed out during the login script (not via GP, or anything else), and if the user isn't a local admin, it won't upgrade the previous verion of SAV, which is 7.5.  We only have a very small percentage of PC's where there isn't a dedicated user who isn't a local admin. 

Since our network accounts (tech support) are part of a group which gives us local admin rights on ever machine, we will sometimes logon to a PC and SEP 11 will get installed for the first time.  We're the only local admins who will ever log on, and it's only these machines which will have the problenm.  I don't know how the scans work behind the scenes, but from this, i can only assume it's using the "currently logged in user's" permissions when running a weekly scheduled scan. 

What, or whose permssions are the scans using when running?  I assume it has full admin rights because it can scan every folder, yet, when it encounters a virus, or something in the quarantine folder, it doesn't have permission to do anything with it except scan and put it in there again as another quarantined item (repeat until hard drive is full - and lucky our pc's only come with 80 gig drives, 160,000 items in the xfer folder takes a while to delete!).

Looking at the folder permssions, everyone has full control to the quarantine folder, but only read, write, execute access to the xfer, and xfer_tmp folder.  My PC still has the Symanctec Antivirus Corporate Edition\7.5 folder there, and the permsssions are the same.  In Quarantine everyone has full control, in xfer (there is no xfer_temp) it's only read, write, and execute.

Now a question for the Symantec guys.  How does SEP 11 handle viruses and quarantined items comparated to SAV 7.5?  Since local admins aren't affected, I'm thinking it's a permissions problem.  Could it be that this version of SEP need to have it's folder permissions changed so "Everyone" had full control in the xfer directory aswell?  The current permissions setup might have been something rolled over from the previous version since it worked fine with the way the program handled viruses then, but with the new program, it doesn't give it sufficient permission to do what it needs (such-as delete items from the xfter folder)?

I'm only guessing here because I can only look at this from the desktop side.  But i've got another job in my queue where a PC's almost unresponsive because it's almost out of hard drive space.  It's one i fixed towards the end of last year.  I'll delete the files, change the permssions ,then check back here.  If anyone reports that it's not the folder permssions, i'll just tell the network guys to push out the reg fix specified above by Gustaves.

And if it helps in any way, it is happening on PC's which only have our standard image on them, and since the staff aren't local admins, nothing new has been installed, so no additional AV, or anti spyware/malware programs etc.

srobak's picture

I have a dozen machines which cropped up with this in the last few weeks.

I see it has been a constant issue for OVER A YEAR.

My renewal is up soon, and if it is not resolved by then, I will be dumping SEP. I do not have time nor patience to deal with crap coding in a product which we pay good money for, and my company cannot afford to lose further money in manhours and productivity to this product.

A couple of months ago SEP failed to block and protect against a worm and backdoor dropper outbreak that brought over 65% of our company to a standstill for four days, and left me getting all of 9 hours sleep in those four days cleaning affected systems using malwarebytes and free AVG of all things. This nonsense with the xfer folder filling up is just the icing on the cake, and will lead me to take my business elsewhere... likely Sophos.

ittemp's picture


I just encountered this problem three days ago and just found a fix for the xfer folder growth...this folder growth caused a particular computer in the company to have all it's hard drive space eaten up... follow this link and it should help clear things up...

This worked for me and cleared 40 GB of data and all is well

Good luck!!

Absoblogginlutely's picture

bump We're getting this issue too on 11.05 and 11.04 clients

LSASPAC's picture

Is there a more 'managed' solution to resolving this problem?  For example can the xfer and xfer_tmp locations be safely added to the centralized exceptions?

The solution in works on a computer by computer scenario, however SEP is not a managed anti virus solution if it requires users to take manual action each time a virus is quarantined.

Like srobak this issue will affect our decision to continue using SEP when our subscription expires

rpfenninger's picture

I've just repaired a workstation as mentioned in the above article (thanks LSASPAC).
Hopefully, this is fixed in RU6. 

Thomas66's picture

Not fixed in ru6 or ru6a.  Maybe if we are lucky it will be fixed in ru6 mp1.

Absoblogginlutely's picture

I too can confirm it doesn't work in r6a
Worse - last night it was filling up files in \windows\temp too.

Absoblogginlutely's picture

I logged a ticket with Symantec - they gave me the following whilst the fix is in engineering - 
1.  Disable Windows Indexing service.
   It has been found that some of the tmp files created are due to file locks.  Very rarely the Windows Indexing service will be indexing a tmp file at the time rtvscan.exe wants to delete it.  Due to the lock, it gets left behind and then detected on the next scan, and so on and so on.  Typically if observed the tmp files will double when the issue occurs.
2.  Disable quarantine re-scanning.
   From the SEP-Manager:
- Edit the Antivirus and Antispyware policy of affected clients.
- In the policy editor click "Quarantine" on the left-hand menu.
- On the general tab click "Do nothing" under the heading "When new Virus Definitions Arrive"
   For unmanaged machines there is a registry value in the Quarantine key, DefWatchMode
(..\HKLM\Software\Symantec\Symantec Endpoint Protection\AV\Quarantine)
- Set this to 3 (do nothing).
Doing these two things should help the issue occur less frequently.  When the issue does occur the solution listed in the following article is the only means of clearing them out.

Title: 'Large amounts of temp files are being created in the xfer_tmp or 7.5/xfer folder and are being detected as threats.'
Document ID: 2009042217073548
> Web URL:

Raleigh Burns's picture

So although not a true solution to this pressing issue (which we are indeed working to fix), I thought I would make a suggestion which could alleviate the problem for many.
There really is no need to quarantine a Trojan or Worm. There is nothing to 'fix' and it will most always simply sit in quarantine until purged or expired.
I always recommend setting Trojan and WORM actions to Clean first then Delete second.
MACRO Virus actions obviously should quarantine always. But for Trojans or Worms I say nuke them.
Many people will argue "what if a false detection or bad def file causes a critical system file to trip ? ". Well, not likely to happen BUT if it did, a system is not going to be any more functional if the file is deleted or quarantined. You'll still have an issue. If it's a real detection on a system file the best practice will always be to replace an infected file rather than run with a cleaned file.
If the files never hit the quarantine to begin with you won't encounter the issue. Not a fix, and certainly not a statement that this problem is any less critical. We continue to work on a solution.

nmventure's picture

We pushed managed clients to pc's about 3 months ago.  Today, one computer ran out of hard drive space.  the xfer folder and quarantine folders were over 200 gig - took all day to empty them.  Did an uninstall / reinstall of the client and immediately the problem started again.  For now, I have uninstalled SEP and installed an unmanaged Symantec 10 Corp edition.  It looks like this problem has been occuring for a very long time, what is the fix for it before it starts showing up all over our network ?

Pistola's picture

As a Symantec Partner I am disappointed with the apathy of the Symantec Endpoint Protection team.

Users have been waiting patiently for a fix to the “xfer - temp file” issue/problem for over 2 years.

I can no longer condone such inaction and, even though I am a Symantec Partner, I am now forced to advise my corporate clients to adopt alternative anti-virus solutions in their next upgrade cycle.

This will obviously adversely affect how I view Symantec’s other products and their SLA’s.

Terabyte Computers's picture


I'm almost there with you.  Over in another thread about Fake AV that I started a week or so ago (and that prompted a lengthy phone call from an Sales Engineer that, in all honesty, was probably trying to settle me down but had no solutions or alternatives), Symantec keeps excusing away their inability to detect and remove the Fake AV-like Malware with other jury rigged settings versus admitting they have a problem and fix it.  Symantec would never make it in a 12-step program because to get past step #1 you have to admit you have a problem.  Symantec's support group needs a change at the top who's willing to admit when there are problem and then who is willing to yell and scream and development until problems are fixed.  I get the feeling the current support group are just yes-men (and women) with little or no guts to stand up for the customer. 

Actually, one of the laughable posts here was from Raleigh Buns who says never to quarantine the Trojans or worms and says it's unlikely to have a false positive but over in my thread,, they tell me to crank up Heuristics and other detection thresholds.  They canned Adobe Flash earlier this year which is one of the most popular and widely install apps in the world.  If they can't be trusted not to can Flash installer there's no way I'm setting SEP not to quarantine.

Edan's picture

I don't understand the purpose of all symantec antivirus products. First of all, all of them make computers slower. Then, they can't catch anything!!! I have to use third party antiviruses in order to clean computers (I am an IT). I can't trust Symantec at all.

I have the same issue with the xfer folder, how anoying!! But is not my call what antivirus product we use at the company I work for, so I have to suck it up....

skriske's picture

Hallelujah, Xfer problem's solved by SEP version 11.0.6100.645. ( or maybe also in earlier, 11.0 versions that i don't know for sure. ) It has just introduced a new joke: DWH*tmp files, generated by SEP own update wizard, are detected as Trojan.gen :)