Open Bug 649128 Opened 13 years ago Updated 2 years ago

"Prop Res DLL not loaded" error when clicking Properties in Print window with Firefox 4 and Lexmark X6170 printer

Categories

(Core :: Printing: Setup, defect)

Product:
Core
Component:
Printing: Setup
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: zzxc, Unassigned)

References

Details

(Keywords: regression) 

A user with a very old (c. 2000) Lexmark X6170 printer reported a "Prop Res DLL not loaded" when clicking Properties inside the Firefox Print dialog in Windows XP.  This user had the latest driver offered from the Lexmark website, and printing in all other programs works.

The code preventing unauthorized modules from being loaded in Firefox 4 is likely at fault here.  Lexmark should fix their driver such that this error does not occur.
I have lexmark 1185 and have this exact same problem.
Reverted back to Firefox 3.6.17 and solved problem.
I would suggest trying one of the 2 workarounds from this Microsoft Knowlege-base article.

http://support.microsoft.com/kb/918730
Alternatively, in about:config set print.extend_native_print_dialog to false.
Resolving as INVALID as this is really not a bug in Firefox, but a bug in older Lexmark printer driver installations that don't install the drivers required for printer preferences in a location that is in the default search path.  THis was not evident in Firefox 3 because it did not try to use the native driver supplied extended printer preferences.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
(In reply to comment #5)
> THis was not evident in Firefox 3 because it did not try to use the
> native driver supplied extended printer preferences.

This is not true.  Fx 3.6.17 opens the native lexmark printing prefs dialog  when you click properties in the print dialog.  According to process explorer it's able to load the appropriate dlls form system32\spool\drivers\W32X86\3\
Why can 3.6 load print prefs and 4.0 can't?

> Alternatively, in about:config set print.extend_native_print_dialog to false.

This doesn't work,  all it does is change the print dialog to the generic XP one, but you still get the error when you click properties.

This should not be INVALID.  Printing worked with these drivers since Fx inception, and only stopped in 4.0.  This is a serious Fx regression.
(In reply to comment #1) from 660462
> I also Googled the problem and found all kinds of articles with peope having
> this same issue with this printer and applications other than Firefox.  I
> would suggest trying one of the 2 workarounds from this Microsoft
> Knowlege-base article.
> 
> http://support.microsoft.com/kb/918730

To be clear, I have no issues with opening printing prefs with any other app on my system, including other browsers, and most significantly, Fx 3.6.  This regression was introduced in 4.0 and can be fixed.  Please reopen this bug.
(In reply to comment #7)
> (In reply to comment #1) from 660462
> > I also Googled the problem and found all kinds of articles with peope having
> > this same issue with this printer and applications other than Firefox.  I
> > would suggest trying one of the 2 workarounds from this Microsoft
> > Knowlege-base article.
> > 
> > http://support.microsoft.com/kb/918730
> 
> To be clear, I have no issues with opening printing prefs with any other app
> on my system, including other browsers, and most significantly, Fx 3.6. 
> This regression was introduced in 4.0 and can be fixed.  Please reopen this
> bug.

THe issue here is that more modern applications, try to use new features in later versions of Windows that permit you form inside the application to access an extended, supplied by your printer driver preferences.  Applications that do not try to use this new functionality do not encounter the issue.  The problem here is that these drivers actually try to make this new functionality available, but because they do not install themselves in a location that is in the normal search path for executables, it does not work correctly.

This issue may not happen with any other application you have installed on your system, but the reality is that these same printer drivers fail in the same manner with recent versions of Microsoft Office.

This is not really a Firefox issue, but is an issue with the way the drivers install themselves, and if you follow the steps int eh article I gave the link to, you will not have this problem with either Firefox 4 or any other new application you might choose to install int eh future.
(In reply to comment #8)
> THe issue here is that more modern applications, try to use new features in
> later versions of Windows that permit you form inside the application to
> access an extended, supplied by your printer driver preferences. 
> Applications that do not try to use this new functionality do not encounter
> the issue.

Your assertion that earlier versions of Fx work because they do not utilize the "extended, supplied by your printer driver preferences" dialog is false.  Fx 3.6 opens the same (completely identical) driver provided printing prefs dialog as 4.0, but successfully.  So I ask again, why does it work in 3.6 and not in 4.0?  It doesn't appear that you know, so who are the devs that can shed some light on this?

> This is not really a Firefox issue

If something works perfectly in version x and fails in x+1, while all other variables are held constant, it's an issue in version x+1.  Fx4 is clearly doing something differently, the question is what and why?  Only when "what" and "why" are clearly established, can one say if this change is justifiable.  Since the Fx4 way of showing printing prefs provides no discernible benefit (at least on xp) over 3.6, but only causes problems, it does not appear justifiable.
One more data point.  The MS KB article mentions Word 2007.  I tried it, and it has no trouble opening the custom, driver's printing prefs dialog.

Who are the devs who can explain what changed in Fx4 that it's unable open the printing prefs, when 3.6 has no problems?  And weather these changes make sense?
The problem started in:
firefox/nightly/2010/10/2010-10-09-04-mozilla-central/
(Reopening per comment 9, as this appears to be a regression)

Pushlog from previous nightly to the one in Comment 11:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b36eeab1df8b&tochange=d45c87e58110

Notably, there are no commits that mention "print" in that range...
Status: RESOLVED → REOPENED
Ever confirmed: true
Keywords: regression
Resolution: INVALID → ---
Aha, looks like it's from this:
> 6f304a4dfd4d	Ehsan Akhgari — Bug 286382 - Don't load DLLs from the current directory; r=bsmedberg a=blocking-betaN+
(Ah, and that's exactly what Comment 0 suggested, actually)
(Bug 286382 is still hidden as a security bug, but you can refer to its non-hidden counterpart bug 579593 for an overview of the vulnerability.)

So it appears that this is a printer driver depending on an insecure behavior in old versions of Firefox that we no longer support.

Fixing this would likely involve re-opening ourselves to that vulnerability.  Not sure whether this should be INVALID or WONTFIX, but this is probably one of those.
So the first half of Comment 5 (in which wg9s closed this as invalid), he appears to be spot-on about this.

He was apparently incorrect in the second half of that comment (per Comment 9) -- instead, that should have read:
> This was not evident in Firefox 3.x, because those versions were more
> permissive about DLL search paths.

CC'ing ehsan, as he wrote the patch in question, in case anything looks out of place here -- ehsan, is this INVALID?
Blocks: 286382
(In reply to comment #13)
> Aha, looks like it's from this:
> > 6f304a4dfd4d	Ehsan Akhgari — Bug 286382 - Don't load DLLs from the current directory; r=bsmedberg a=blocking-betaN+

http://support.microsoft.com/kb/2264107
CWDIllegalInDllSearch=2: Blocks a DLL Load from the current working directory if the current working directory is set to a remote folder (such as a WebDAV or UNC location)

Is it necessary to prevent the loading of dlls from a local current directory?  Isn't the vulnerability about dll loading from remote current directories?  It's not realistic to expect older print drivers to be updated.  Somehow latest Chrome and patched IE8, manage to be able to print, while presumably addressing this vulnerability more gracefully.

Incidentally, according to the KB, CWDIllegalInDllSearch can be configured per application.
(In reply to comment #17)
> See also http://support.mozilla.com/es/questions/816333

The workarounds have already been posted, that's not the point.  Unless you think that the current versions of IE and Chrome are still vulnerable (unlikely) there must be a way to address this vulnerability, without breaking anything, something equivalent to CWDIllegalInDllSearch=2 perhaps.
(In reply to comment #19)
> (In reply to comment #17)
> > See also http://support.mozilla.com/es/questions/816333
> The workarounds have already been posted, that's not the point.
(I wasn't directing that "see also" at you -- i was just documenting the connection between this bug & that support page)
Does anybody know where in the code we're loading those DLLs from?  I may consider exempting them from the general protection implemented in bug 286382 (although I have not made up my mind on that yet).
Can you open access to Bug 286382?
(In reply to comment #22)
> Can you open access to Bug 286382?

Unfortunately not, sorry.  The interesting part to this bug is that we've changed the way we load DLLs, which seems to break things for this printer software.
(In reply to comment #23)
> (In reply to comment #22)
> > Can you open access to Bug 286382?
> 
> Unfortunately not, sorry.

Why not?  Has it not been closed and released 8 months ago?
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> > > Can you open access to Bug 286382?
> > 
> > Unfortunately not, sorry.
> 
> Why not?  Has it not been closed and released 8 months ago?

The reason that the bug cannot be opened is because there is still some information there which could potentially help attackers exploit users.  I'm sorry that I can't share more information at this point, in the interest of protecting our users.
This fixed the problem for me:
went to http://support.microsoft.com/kb/918730, suggested above, and did the following.
To copy the printer driver files to the System32 folder, follow these steps:
    In Windows Explorer, locate the following folder:
        On a computer that is running a 32-bit version of Microsoft Windows, locate the following folder:
        drive:\Windows\System32\Spool\Drivers\W32X86\3
        On a computer that is running a 64-bit version of Windows, locate the following folder:
        drive:\Windows\System32\Spool\Drivers\X64\3
    Press and hold CTRL, and then click each printer file.
    Note Each printer driver file has a file name that resembles the following:
        lx**prpb.dll
        lx**prpr.dll
        dl**prpb.dll
        dl**prpr.dll 

In my case, I only needed to copy one file(lxbkprpr.dll)and it now works fine.
(In reply to Bill Cassel from comment #26)
> This fixed the problem for me:
> went to http://support.microsoft.com/kb/918730, suggested above, and did the
> following.
> To copy the printer driver files to the System32 folder, follow these steps:
>     In Windows Explorer, locate the following folder:
>         On a computer that is running a 32-bit version of Microsoft Windows,
> locate the following folder:
>         drive:\Windows\System32\Spool\Drivers\W32X86\3
>         On a computer that is running a 64-bit version of Windows, locate
> the following folder:
>         drive:\Windows\System32\Spool\Drivers\X64\3
>     Press and hold CTRL, and then click each printer file.
>     Note Each printer driver file has a file name that resembles the
> following:
>         lx**prpb.dll
>         lx**prpr.dll
>         dl**prpb.dll
>         dl**prpr.dll 
Note ** is a two-letter designation that is associated with the printer.
With the printer driver files selected, right-click the files, and then click Copy.
In Windows Explorer, locate the following folder:
drive:\Windows\System32
Right-click the System32 folder, and then click Paste.
> 
> In my case, I only needed to copy one file(lxbkprpr.dll)and it now works
> fine.
I found a fix for this problem here : http://theitbros.com/how-to-fix-prop-res-dll-not-loaded/
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.