Share via

Script error ‘res://ieframe.dll/preview.js’ trying to print from Outlook 2003 in a TS/RDS session with IE9 installed

  • Article

Update 2012-01-11:
There is now a hotfix available for Windows 7 / Server 2008 R2 to address this issue – KB2647169

Update 2012-02-16:
The above hotfix has now been extended to cover Windows Vista / Server 2008

A customer had a case recently where a Windows Server 2008 x86 SP2 server had Office 2003 and Internet Explorer 9 installed, and when users in TS sessions try to print HTML format emails from Outlook, the following error is displayed:

Line: 2053
Char: 1
Error: The system cannot find the file specified
Code: 0
URL: res://ieframe.dll/preview.js

Plain text, and RTF format emails print just fine – the problem is specifically HTML format (which makes sense as this would invoke the HTML rendering engine shared with the OS and IE).

Others have reported the same issue on Windows Server 2008 R2 in RDS sessions, and only after upgrading from IE8 to IE9 – so on the surface the problem appears to be with an IE component, however that’s actually not the problem here…

 

First, what file is it that the system cannot find?  Here’s how we find out…

First, download Process Monitor.

Next, start Outlook 2003 and open an HTML format email so you are ready to repro the problem.

Now start Process Monitor so we are logging all I/O events.

Now click the Print button on the Outlook toolbar and get the error up.
TIP: Don’t clear the error message by clicking OK – this will just generate more activity and we’ve already recorded the problem.

Now switch to Process Monitor and stop it recording, then filter on Process Name = OUTLOOK.EXE.

Filter out all but file I/O events to reduce the list, and use a highlight rule for Result = NAME NOT FOUND.

Scroll down the list and you can get an idea as to what Outlook is doing as it renders the elements of the mail in the Temporary Internet Files folder in the user profile.

The actual files created will vary, as the mail content and name for the cache folders will be unpredictable, but you will see a pattern of checks to see if a file exists (NAME NOT FOUND, highlighted), then afterwards a series of events for the same path where the file is created and written to, then closed.

At some point down the list you will see a NAME NOT FOUND for a path ending with \Windows\Fonts, and there is a series of successful I/Os that follow – the events after here are actually handling the script error.

 

The problem is that the process is trying to open a folder that does not exist – so the solution is to create this missing path (the folder does not need to contain anything).
NOTE: There may be side effects of creating this folder and not having it populated.

The path to the folder is %HOMEDRIVE%%HOMEPATH%\Windows\Fonts, and for most users this translates as C:\Users\%USERNAME% , but if the AD user object has a home folder specified then this will be a UNC path.

 

So now we know what is missing and how to work around the problem – but why does it happen, and why only when IE9 is installed?

IE9 had a design change in how its invokes printing APIs in the OS – the XPS component is now involved.

IE9 itself does not have a problem printing, so why do applications such as Outlook 2003 suddenly get issues?
This is because the application is not “TS aware” and so its API calls are marked as such, leading to an incorrect code path being followed when trying to enumerate the path to the fonts folder.
If the application was marked as TS aware then the system fonts folder is used ( %SYSTEMROOT%\Fonts) and there would be no problem.

NOTE: This is not the root cause of all scripting errors, or even all errors thrown by preview.js, it is just one specific symptom tied directly to the presence of an IE version after 8.0, and only in TS/RDS scenarios.

Comments

  • Anonymous
    January 01, 2003
    Hi MarkH, Yes, that should work fine - though I'd be tempated to use Replace mode (so it can be removed when the GPPrefs policy no longer applies to ther user), and create "%HOMEDRIVE%%HOMEPATH%WindowsFonts" so it works regardless of local or remote home folder location. Cheers, Paul

  • Anonymous
    January 01, 2003
    Version is SP1.  To confirm I verified that the file xpsprint.dll is version 6.1.7601.21866

  • Anonymous
    January 01, 2003
    The hotfix linked here doesn't seem to work for me even though the workaround does.  Has anybody else had issues with the hotfix? I've tried installing it several different ways, but it only ever seems to correct the issue for the user I installed it as.  I've tried it as a Domain Admin, Local Admin, and with plain user accounts.   The workaround requires me to put the folder "fonts" into the "WINDOWS" folder on every users local profile.  Since we use remote desktop roaming profiles and a server farm of five servers, that is a A LOT of folders.  Does anybody know how to get the Hotfix to work?

  • Anonymous
    January 01, 2003
    It seems I've actually given you some false information.  Further testing reveals that administrator account can print no matter if the hotfix is installed or not (something I'm almost certain I wasn't able to do before I installed it the first time), and user accounts cannot print regardless if the hotfix is installed or not. I had actually forgotten to delete the "Fonts" folder for the user I was testing the hotfix on, which is why I thought it had worked for that user. So basically, it hasn't fixed the issue for users.  I'm going to try it on a different server today just in case.  Any other information I can provide you with?

  • Anonymous
    January 01, 2003
    Strange, I've not seen any reports of it failing for others. The bit that concerns me is this: "...it only ever seems to correct the issue for the user I installed it as" - the hotfix is repalcing a DLL, and as such is not user-specific in any way so should either work for all or no users, so long as this is the problem being hit... I would start by looking at what Process Monitor records for a user who does not have the workaround in place does but does not have the problem - is there any I/O towards the WindowsFonts folder in the user profile folder?

  • Anonymous
    January 01, 2003
    Is this W2K8R2 RTM or SP1? What version string do you have for xpsprint.dll? The RTM LDR version is 6.1.7600.21097 The SP1 LDR version is 6.1.7601.21866

  • Anonymous
    January 01, 2003
    I'd still be going back to Process Monitor - the symptom described & addressed by the hotfix is not related to permissions or privileges but the presence (or more correctly, absence) of a folder in their profile  so should affect standard or administrative users alike. I would set up a brand new standard user account and repro the problem while recording with ProcMon, then make them a member of Administrators, log off & on again and repeat the test (now successful according to your comments above) and compare the difference. In particular, the call stack of the event in Process Monitor (with symbols configured) where the access to %HOMEDRIVE%%HOMEPATH%WindowsFonts is attempted would be an interesting place to look.

  • Anonymous
    November 16, 2011
    Could we use Group Policy Preferences to create the folder? User Configuration Preferences Windows Settings Folders Create c:users%username%WINDOWSFonts "Run in logged-on user's security context"

  • Anonymous
    January 09, 2012
    Thank you so much! This helped me immensely!

  • Anonymous
    May 30, 2012
    It it worth noting that, at least in my case, the %HOMEDRIVE%%HOMEPATH%WindowsFonts needs to exist before the user logs in. I logged in and created the folder, but the fix did not work until I logged out and back in again.

  • Anonymous
    June 26, 2012
    So it seems we have this same issue. Windows 7, IE9, Outlook 2003. I our case we were able to get it to work it we select the Printing in plain text only option as a work around. We also noted that we were able to print to our Konica Copier and can also print to an HP CM1420 using the PCL driver but not the HP4250's. Seems it may be a driver issues here.

  • Anonymous
    October 09, 2012
    I created the aforementioned folder through policy, and it has corrected the problem.  Screenshot in link: http://prntscr.com/h37qh

  • Anonymous
    November 13, 2013
    @DAN k --your picture is missing. Please give us proper snapshot so that we easily correct this problem

  • Anonymous
    October 07, 2014
    I tried installing the hotfix on our 2008 r2 terminal server and it didn't resolve the issues with HP Universal Print drivers and html printing. The fix was to manually create the folder WINDOWSFonts under the user's roaming profile. As mentioned above user needs to log off and log back in for it to take effect. Works great!