none
Windows 7 Printer Problems

    General discussion

  • I have approximately 24 new PCs built with Windows 7 Enterprise. A handful have had problems with the printers installing. Models are HP Color LaserJets 2250, 2840, 4250. Other models such as the HP LaserJet 3055, Canon iR4570 and iR5055 install with no problems. The PrintService event logs have error EventID 808 "The print spooler failed to load a plug-in module mscms.dll, error code 0x7e". I have not found any conclusive fix. I can set up the printer as a local printer to the port but not when using the network shared printer from the Win 2003 Std print server. I have checked the region settings as some have suggested but no problems there. If I try to install assigning the sharename as the local port address then it fails install asking for a file that is not part of the driver files provided by the vendor for this printer "HPBMIAPI.DL_". I have attempted using both the Windows Vista compatible drivers and the latest version of the HP Universal Print driver.  I have attempted to replace the mscms.dll file from a good machine to the bad machine and Windows 7 will not release control of the file having attempted steps to takeown /f and cacls /g :F to give full access control of the file. Attempt to regsvr32 as admin results in error, "The module 'mscms.dll' was loaded but the entry-point DLLRegisterServer was not found. Make sure that 'mscms.dell' is a valid DLL or OCX file and then try again." This has affected 3 out of 16 desktops just built and at least 1 out of 9 laptops (have only attempted on 2 laptops thus far, 7 of those are of unknown status).

    Any suggestions other than flatten and start over?

    Thursday, April 29, 2010 1:22 PM

All replies

  • 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

     

     


    Alan Morris Windows Printing Team; Search the Microsoft Knowledge Base here: http://support.microsoft.com/search/Default.aspx?adv=1
    Friday, April 30, 2010 4:00 PM
    Answerer
  • We have also this problem with eventid 808 and mscms.dll

    Tried the workaround with copy the .dll to spool\drivers\x64\3 and it worked.
    Is it possible to say what is the reason why the path of the dll is changed or
    is not reset back to default.  (Printerdriver ? ).

    We have this issue with 2 different printers (Canon , HP).

    Hope for the better solution mentioned from Alan

     

     

    Wednesday, May 19, 2010 4:28 PM
  • I'm still poking the right people.  Will update all when I have something to give you.
    Alan Morris Windows Printing Team; Search the Microsoft Knowledge Base here: http://support.microsoft.com/search/Default.aspx?adv=1
    Wednesday, May 19, 2010 6:51 PM
    Answerer
  • Yes, the better solution will be delivered soon. Till then, please use the workaround to copy the dll.

    Friday, May 21, 2010 9:02 AM
  • Yes... please let us know what you find.

    Same issue (The print spooler failed to load a plug-in module mscms.dll, error code 0x7e. See the event user data for context information.)

    Thursday, June 10, 2010 3:29 PM
  • Not yet.
    Alan Morris Windows Printing Team; Search the Microsoft Knowledge Base here: http://support.microsoft.com/search/Default.aspx?adv=1
    Friday, June 11, 2010 3:49 AM
    Answerer
  • I suppose this is the solution: http://support.microsoft.com/?kbid=982728

    Ingo

    Tuesday, July 6, 2010 9:06 AM
  • I am having the same issue (Event ID 808) in my environment (Windows 7 64-bit clients with 2008R2 print server). Any updates on this matter?

    I checked the registry key on my server referred to above and none of my printers (64-bit) have the ..\CopyFiles\ part of the key. I went ahead with copying the mscms.dll to \windows\system32\spool\drivers\x64\3 as suggested above on a couple of client computers. Waiting to see the result of that.

    Friday, October 22, 2010 8:05 PM
  • Hui2 has the correct QFE link for the client side fix. 
    Alan Morris Windows Printing Team
    Friday, October 22, 2010 9:24 PM
    Answerer
  • I am having the same issue (Event ID 808) in my environment (Windows 7 64-bit clients with 2008R2 print server). Any updates on this matter?

    I checked the registry key on my server referred to above and none of my printers (64-bit) have the ..\CopyFiles\ part of the key. I went ahead with copying the mscms.dll to \windows\system32\spool\drivers\x64\3 as suggested above on a couple of client computers. Waiting to see the result of that.


    Did this end up working for you?
    Tuesday, November 2, 2010 5:53 PM
  • the hotfix on the KB Article is down. You would think there would be a server side fix for this.
    Tuesday, November 2, 2010 5:55 PM
  • We've just hit this issue during a large Windows 7 rollout.

    500+ Windows 7 Enterprise machines had a Canon colour print queue mapped via group policy, all working fine. We then had to update the driver for this print queue, after which 100's of clients are suddenly broken and unable to install printers. We are seeing a combination of the existing queue being present but broken due to not pulling down the updated driver correctly and ending up in a non functional halfway state, and also inability to connect to other network printers which they had previously been able to connect to. It's a bit of a mess.

    Errors are as above "The print spooler failed to load a plug-in module mscms.dll, error code 0x7e. See the event user data for context information"


    Looking at Alan's earlier post it mentions looking at the following key on the server:

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

     and seeing if the module value is set to \windows\system32\mscms.dll  or just mscms.dll?

    I confirmed it was set to mscms.dll in our case on a W2K8 server. However, looking further at a different Windows W2K3 print server I have running over 500+ queues of various makes and model of printer, serving ~2000+ Windows XP clients, EVERY single instance of the 'copy files' key has the module path set to just mscms.dll. None of them refer the path as being in \windows\system32\

    What i'm not clear on is what trigger's the issue? If i rebuild an affected machine it seems to fix the problem, so there doesn't seem to be a problem with the newer driver. In most cases, if i simply reboot the machine it fixes the problem. So it can't just be the value of the 'copy files' key on the server can it? Otherwise my machine would still be broken when i rebuilt it and reconnect to the same queue? There must be more to it.

    In addition, when connecting to various HP print queues from broken machines, we are seeing other modules failing to load such as

    "The print spooler failed to load a plug-in module spool\DRIVERS\W32X86\3\hpcpn6dn.dll, error code 0x7e. See the event user data for context information"

    "The print spooler failed to load a plug-in module spool\DRIVERS\W32X86\3\hpcpn083.dll, error code 0x7e. See the event user data for context information."

    What's even stranger is we scripted a reboot of the affected machines, thinking it would fix them all, but it didn't. However if we manually reboot a machine whilst stood in front of it, in most cases it does fix the issue. This has taken up a lot of our time, and seriously impacted our service, and we still don't have a black and white answer as to what the problem is, and the problem doesn't appear to be easy to replicate either.

    I've seen reference to the hotfix, which we're testing, but it's not clear exactly what it does, or why the problem sometimes does or doesn't appear. I'm assuming it doesn't fix all 0x7e errors, as it appears this error can be caused by  other issues such as permissions, or even a Windows XP driver that doesn't support Windows 7.

    A more detailed explanation of the problem would be extremely useful, as there are a lot of threads on the net pointing to this one, but fairly vague explanations as to the root cause of the problem, what the hotfix does, and whether or not it only fixes the mscms.dll issue or other failing modules under the 0x7e error as well.

    Monday, January 31, 2011 3:10 PM
  • The hot fix only affects the issue when the print driver sets the install path and the spooler loses track.  The fix in localspl.dll allows the spooler to find the files rather than use the path specified by the print driver.  I've not seen an HP driver cause the mscms.dll failure.  For the HP modules, HP will need to address this.  They actually have with the 64bit version of the driver.  After a couple conversations with an HP driver developer, deleting the CopyFiles\BIDI key from the print server printer definitions allows the 64bit machines to connect since they will no longer attempt to copy and load a 32bit binary.

    I would expect the HP module load issue only on 64bit clients.


    Alan Morris Windows Printing Team
    Monday, January 31, 2011 5:04 PM
    Answerer
  • The hot fix only affects the issue when the print driver sets the install path and the spooler loses track.  The fix in localspl.dll allows the spooler to find the files rather than use the path specified by the print driver.  I've not seen an HP driver cause the mscms.dll failure.  For the HP modules, HP will need to address this.  They actually have with the 64bit version of the driver.  After a couple conversations with an HP driver developer, deleting the CopyFiles\BIDI key from the print server printer definitions allows the 64bit machines to connect since they will no longer attempt to copy and load a 32bit binary.

    I would expect the HP module load issue only on 64bit clients.


    Alan Morris Windows Printing Team

    Alan, thanks for the reply.

    Are you saying that the issue specifically arises when the module value under the copy files key, is set to just 'mscms.dll' rather than \windows\system32\mscms.dll? Is that the trigger that upsets Windows 7/W2K8R2 machines?

    If that is what you are saying, we are not seeing it as being that black & white unfortunately. For example, if i rebuild an affected PC (using the same SCCM image) and reconnect it to the same print queue as before (which is now using the updated driver), why doesn't it break again?

    Regarding the HP modules errors I mentioned, these are occurring on 32bit Windows 7 Enterprise. We havn't rolled out 64bit yet. Admittedly though i need to do more testing on this to be sure the issues are connected.

    Monday, January 31, 2011 6:11 PM
  • No it's a driver issue that resets the install path and the spooler can't find mscms.dll even though it's sitting in \system32.  The change in localspl.dll resets any path changes to include all the system default paths.  The trigger is the driver you install that changes this.  I know Konica Minolta had some drivers that did this but there latest driver set for the same class of device does not. 

    Not sure on the HP file set.  All I know about is the BIDI issue MS IT hit years ago and still encounter it.


    Alan Morris Windows Printing Team
    Tuesday, February 1, 2011 12:24 AM
    Answerer
  • No it's a driver issue that resets the install path and the spooler can't find mscms.dll even though it's sitting in \system32.


    Alan Morris Windows Printing Team
    Alan, I'm a little confused now. You're reply above appears to indicate the issue is NOT dependant on the 'Module' registry value (which was what i queried), but is caused by a driver issue. Yet earlier in the thread your post suggested it WAS because of the 'Module' registry value!

    Surely the driver issue and the incorrect 'Module' value are one and the same thing?

    ie: IF the Module value under the Copy Files key, were set to just 'mscms.dll', that WAS the driver problem, and the error occurs. At least that's what i read your post to mean.

    Apologies if i'm missing something obvious here?

    Tuesday, February 1, 2011 6:19 PM
  • No you are not missing anything.  I posted the suggestions before I tracked down the issue to the work item for this problem and before the release of a QFE.  I editted the previous post.


    Alan Morris Windows Printing Team
    Tuesday, February 1, 2011 7:09 PM
    Answerer
  • Alan,

    Thanks for clarifying. This makes things a little clearer.

    However in our case it doesn't explain why the issue arose when we changed the driver, but doesn't re-occur if the machine is rebooted (which seemed to fix the issue in some cases) or rebuilt altogether. One would expect that if the newer Canon driver we installed caused this issue, that same driver would continue causing the issue regardless of the machine being rebooted or rebuilt. I don't know if you have any thoughts on our observations of this.

    Moving forward, I need to resolve this one way or another, and fairly quickly, as this is holding up the roll out of our new Canon managed print service. As such it looks like we may have to deploy this patch across our domain. I know the KB article states "Apply this hotfix only to systems that are experiencing the problem described in this article", but clearly it isn't practical to install this on hundred's of individually affected machines. It is going to have be an all or nothing rollout in our case. Is this what you would advise?

    I note that KB982728 is included in Windows 7 SP1, but unfortunately we can't wait that long. Do you know if KB982728 will remain unmodified when bundled in SP1?

    Am i right that the root cause of all this is the Canon driver? If so, I guess it is also worth us raising this issue through our Canon contacts?

    Finally, out of interest, any idea why this only affects Windows 7/W2K8R2, and not Vista,W2k8 and XP?

    Wednesday, February 2, 2011 1:34 AM
  •  If the driver does get installed but it's just the connection that is not created then a reboot getting this working makes sense.  With the driver already installed on the first connection attempt, the spooler will copy down the files for the driver from the server but once it checks that the files are the same, the previously installed driver is used and the connection is created without a new driver install.

    Roll it out!

    The changes made for the QFE are included in SP1.

    The driver is resetting the path but the spooler is the one getting lost.  There were changes make in Windows 7 / 2008 R2 to determine where the files were coming from the server and if these were proper for the client platform.   So attempts to make sure that files from \\SERVER\print$\w32x86\3 where not copied to a 64bit machine caused other problems in core spooler. 

    The change to check the binary source location was never made for Vista as a QFE so you can still copy files from the wrong source.  XP? I know there is a lot out there but changing in that code base are to address security exploits.


    Alan Morris Windows Printing Team
    Wednesday, February 2, 2011 6:49 AM
    Answerer
  •  If the driver does get installed but it's just the connection that is not created then a reboot getting this working makes sense.  With the driver already installed on the first connection attempt, the spooler will copy down the files for the driver from the server but once it checks that the files are the same, the previously installed driver is used and the connection is created without a new driver install.

    Roll it out!

    The changes made for the QFE are included in SP1.

    The driver is resetting the path but the spooler is the one getting lost.  There were changes make in Windows 7 / 2008 R2 to determine where the files were coming from the server and if these were proper for the client platform.   So attempts to make sure that files from \\SERVER\print$\w32x86\3 where not copied to a 64bit machine caused other problems in core spooler. 

    The change to check the binary source location was never made for Vista as a QFE so you can still copy files from the wrong source.  XP? I know there is a lot out there but changing in that code base are to address security exploits.


    Alan Morris Windows Printing Team

    Alan, some more feedback on this, I've just discovered that rolling this out, is not that easy, as Microsoft doesn't offer this hotfix in the WSUS catalog, and as the download is an msu format, it seems i can't roll this out by WSUS anyway. Microsoft's explanation of this appears to be that this type of hotfix, is only intended to be installed manually on affected machines. Well ok, i know that, but now that puts us between a rock and a hard place.

    Considering this is going into Windows 7 SP1, is there a reason it isn't on the WSUS Catalog?

    Regarding the query on Windows XP, my question was why doesn't the issue affect XP, NOT why aren't Microsoft releasing a fix for it.

    I know microsoft has a patch to fix this, but can you clarify if the root cause of all of this is the Print vendor's drivers (Canon in this case) mucking things up, or an issue with Microsoft's Windows 7? I ask as it only seems to be Windows 7 that is affected?

    Thankyou for your feedback on this issue by the way. I appreciate your input on this.

    Monday, February 7, 2011 5:04 PM
  • No clue on WSUS stuff.

    No affect on XP is for the same reason as no impact on Vista.  "The change to check the binary source location was never made for Vista as a QFE so you can still copy files from the wrong source."

    Windows 7 RTM relied on the driver NOT reseting the search path since most do not

     


    Alan Morris Windows Printing Team
    Monday, February 7, 2011 8:18 PM
    Answerer
  • Hi markey164

     

    Its not directly a hint for this printer problem, but with your problem to deploy the hotfix over WSUS.
    Last night i found this helpy little bit of software by accident: http://localupdatepubl.sourceforge.net/  (this great blog made me find it, sorry for the ad but this blog is simply great for every it technician (especially if you work in education business) --> angrytechnician.wordpress.com)

    I didn't tried it by myself until now, because i didn't had the time today :( But i read the description of it and it should also fit your requirements! Also for other update deployment etc.

    Good luck with it, if you decide to give it a try!

    Greetz

    Friday, May 27, 2011 2:48 PM
  • Hi,

    The printer connected to your Windows 7 requires drivers to function.

    Drivers are the translators between the printers and the Operating System, and issues with the printer drivers would cause printer not functioning issue.

    All Windows 7 users facing printer not working problem are suggested to verify the printer drivers installed on the system using the device manager.

    If the printer drivers are found incorrect, incompatible, or illegitimate, then the drivers would have to be replaced to solve the problem.

    Get more information to fix windows 7 printer problems :

    http://printers.iyogi.com/help-support/windows-7-printer-not-working.html

     

    Hope this information helps you.

     

    Tuesday, August 16, 2011 5:03 AM
  • I changed the registry key on the print server to specify C:\windows\system32\mscms.dll and it seems to have resolved the issue. I suppose you could also change it to %windir%\system32\mscms.dll
    Tuesday, April 24, 2012 5:49 PM
  • Thank  you Alan,

    I have Win 7 32 bit clients connecting to Server 2003 print servers. Thanks to your work, I now am able to resolve Win 7 connection issues by either Deleting the CopyFiles registry key or repointing the Modules key to C:\windows\system32\mscms.dll  . Either works, however, I expect it to be a fairly large remediation task.

    My real question is..Why do some (at least half) of my Win 7 Clients successfully add the print queues? The Win 7 clients are all created from a consistent corporate image and deployed in groups. I have seen no consistency in why (or why not) the network printers get added, however, your fix will consistently cure the problem accross the board.

    Thanks to you, I understand what is happening when it fails, I just don't know why it does not always fail.

    Thank you for the resolution

    Wednesday, June 6, 2012 7:23 PM
  • we are having the same issue with  event id 808  on windows 7 PCs connected to a server running server 2003.
    Thursday, December 20, 2012 11:27 PM
  • I know this is an old thread.  Error on W7x64 printing to network printer: "Test page failed to print. Would you like to view the print troubleshooter for assistance?"  Could print to network printer, just no go on test page.

    Solution was: check event viewer on W7 PC- search for source: PrintService.  In my issue, had Event ID: 808 C:\widnows\system32\spool\drivers\x64\3\fxsui.dll 0x7e error.  I copied a working W7 printing PC 3 folder to PC with issue- was missing a lot of dlls in the "3" folder.  Restarted print spooler. Test page now works.

    Friday, July 29, 2016 1:20 PM