Acrobat/Reader: Z@xxx.tmp files left behind in Temp folder after printing


If you are printing files with Adobe Reader/Acrobat you may notice that some tmp files are created in your Windows Temp folder:

C:\Documents and Settings\<user>\Local Settings\Temp

with file names similar to:






Only some of these tmp files get cleaned up after the print job has completed and you close Adobe Reader/Acrobat.  The remaining files are locked and cannot be deleted.  This can cause problems particularly in Terminal Server or Citrix environments where the user’s profile should be cleaned up when they logoff, but such locked tmp files prevent the successful cleanup.  This problem with remaining locked files only seems to occur on Windows XP, NT and 2003 Server.


These tmp files are actually the true type fonts that are used by the Windows print spooler when printing a PDF.  The font files get created using the Windows call CreateScalableFontResource.  This Windows API call locks the files and thus when Acrobat calls DeleteFile on these files, sometimes an ACCESS_DENIED error is returned and they cannot be deleted.

The issue is the OS keeps a lock on these files which gets released on system restart, or when the user logs off and back on (this is the case with XP/NT/2003Server).  These files can be deleted when the system restarts, Acrobat/Reader is launched again and then closed which will issue the request to Windows to delete the files again.  Sometimes the lock on these files is released by the OS after some time has elapsed.

We have been unable to identify the root cause of this issue in Windows and why it keeps a lock on these files, despite very intensive testing and debugging.  The problem is not isolated to any specific issue in Adobe software.

We provide the following workarounds to avoid this issue.


In a Terminal Server or Citrix environment it is not possible to restart the machine, as there may be other users logged on.  Therefore you may use one of the following workaround files.

There are 2 methods used in Acrobat/Reader to create these temp files for the fonts.  In the first acroct.ini file we disable one of these methods, and this has brought positive results in most cases.  In the second acroct.ini file we disable both methods, so that no temp files for the fonts are generated anymore, and therefore cannot be locked.

1. close Adobe Reader/Acrobat

2. extract the first acroct.ini, or second acroct.ini file to C:\Windows

On Terminal Server this should then install the .ini file in each user profile under C:\Documents and Settings\<user>\Windows.

Please note that using these .ini files will reduce the quality of the printed output, as the printed fonts can no longer render exactly as shown on screen.  Therefore it is more desirable to use the first acroct.ini (diables only one method) if it solves the issue, rather than the second acroct.ini (disables both methods).  You should verify the printed output using these files and decide which one works best for you.


Following our testing we have discovered that the issue does not occur in Windows 7, or Windows 2008 Server.

It seems that the updated versions of Windows provide a solution to this issue.  We would therefore recommend updating your OS if possible.

reference: (182680504/2989318)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 6.3/10 (76 votes cast)
Acrobat/Reader: Z@xxx.tmp files left behind in Temp folder after printing, 6.3 out of 10 based on 76 ratings

19 Responses to Acrobat/Reader: Z@xxx.tmp files left behind in Temp folder after printing

  1. Elst Ingrid says:


    I tried this work-around because we have this problem on a couple of windows 2003 servers.
    We need to reboot every 40 days because of the limit of 32000 open Adobe Z@*.tmp files. After restarting the server we can delete these files. Because it is a production server (7/7 days,24/24 hours) it isn’t evident to reboot the server.
    We already did an upgrade on 1 server to Adobe reader 9.4.0 to check if this Adobe version still creates these tmp files. It is.
    This work-aournd works fine if adobe reader 7.0.9 is installed on the windows server. It doesn’t work with Adobe 9.4.0. Do you have another solution for Adobe 9.4.0?

    • dmcmahon says:

      The problem is actually caused because Windows is holding a lock on some files when Acrobat wants to release and clean them up. We are working on another workaround for Acrobat 9. I will update this post once we have a solution.

  2. John Robles says:

    Using an iMac OSX lion i7 processor I found such a file on my desktop after submission ON LINE of form CT600 to HMRC for Corporation Tax. I could not at first understand why I could not open up the file or even move it into a folder I had created to keep all the relevant forms etc, in connection with the submission.

    Of course when I shut down and restarted my iMac the PDF.tmp file had been automatically removed from my desktop

  3. Brent Leis says:

    We have had this issue since I started 4 years ago in our existing terminal server enviorment.

    I put the workaround in place Early December and it has resolved our issue (although) we are working with Adobe version 8.0 Professional.

    Why did it take SEVERAL years for this article to surfice is my question.

  4. Elst Ingrid says:

    After the upgrade from Adobe 7.0.9 to Adobe 9.4.0 we have to reboot our server after 2 weeks (!) because the printing of pdf files takes a lot of time (45 sec per request) and cpu.
    At that moment we had 19000 open tmp files. Every 2 hours we run a script that delete the closed tmp files.
    When shall you have a solution for Adobe 9.4.0?
    Do we need to downgrade to Adobe 7.0.9?

  5. MRK says:

    Hi David,

    Any news about this issue?

    • dmcmahon says:

      Hi Marijus,
      We are working with priority on this issue. It is difficult to identify the root cause, as it appears that windows is keeping a lock on these files, and we do not know why. So far, we have discovered that performing a windows update resolved the issue on our test servers. We would recommend that you update your Windows servers with the latest updates, and give us feedback if that also relieves the problem in your environments with Reader 9.
      We are looking at making changes in our Reader 9 code to avoid the issue altogether, due to the difficulties in locating the root cause in the communication with Windows. We hope to be able to provide a final solution for Reader 9 very soon, but I don’t have any dates at the moment I’m afraid.

  6. MRK says:


    Nice to hear that something is being done. My machines are mostly always up to date. How do You think, should we plan downgrade?

    • dmcmahon says:

      Hi Marijus,
      It seems the reason the acroct.ini is not working with Reader 9 has something to do with Terminal Server itself. If the server is in install mode, then acroct.ini can be read, and it works fine for all users. Of course this is not recommended so we are working on a new workaround.
      It is possible that this new workaround will make it into the upcoming quarterly release in April. We have to be careful however, not to cause negative consequences for installations where this problem is not occurring. I will update the post as soon as I have confirmation.
      best regards,

  7. NextLevel says:

    I’ve made also a copy of the acroct.ini directly to C:\ . This seems to work on Terminal Server Windows 2003 R2 . At least, the process monitor logs an access to this file and there are no more Z@R*.tmp files, yet.

  8. MRK says:

    Seems like it’s time to move to Reader X. Do You know if this problem is solved in latest version?

    • dmcmahon says:

      Hi Marijus,
      the issue is not caused by Adobe Reader. It is related to Microsoft Windows. You should upgrade your OS version if possible to Windows 7/Windows 2008 Server or later.

      If you upgrade to Acrobat/Reader X but the OS is still an older version of Windows the issue will probably occur there also. You can use the workarounds above (acroct.ini) with Acrobat/Reader X too.

      Using the 2nd acroct.ini file in C:\Windows you should notice that no Z@R*.tmp files are generated anymore when printing. If you are still seeing .tmp files when printing then it looks like your acroct.ini file cannot be read by windows for some reason and you should find the root cause of that first.

  9. Elst Ingrid says:

    Hello David,
    As you can see in my comment of December 22:
    This work-aournd works fine if adobe reader 7.0.9 is installed on the windows server. It doesn’t work with Adobe 9.4.0.
    Is there a solution available for Adobe 9?

    • dmcmahon says:

      Hello Ingrid,

      Ensure you have also tried the second acroct.ini workaround file with Reader 9.4.0. This newer version was designed to disable both print methods which generate tmp files, so if it is installed correctly, you should not see any Z@R*.tmp files while printing.

      As mentioned above, this issue is not an Adobe Reader issue, but seems to be a problem with the OS which does not release the lock on these files. We do make changes in the functionality of Adobe Reader between major releases to improve the efficiency and quality of printing functions, and we do this using the standard OS API calls. If the issue only occurs in later versions of Adobe Reader this does not prove it is an Adobe issue. Adobe Reader is using the correct Windows API calls to delete these files but they do not get deleted in certain circumstances and we do not know why. The issue has been reported to Microsoft.

      We have invested considerable time and effort in investigating this issue and provided the workarounds to assist our customers but we cannot provide an ultimate solution in this case for an issue that appears to be caused by the OS.

      best regards,

  10. acampbel says:

    This issue appeared today with Acrobat Reader 9.5.2 on Windows Server 2008 SP2. 13+GB of tmp files (mostly Z@R7730.tmp) in 18,900 tmp folders named similar to described above. The user was logged on via Remote Desktop though disconnected. I had to force log off of the user to empty the temp folder. The dates of the tmp folders covered 12+ hours.

  11. Vicky Khurana says:


    I have sort of similar Issues on my 2003 server. However, what i found is that in the “C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\” i have bunch of “*.tmp” files and “*.PDF” files.

    the size of the folder is around 10 Gig. we found that we can delete all the files and grab a space except the one file named “AD$2sdgg2[1].tmp” and the size of the file is 8.7 GB.

    Was wondering if this solution can help me Eliminate this issue.. This is production server and i don’t want to reboot.



    • dmcmahon says:

      The solution mentioned above will only work for files named similar to Z@xxx.tmp in “C:\Documents and Settings\\Local Settings\Temp” as these are created by Acrobat/Reader. It will not work for .tmp files in “C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\”. You will need to figure out what process/application produces that .tmp file to correctly evaluate how it should be handled.