Adobe Reader’s Z@….tmp files cannot be deleted

Posted on by

Recently Microsoft provided me a private hotfix to fix a bug in the Windows Server 2012 OS (see one of my previous posts). The fix worked great, but after a day having it in production, a new issue appeared. Since we applied the hotfix, some users started to complain that a login isn’t possible anymore. It was immediately clear, this most probably is a side-effect of the applied fix. We configured our XenApp servers the way that the users’s temp folders are located on d:\temp\%sessionid%. This folder usually gets deleted when a user logs off. Additionally in the login script we check if the d:\temp\%sessionid% folder already exists on the server and if so, we try to delete it. If the folder cannot be deleted, the user will be automatically logged off during the login. You might ask you why we do that. The reason is that we didn’t want to have temporary files of a previous user in another user’s temp folder. There is not just a security reason behind, but also a potential issue that might appear if the users starts an application that wants to create a file that already exists and cannot be changed (i.e. Lotus Notes creates such issues). Therefore we decided that we want to have a clean temp folder for every user.
Knowing that, we knew that there must be something that still remains in the temp folder of a previous user that cannot be deleted. It was Adobe Reader that created Z@<something>.tmp files that were still in use by the SYSTEM process and couldn’t be deleted. Even a tool like handle.exe from Sysinternals wasn’t able to release the handle. Only a reboot of the server indeed released the handle and the file could be deleted. This brings us to the next question. Why is deleting those files not possible anymore after the hotfix? I monitored Adobe Reader and figured out that Adobe Reader still uses a Windows API that is no longer supported by Microsoft after Windows XP! This is one of the Windows API calls when I was printing some PDF pages:

CreateScalableFontResourceW ( 0, “C:\Users\michi_000\AppData\Local\Temp\acrord32_sbx\Z@SC8AF.tmp”, “C:\Users\michi_000\AppData\Local\Temp\acrord32_sbx\Z@RC89E.tmp”, NULL )

Check out http://msdn.microsoft.com/en-us/library/windows/desktop/dd183517(v=vs.85).aspx to get more information of that function. There you can find that end of client support is Windows XP and end of server support is Windows Server 2003. So again, Adobe uses an API that isn’t support since XP/2003 server! And the private hotfix has somehow changed the behavior of that API that Microsoft won’t support anymore.

Maybe you observed that the temp folder in the example above isn’t d:\temp\%sessionid%, but instead the default one. Correct! The reason is that I was even able to reproduce the issue on my Windows 8.1 with the latest Microsoft Updates. This made me thinking about updates. And indeed it now looks like that all Windows clients and Windows server OSs with the latest Windows Updates will be able to reproduce the issue! So which update is it? Honestly writing, I didn’t remove the update to proof it is this one, but it’s very obvious. Check out this security update: http://support.microsoft.com/kb/2993651/en-us

Read “Known issue 1” and you exactly read what you experience! So what does this mean? Adobe has to recode Adobe Reader and should use another API that is supported and doesn’t produce the same issue. This is not a Microsoft issue, this is an issue that has to be fixed by Adobe.

Maybe you also came across that post: http://blogs.adobe.com/dmcmahon/2011/11/08/acrobatreader-tmp-files-left-behind-in-temp-folder-after-printing/

It’s an older post, but still valid and reflects the issue. The option with the ini file still works with the latest Adobe Reader version, but this isn’t an option for me as this will have an impact on the quality of the printouts.

To sum up – Adobe has to recode Adobe Reader. The CreateScalableFontResourceW function is outdated and not supported anymore. I was able to proof that this API doesn’t release the font file anymore after it has been executed.

24 thoughts on “Adobe Reader’s Z@….tmp files cannot be deleted”

    • Hi,
      I don’t know how you configured your user profiles, but I can tell you what we do as a workaround. The Z@…tmp files are usually in the temp folder. Our %temp% Folder is not located in the user profile, it’s in on d:\temp\%sessionid%\. This folder will be automatically created when a user logs in. When a user logs in on a server and the d:\temp\%sessionid% folder already exists, we reset the permissions of the folder so that the logging in user gets full control rights on the existing folder (otherwise he would have received ‘Access is denied’). Means the user logging in takes over the temp folder that existed before from a previous user. The only downside is that he also takes over the .tmp files from Adobe Reader that have been created from the previous user. But that’s not really a big issue. Does that help?

      Regards, Michael

      Reply ↓

  2. If you remove hotfix 2993651, the problem goes away. The left behind files are actually font files, and MS changed the way they handled them.

    Reply ↓

  4. Hi Michael,

    funny thing is: you can move those locked files.
    you cannot delete them or rename the profile they are in. But you can move them. Did the job for us, because we do not delete those files on a regular base.

    Reply ↓

  6. Hi all,

    I have read many many articles for this issue.
    Outcome is, like from this Blog, Adobe has to re-code Reader.
    We have tried alot of ways to get this fixed, but neither uninstalling MS Patches, nor the AcroCT.ini files (yes both) are a fix for us.

    If Adobe Reader needs to use temporary fonts for printing the PDF files, they have to Force unload and clean up the temporary fonts/files. (Font Installation and Deletion (Windows))

    Since MS14-045: Description of the security update for kernel-mode drivers: August 27, 2014 there is a new behavior for Font and Font Resource installation/deletion.
    Since Adobe Reader has NO support channel, NO way of contacting other than the forums:
    How on earth could we get this to be fixed in a new release???

    Should this message be posted on all threads for this annoying issue?
    We are facing this problem with over 10 customers on over 600 Remote Desktop Servers – No way I am going to remove patch #1 from August 2014, which is being re-deployed in a newer fix every month..

    The root cause is the programming in Adobe, which had been conform Microsoft’s wishes, but this behavior change in removal has to be remarked to Adobe…

    Regards and awaiting a way into the developers part on Adobe Reader.
    Michael

    Reply ↓

  8. Hi Alex. Haven’t heard or read about a fix from Adobe. Therefore I still suggest to implement one of the workarounds that are mentioned on that post/comments. I see that some admins start to block Windows updates that contain win32k.sys or gdi32.dll, but that’s definitely not a good and secure workaround. I’d rather redirect the temp folder that contains Adobe’s .tmp files to another folder (out of the profile) so that the users can still logging off and in without any issues.

    Reply ↓

  11. Hi there,

    I also have this problem, I want to check some settings, but I can’t find a pdf file witch is creating these Z@…tmp files, does anyone know where I can find them ??

    Has something to do with Windows updates KB2970228 and KB2993651

    Reply ↓

  13. Pingback: Adobe solved the z@ tmp files issue | Michael's IT Blog

Leave a Reply to Ger Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.