none
IE 8 Print: Script error / crash when printing (res://ieframe.dll/preview.js)

    Question

  • I have seen other similar topics, but I don't think answers given there apply to this situation.

    We have a problem when user is printing from IE 8, that sometimes it will crash after pressing print button inside print preview with the following message: (sorry for inaccurate translation from another language):

    Script error
    Line: 369
    Character: 1
    Error: The receiver of the call (server [not serverprogram]) is not available;
    all connections are invalid. Call was not executed.
    Code: 0
    URL: res://ieframe.dll/preview.js

    The weird thing is that this does not happen all the time, as a user reports, lets say after 12 printouts.

    I would appreciate any help.

    Best regards,

    Mike

    Friday, May 18, 2012 7:45 AM

All replies

  • The weird thing is that this does not happen all the time, as a user reports, lets say after 12 printouts.


    So that sounds like it is a quirk of the driver.   Try printing to a virtual printer, such as  XPS Document Writer?

    BTW you can find out what is at line 369 using  Developer Tools.   First open  res://ieframe.dll/preview.dlg  in a tab using the Address bar.   Then press F12.   Then click on the Script tab.   Then select  preview.js  from the list of script files which have been loaded so far.   Then see what you have above line 369.   I'm not using IE8, so I can't say for sure but usually you will see that it is in a Catch block after a call to the driver.   There may be more details in the Console tab about the error.   Unfortunately, I don't think we can debug the script for a real test, so you just have to make some inferences based on clues such as these.

    Good luck


    Robert Aldwinckle
    ---


    Friday, May 18, 2012 7:12 PM
  • The problem is that we are unable to reproduce that error at our computers. User now claims that this error pops out when they open page with printout, which is hard to believe. As I understand, this script is used by IE while printing, so how could error in it occur while user opens page...?

    User claims that this must be problem with our software and not Microsoft. That is also rather unlikely as we only return image for printing, how this cause error in IE print script.

    About checking preview.js, line 369 is:

    if (fitScale < dialogArguments.__IE_STFScaleMin) fitScale = dialogArguments.__IE_STFScaleMin;

    Doesn't tell me much....


    Monday, May 21, 2012 3:36 PM
  • Hi,

    How about trying this hotfix?

    http://support.microsoft.com/kb/2647169


    Niki Han

    TechNet Community Support

    Tuesday, June 05, 2012 1:49 AM
  • About checking preview.js, line 369 is:

    if (fitScale < dialogArguments.__IE_STFScaleMin) fitScale = dialogArguments.__IE_STFScaleMin;

    Doesn't tell me much....

    It's actually the context which is more signficant.   E.g. in IE9 that line occurs on line 374 and it is inside an  if block for g_fCheckAutoFit  which is within function  CalcDocsComplete().   So, I suspect you could avoid this particular symptom by avoiding Shrink to Fit.   Also, I can see only one reference to that function as a text argument to a  window.setTimeout()  call?   Could you try shortening whatever it is that you are printing so a timeout would not be invoked?   Alternatively, the implication of the CalcDocsComplete() function is that it is doing something with multiple documents and only gets invoked after they are all done.   So, perhaps you could add more dummy documents to be printed that you didn't care about and then what you really cared about would have already been printed before this error occurred?   Etc.


    Good luck

    Robert
    ---

    Tuesday, June 05, 2012 5:15 AM
  • How about trying this hotfix?

    http://support.microsoft.com/kb/2647169

    @ Niki

    Looks like that would be the wrong module?   E.g. the script is in ieframe.dll;  that hotfix replaces xpsprint.dll?

    However, maybe that is where I got the idea to use a virtual printer (e.g. XPS Document Writer) as a workaround for all these driver incompatibilities.    <eg>

    BTW this reminds me that I was disappointed that applying that hotfix did not result in the rest of the IE modules being set on the LDR track (e.g. in particular the ieframe.dll LDR version).   In order to get there I had to use a variation of the technique documented by  Pronichkin

    I found that procedure daunting and refuse to document what I did with it exactly.  When is this going to be replaced by a FixIT so that anybody who wants to get on the IE LDR track can do so more easily?


    TIA

    Robert
    ---

    Tuesday, June 05, 2012 5:36 AM