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.
Hi,
Im having the same problem on many servers. What do you think is the best fix/workaround?
F. Martina
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
Hi Michael,
Thanks for replying. I used the workaround discribed in this article:
http://blogs.adobe.com/dmcmahon/2011/11/08/acrobatreader-tmp-files-left-behind-in-temp-folder-after-printing/
The second .ini file worked for me. Although i still believe Adobe has to fix this problem.
Regards,
Fabio
Hi Fabio,
I also tested this one and it worked too with the second .ini file. But there seems to be a quality Impact on the printouts, that’s why I decided to not implement this solution.
Hi,
I asked a few users to check the quality. They are not complaining and tested a few prints with the before and after result. It was nearly possible to see :).
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.
Hi Lindsay. Your comment confirms what I assumed, thanks for sharing this.
Have you also done a bug report ? I just did, maybe it helps if more people do this to drwa their attention. https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
Hi Dennis – I wasn’t aware of that link, thanks for sharing. I will send a bug report as well.
Regards, Michael
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.
I tried to move it and it didn’t work for me !
hi guys,
any news regarding this issue?
i also have the same problem on mein XenApp-Servers
regards
Michael
Hi,
You can copy the 2 .ini files to the C:\Windows folder as mentioned in the the following article:
http://blogs.adobe.com/dmcmahon/2011/11/08/acrobatreader-tmp-files-left-behind-in-temp-folder-after-printing/
Worked great for me!
Hi Fabio,
Thank you.
I will test this.
According to the description this file should be copied to the user Profile
regards
Michael
Hi,
I think thats not correct. It says:
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\\Windows.
The text says you have to copy it in the c:windows folder. But i see you use XenApp, then it wont work i guess.
I am using XenApp in my Environment. You only need to put the ini-File into the windows-folder. Now everytime, the adobe reader is launched, it prevents those temp-files from being created.
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
Hello Everyone,
Any updates on this issue? Does it have a definitive fix already?
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.
Hi all
I have created a new thread in the Adobe Community – Having the Issue on Windows 7 without TS / RDS. https://forums.adobe.com/thread/1868132
Hope someone will add a useful commend. Tested a lot around this issue…
Regards
Solero
Hallo together,
is there still any new Information about the issue??
Regards Matthias
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
Issue solved with Adobe Reader 11.0.14: http://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotes/11/11.0.14.html
Pingback: Adobe solved the z@ tmp files issue | Michael's IT Blog