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.