Let’s say you’re running Windows 7 on a computer connected to a local network. There is a shared printer running on a different machine on the network. The drivers for the printer are installed on the remote machine, and the printer is shared.

You think that you’ll just sit down at your puter, use the Add Printer feature, connect to the remote printer, the driver will be copied over to your machine automagically, and you’ll be off and running. But then you see this:

Windows cannot connect to the printer. Operation could not be completed (error 0x0000007e).

There is a common solution you can find on the web involving creating a new local port and inserting the network path to the remote printer, but you may find that doesn’t work either!

The solution to your problem is very simple, and is even available as a Hotfix from Microsoft. You don’t really even need the hotfix, though. Here’s how you “fix the glitch”.

It turns out that this “cannot connect to printer” error (0x0000007e) is well-known to Microsoft. Check out this Technet forum thread entitled “Windows 7 Printer Problems”:

winerror  0x7e
126 ERROR_MOD_NOT_FOUND <–> 0xc0000135 STATUS_DLL_NOT_FOUND

When the printer was added to the server, the driver created a registry to copy this file which in not neccessary since the client already has the file.

During the connection process, the driver resets the path from \windows\system32 to the print drivers directory \windows\system32\spool\drivers\x64\3 (or w32x86\3)  but never sets it back to default and the spooler process does not reset it either and looks for the color module mscms.dll in the drivers directory.

Look at the registry setting of the problem printers on the server

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\PRINTERNAME\CopyFiles

Is the module value  \windows\system32\mscms.dll  or just mscms.dll?

I think if you copy the mscms file to the drivers directory on the client you can workaround this issue.  You could also remove the data from the Module value and verify creating the connection succeeds and printing is as expected.

Further down the thread, we find there is actually a hotfix available:

I suppose this is the solution: http://support.microsoft.com/?kbid=982728

It turns out this hotfix will be included in Windows 7 SP1!! Apparently Microsoft didn’t think it was important enough to test the fix thoroughly and release it early – despite the huge number of people having this problem if my search results are any indication.

You can request the hotfix if you really want to, or even wait for Windows 7 SP1, but the “workaround” is so simple that there’s no point in trying the other options:

  1. Go to the C:\Windows\system32\ directory and find the file “mscms.dll
  2. Copy that file to:
    • C:\windows\system32\spool\drivers\x64\3\ if you are using 64-bit Windows 7
    • C:\windows\system32\spool\drivers\w32x86\3\ if you are using 32-bit Windows 7

That’s it.

Now try to connect to the remote printer again. This time, it will work!

This error does not appear to depend on the type of printer you have, or what driver you use. On 10 computers, I saw the problem 5 times. It seems to be a toss-up as to whether it will happen or not.

Hopefully now you won’t have to spend 4 hours looking for the solution like I did!

If all else fails, you can always treat yourself to a new printer!

Need help? Hire me!
Get Scottie Stuff!