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.