Windows Server 2008 R2 SP1; Citrix Xenapp 6
Files with names in the form SETnnnn.tmp are accumulating every day on Citrix farm servers in the C:\Windows\System32 directory. The nnnn is a 4-digit hex number in the name of each file. (such as SETB14A.tmp or SET1A02.tmp)
Each file has the same date (2/25/2009 7:01 PM) and size (497 KB). The files are owned by SYSTEM. Opened a couple of them with Wordpad and I can make out the filename of DIFxAPI.
These farm servers have been online about 6 months, with SP1 installed about 2 months ago. The first time I found them each server had about 15,000 of these .tmp files. At night, with users sessions logged off, I deleted these. Next day, a couple of hundred more were created.
Since these files are only accumulating on these servers and no others with Windows 2008 R2 SP1, it’s pretty clear that it’s related to sessions. In searching on this, I’ve seen others mention these files but no specific reason as to why they are created or why they aren’t being deleted automatically. But this would seem to indicate that it’s related somehow to Terminal Services rather than Citrix software.
Does anyone have any information as to why these tmp files are created in the System32 folder and why they aren’t being deleted automatically when the process finishes?
1. Please check if there are entries in PendingFileRenameOperations registry value. If it exists it will be located here:
2. Please check the logs using eventvwr.msc for signs of problems installing a driver, update, etc. You may see repeated entries from Windows Installer where it is installing something but there is a problem.
I did some searching on the Internet and it appears what you are experiencing is not related to RDS/Terminal Services, and has been reported for various windows versions over the years (long before 2008 was released), many workstation versions.
My theory is that there is some sort of driver/update/component that is either not able to install properly for some reason, or the installer package is incorrect, or there is a bug. If it is windows installer-based you will likely see clues in the logs that can help you track down the source.
- Proposed as answer by Yuan WangMicrosoft employee, Moderator Wednesday, August 10, 2011 3:18 PM
There are entries in the PendingFileRenameOperatons registry value.
I haven't been able to find any Windows Installer errors in the event logs.
The most common error that is recorded is a Metaframe error regarding printer autocreation for clients. We have always had these, no matter what version of Citrix software we run and we are currently using Xenapp 6. It's the only thing I can see that would be driver related that would cause the issue with the temporary files.
However, I have never really found anything that resolved these autocreation issues with printers.
Not really sure where to check next to verify this is causing the problem or not.
Did you ever get this resolved? I know it has been almost 2 years since this was responded on, but we are having the exact same issue. We have a Xenapp 6 server on Server 2008 R2 (needed because of some legacy software it publishes) and we have the exact same printer auto-creation warning, set.tmp files, and data in the PendingFileRenameOperations registry key. What is more, our Winsdows\system32\spool\drivers folder is almost 40GB of data. So it appears to be an issue with printer creation and printer drivers.
I am really curious to find out what was done in this particular case and whether there was any permanent resolution.
We never found a reason why these tmp files are created by a SYSTEM process but then not deleted when the process is complete. We did determine that this is related to print jobs and is exacerbated in a TS environment as each connected user who prints creates several of these per print job.
No one had offered any solution or fix to this, so I ended up creating a Scheduled Task that runs each night, running a cmd file that removes all set*.tmp files in System32 folder.
Thanks for the response. I kind of anticipated hearing something along those lines. Looks like I will have to run this by Microsoft since this raises some concerns about the overall stability of this system. If I find out anything more, I will post it here. Thanks!
No one had offered any solution or fix to this?
TP gave you the right information. This happens when you have (or have tried to) install corrupted drivers. It's up to yourself to find which one it is and to remove it. Maybe you can post the entries in your registry?
And Eric, this is also the matter with your system. Try to find the corrupted driver and remove it from your system. Check your register as TP already mentioned. It will give you a good indication of the corrupted driver.
- Edited by Roy van den Berg Thursday, July 25, 2013 7:33 AM Typo's
I responded two years ago that:
1. The registry entries existed (neither a cause or a solution);
2. There were no relevant Event Log messages identifying corrupt print drivers.
I also disagreed with the notion that this isn't related to a TS environment, as this issue does not occur on any PC that is configured with the same network printers, or same model of local printers.
Logically, I can only conclude that this isn't related to a corrupt print driver, then.