Windows 7 x64 printing through a 32-bit print server 0x000007e error

BY IN Uncategorized 24 COMMENTS , ,

This week, we bit the bullet and installed Windows 7 on all 100 machines in the university library. Of course, the sensible thing to do would be to test everything works first. But where’s the fun in that?

So, 64-bit Windows 7 installed, we checked all was okay. Oops… x64 windows needs x64 printer drivers. That wasn’t a problem, and most printers were working within an hour or so. However, some of the HP printers that are in the library, particularly the HP colour laserjet 9500, proved more troublesome.
64-bit drivers added to the Server 2003 x86 server, the client machines would download the driver (we were using the HP Universal print driver PCL 6) but then fail with the following error when trying to connect to the printer:

Windows cannot connect to the printer.
Operation failed with error 0x0000007e.

So we tried PCL5. No luck. None of the HP drivers would work. Googling the error showed lots of people in the same position – with 64-bit Windows Vista or Windows 7 and a 32-bit print server. The only suggested workaround is adding the printer manually to a workstation as a local printer, and picking up the driver from a CD or download that way (not from the print server).

So… in comes procmon. Not long before the dreaded error message, spoolsv.exe looks in a registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\[SERVERNAME]\Printers\{0000-guid-of-printer-00}\CopyFiles\BIDI\Module that tells it to go find (system32) spool\DRIVERS\W32X86\3\hpcpn081.dll. This doesn’t exist, hence the ‘module not found’ error 7e. The driver installation does, interestingly, copy a newer hpcpn104.dll into this directory. Getting warmer!

Copying hpcpn081.dll from \\PRINTSERVER\print$\x64\3 to c:\windows\system32\spool\drivers\w32x86\3… printer installs successfully! So, why is it copying the wrong dll? Well, a short dig through the server’s registry reveals a key similar to the one on the client, in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\[PRINTERNAME]\CopyFiles\BIDI. The “Module” value points to spool\DRIVERS\W32X86\3\hpcpn104.dll. Change this to hpcpn081.dll and hey presto, all is fixed.

No having to deploy drivers to all machines or send the desktop teams round… just tweak this value for each of your stubborn printers!

Just go to your print server and change

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\[PRINTERNAME]\CopyFiles\BIDI\Module

from hpcpn104.dll to hpcpn081.dll

24 Comments

  1. Jeremy |

    I’m having the same issue in our environment. I’d like to attempt your fix on one of our less used printers to see if it works, however hpcpn081.dll does not exist in the x64 directory. 094 and 104 do exist and the registry points to spool\DRIVERS\W32X86\3\hpcpn094.dll

    Would you suggest changing this key to point to \\printserver1\print$\x64\3\hpcpn104.dll?

    Thanks!

    Jeremy

  2. Bryan |

    I had a similar issue. Same situation pretty much, Windows Server 2003 R2 x86 print server, Windows 7 x64 clients, and an HP printer, but in this case it was a P2055dn. Both the universal print driver and the 2050 series exhibited the same 0x0000007e error when using point and print.

    I was hoping it was the same issue as yours, but it wasn’t quite the same. In my case, the installation was looking for an hpcpn093.dll in the following directory on the client, which didn’t exist:

    C:\windows\system32\spool\drivers\x64\3\spool\drivers\w32x86\3\

    That looks to me like someone botched that up a bit, maybe goofed up a slash or mixed up a relative/absolute path or similar, but in any case, I created the directory structure from the second “spool” on down and copied the hpcpn093.dll there. That allowed the driver to install on the client instantly.

    Of course, that doesn’t fix any of the clients that don’t have that .dll in the right location, but I’m sure searching the registry on the server or the install .inf files for that string will turn up where that install is going wrong.

  3. mmody |

    hey thanks for this info. do you know if this will work for any hp printer or just the mentioned printer above. I am in a similar situation: W2K3 x86 printer server, running SP2 and clients running W7x32/x64. The W7x32 was an easy fix during deployment, however, running into the same 0x0000007e when trying to install the network printer – hp p4014dn. I have the 64-bit version of the driver shared. Running the Microsoft patch – 982728 does not resolve the issue, nor does copying the mscms.dll to the required directories.

  4. Neil |

    I had this problem and tried the fix and it seemed to resolve some of the issues but other printers are being stubborn. I actually copied the file it was looking for from the keys in the registry on the server to the clients. Now I’m having some issues on XP clients when trying to print to the queue. I can add the printers but when I try to print a test page it immediately says “test page failed to print would you like to start the troubleshooter?” The troubleshooter is worthless. I can print to the printer if I set it up as a direct ip printer though. Any thoughts?

  5. FunkPumpkin |

    Thank you for documenting this issue. I have a HP Pavilion DM4 running W7Pro64 and initially could not get it to connect to the HP2420 printers here at work.

    Your documentation above put me on the track to fix my issue as well. Thanks again!

  6. David |

    Thanks for the post. Copying the hpcpn111.dll file from the x64 directory to the x32 directory, along with the registry change worked for our HP9040.

    Wow, what a pain in the you-know-what. Never would have figured one out on my own.

  7. Billy Mutafov |

    You nailed it
    I can install stubborn drivers now.
    One question, how did you find your way around with procmon? Even when you filter by process, if you don’t know what to look for you wouldn’t understand what is going on, or at least I wouldn’t 🙂

  8. Tim Braun |

    This helped point out the problem in our environment – mismatched 32-bit and 64-bit print drivers. In our case the numbers in the file names were 111 and 112, and we only had two 64-bit clients to update. So I installed the new (112) 64-bit driver and added a printer going to the printer directly. This copied the new driver files to the client. Then added the printer with the network server connection, which copied the old driver files (minus the new BIDI module) to the client. Client uses new 112 BIDI file and the rest of the 111 files from the server. Printing works from 64-bit client to 32-bit server.

    I’d update the 64-bit driver on the 32-bit server, if I could figure out how.

  9. Shawn |

    I can’t seem to get this fix to work. I don’t see the same .dll files that you mention. Is there an update to this fix?

  10. Travis Runyard |

    Thank you for posting this. My issue was very related to this one but after tracking the Module reg entry, it was correct on client and server. I actually had to give TrustedInstaller and System accounts limited permission to the Printers key because spoolsv.exe would try to delete it before I could read it. I ended up using the string from another printer using the HP UPD and it worked with HP M5035.

  11. Michael |

    With a bit of assistance from this entry I was able to fix a very similar issue. Have you found any documentation about why this would have changed to the 104.dll? We are switching to Windows 7 at our organization (over time) and just ran into this but are unsure how it happened. Both XP users and Win 7 users experienced issues. Is this a flaw or problem with using Server 2003 and Windows 7?

  12. Paul |

    I cannot find hpcpn081.dll on our Server 2003 nor on the windows 7 64bit pc where do I find it. Thanks.

  13. DuaneK |

    Ant,
    You are da man (unless of course, you’re a woman).
    I agree with others that I would not have figured this out on my own (or as the KJV says it, mine own). This fix has saved my bacon and our deployment of a new print server. Interesting that only the HP UPD PS driver 5.3.1 was having this hiccup (Windows cannot connect to the printer. Operation failed with error 0x0000007e), and only on some printers. Prior to this fix, printer connections worked fine from my test Win7 x64 client for some printers using the same driver, but not others (failed). Now I can map any of the printers.

  14. unni |

    hi,
    thanks for your comments… I have the same problem rectified now.
    thankyouverymuch

  15. tojnk |

    Same problem here for our CM3530.

    Changing hpcpn082.dll to hpcpn093.dll did the trick.

    Thanks a lot!

  16. Anony |

    Thanks, I retraced your steps to fix a similar problem with my HP laserjets. The fix for me was to copy over the 64 bit drivers from my 32bit print server and copy them to the w32x86 directory manually.

    (It essentially tricked windows into using the 64bit drivers in the 32bit directory). The best thing about this is it is just a slight modification to our 64bit clients, when we upgrade to 64bit 2008 R2 server this shouldn’t be an issue.

  17. slyork |

    Thanks, using this article I was able to sort out my printer problem with Windows 7 64bit drivers and the HP Universal Printer Driver PCL6

  18. Nile |

    I chose Bryan’s approach from Sep 29,2010 (see his earlier comment above):
    Placed x64 DLL that the printer relies on from Server’s correct location to Client’s screwed up perceived location:
    C:\windows\system32\spool\drivers\x64\3\spool\drivers\w32x86\3\
    Mapped fine after this.

  19. Lannar |

    thanks for this post. We had a similar issue, but with a twist. We have two physical printers of the same model (Laserjet 4250) shared from a x86 server with the same driver specified for each (PCL5e). For some reason we could map one of them on the x64 client machines, but not the other.
    Looked into the registry keys mentioned and found the ‘CopyFiles’ key didn’t exist for the printer that we COULD map, but it was there for the bad printer, pointing to the w32x86 as mentioned.
    Since the other printer is working, I backed up the registry and just deleted the copyfiles key from the non-working printer, and am now able to map the printer. Printing seems to be working fine, so no negative impact thus far.

  20. Gilles |

    Another solution : remove the subkey COPYFILE on the server (or rename it) as BIDI files are not necessary. It works for an P2055 and P3015 ….

  21. TPK |

    Gilles, You are right.

    It seems that old versions of HP drivers used that COPYFILE registry setting.
    New installation of latest(06/2013) universal driver do not include that.

    Removing it fixed our(my) problems with x64bit Windows 7 and 32bit and Server 2003 working as printer server. Our printers are HP 6030 and 6040 MFP series.

  22. Procmon instructions Issue with Xerox |

    I was wondering if you could give a brief overview of how you used procmon to solve this issue. I am seeing this same error but with Xerox printers. There are no references in the registry to the same or even similar dll files on the server or client, that I can find so far anyway.
    Xerox support was no help, so I need to find out how they messed up their driver, and fix it.
    Thanks,
    Ribs

  23. Shah |

    The same error is getting in my windows 8.1 pro system,But the problem is happening only if i try to add hp laserjet 4700 color printer from the server.My print server is windows 2012 R2 and i have installed PCL6 universal driver for this printer.I haven’t seen the specified .dll file in both server and client .There is a different file hpcpn6de.dll ,Please suggest a solution

  24. Tim |

    Conflicting HP printer drivers will cause problems on the server and on clients. For example, I was using 3 different HP drivers for 3 different laserjets on Server 2008 32-bit. When I switched to the HP Universal driver on the server, some of the printers would not install with the error message listed at the top of this page. I did not remove the older HP drivers when I installed the Universal driver (which I should have done). Looking at the registry entries for the printers, there were DLL entries for files that were no longer on the server (in the path located in the registry entry). So, I deleted the HP printers on the server, deleted the HP printer drivers and packages. Reinstalled the printers and the HP Universal driver…now they all work fine (32-bit and 64-bit)

So, what do you think ?