none
Print drivers on windows 7 clients missing dependent files..?

    Question

  • Hello All,

    I am having a strange issue with a handful of our windows 7 clients.

    What we have:

    Recently I have setup a new 2008 R2 x64 server to hosts the printers in our school district. I have tried to keep things simple by using global print drivers that are available.  I only have the lastest hp global driver, the lastest xerox global driver, a dell printer driver, and a minolta driver. All of out client machines are running windows 7 enterprise and are both x64 and x86.

    The Problem:

    A handful of windows 7 machines seem to be missing the dependent files that should be listed under the properties of the driver in "print server properties". It has happened on x64 and x86 clients and pretty much prevents the clients from using any functionality of the printer they are connected to. At first I thought it may have been a xerox driver issue, but after seeing the issue on a few hp printers I am thinking its a problem with point and print somewhere? Any information that may help us resolve this problem would be greatly appreciated, thanks for your support! :D

    Monday, May 07, 2012 2:42 PM

Answers

  • The article at http://support.microsoft.com/kb/2864755 has been updated.  I think next month they will actually link the download to the article.

    Resolution

    To repair the printer, remove and reconnect the network printer that is using the problem driver.

    To prevent the issue from occurring, apply the hotfix for KB 2896881 - 

    http://support.microsoft.com/kb/2896881
          (http://support.microsoft.com/kb/2896881)    


    "Long logon time when you use the AddPrinterConnection VBScript command to map printers for users during logon process in Windows Server 2008 R2 SP1"

    Alan Morris Windows Printing Team

    Friday, November 22, 2013 1:26 AM
    Answerer

All replies

  • Hi,


    Do you mean point and print Restrictions Policy?


    For details: http://gps.cloudapp.net/Default.aspx?PolicyID=2211; http://gps.cloudapp.net/Default.aspx?PolicyID=2212


    To isolate printer driver issues, please install a Generic Text Only printer on the computer

    a. open the Devices and Printers.
     
    b. Choose "Add a local printer".

    c. In the "Install the printer driver" tab, select "Generic" in the "Manufacturer" list box, and select "Generic / Text Only" in the "Printers" list box.

    d. Follow the wizard to complete the printer installation.
     
    e. Logon to and install the Generic Text only network printer.

     


    Hope this helps!


    Best Regards
    Elytis Cheng


    Elytis Cheng

    TechNet Community Support

    Thursday, May 10, 2012 9:26 AM
    Moderator
  • rwalter,

    Did you get anywhere with this issue? We have a Windows 2008 R2 print server, currently only running HP Universal print drivers and are seeing very similar symptoms on our Windows 7 x64 Enterprise clients. Essentially the printer driver stops functioning and if you look on the client at the following registry location there is some differences from a working client.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 6 (v5.4)]

    "Dependent Files"
    "Help File"
    "Monitor"

    As you point out this results in missing depending files and print monitor being displayed in the print server properties interface. In our scenario the above registry keys are all blank on a client which shows the issue. Reimporting these keys from a working client has so far resolved the issue. Our next plan of action is to try and setup audting on these registry keys.

    Monday, May 21, 2012 1:44 PM
  • I have not found the source of this problem yet. Our client machines have a lot of older print drivers installed from our old print server and I thought they may be messing with the universal driver since some of the files are the same. I have been removing the older drivers on the clients and letting the server install the new universal driver and it has worked, but we have a lot of client machines and are still looking for a solution.

    I am working on a script to remove all the installed printer drivers and have found many articles regarding the removal of printer drivers. My problem seems to be that even with no printers connected, and no clients logged into the machine the drivers are in use and I am unable to remove the driver package. I was working with this which has been working so far http://members.shaw.ca/bsanders/CleanPrinterDrivers.htm


    -Richard R. Walter

    Monday, May 21, 2012 2:02 PM
  • Richard,

    *If* we are seeing the same issue, I note our environment is a brand new domain with freshly installed print server (2008 R2) running only HP universal print drivers. Also all clients have been deployed in the past few weeks so we have very little if anything, in regards old drivers etc on them. We have also seen on these freshly deployed machines difficulty removing drivers with them being reported in use.

    We have ensured no print queues are configured with these drivers, rebooted, restarted spoolers, etc etc and the only way we have managed to remove them is by modifying registry.

    If we make any progress Ill report back.

    Monday, May 21, 2012 3:28 PM
  • Hi Richard and Surry44,

    We are seeing what I think is the same issue as you and I was very happy to find your post which led me to the registry key in question. Our symptom is that the printing preferences dialog for a Xerox printer (using the Xerox Global Driver) is replaced with a low functionality unbranded dialog instead.

    If I repopulate the values below with the correct entries from a working computer the issue is reversed and the correct printing preferences dialog shows again.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\Xerox Global Print Driver PS]

    "Dependent Files"
    "Help File"

    I ran an audit on the registry key and got the following output which says the spooler service made the change:

    Log Name: Security
    Source: Microsoft-Windows-Security-Auditing
    Date:          30/05/2012 13:40:17
    Event ID:      4657
    Task Category: Registry
    Keywords:      Audit Success
    Description: A registry value was modified.<o:p></o:p>

    Object Name:  \REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Drivers\Version-3\Xerox Global Print Driver PS
    Object Value Name: Dependent Files
    Handle ID:  0xae4
    Operation Type:  Existing registry value modified<o:p></o:p>

    Process Information:
    Process ID:  0x458
    Process Name:  C:\Windows\System32\spoolsv.exe<o:p></o:p>

    Change Information:
    Old Value Type:  REG_MULTI_SZ (New lines are replaced with *. A * is replaced with **)
    Old Value:  xUNIVPHT.ini*xUNIVPHT.cfg*x2upHT.dll*x2rpsHT.dll*x2wfuvHT.dll*x2guiHT.dll*x2coreHT.dll*x2utilHT.dll
    *x2rnutHT.dll*x2comsHT.dll*x2jobtHT.exe*x2ptpcHT.dll*x2fputHT.dll*x2txtHT.cab*x2UNIVHT.cab*x2JARHT.cab
    *x2fpbHT.exe*xlibeay.dll*x2fpd02.dll*x2UNIV.ppd*PSCRIPT.NTF*PS_SCHM.GDL*PSCRPTFE.NTF

    New Value Type:  REG_MULTI_SZ (New lines are replaced with *. A * is replaced with **)
    New Value:  <o:p></o:p>

    -----------------------------------------------------------------------------------------<o:p></o:p>

    Log Name: Security
    Source: Microsoft-Windows-Security-Auditing
    Date: 30/05/2012 13:40:17
    Event ID: 4657
    Task Category: Registry
    Keywords: Audit Success
    Description: A registry value was modified.<o:p></o:p>

    Object Name:  \REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Drivers\Version-3\Xerox Global Print Driver PS
    Object Value Name: Help File
    Handle ID:  0xae4
    Operation Type:  Existing registry value modified<o:p></o:p>

    Process Information:
    Process ID:  0x458
    Process Name:  C:\Windows\System32\spoolsv.exe<o:p></o:p>

    Change Information:

    Old Value Type:  REG_SZ
    Old Value:  PSCRIPT.HLP
    New Value Type:  REG_SZ
    New Value:  

    I'm logging this with MS for assistance so will report back any outcome from that call.

    Cheers,
    Simon.


    • Edited by screendj Wednesday, May 30, 2012 3:51 PM
    Wednesday, May 30, 2012 3:50 PM
  • screendj,

    That is exactly the problem we are experiencing. Your audit says it all! I would greatly appreciate your findings once you are done with your MS call. Thanks again for the reply! 


    -Richard R. Walter

    Wednesday, May 30, 2012 4:08 PM
  • This was in the event log of one of our machines with the dependency issue.

    Log Name:      Microsoft-Windows-PrintService/Admin
    Source:        Microsoft-Windows-PrintService
    Date:          5/3/2012 10:05:30 PM
    Event ID:      215
    Task Category: Installing a printer driver
    Level:         Error
    Keywords:      Printer Setup,Printer
    User:          SYSTEM
    Computer:      MHRM118PC01
    Description:
    Installing printer driver Xerox Global Print Driver PS failed, error code 0x20, HRESULT 0x80070020. See the event user data for context information.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-PrintService" Guid="{747EF6FD-E535-4D16-B510-42C90F6873A1}" />
        <EventID>215</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>19</Task>
        <Opcode>12</Opcode>
        <Keywords>0x8000000000000220</Keywords>
        <TimeCreated SystemTime="2012-05-04T02:05:30.282445500Z" />
        <EventRecordID>183</EventRecordID>
        <Correlation />
        <Execution ProcessID="1792" ThreadID="2092" />
        <Channel>Microsoft-Windows-PrintService/Admin</Channel>
        <Computer>MHRM118PC01.ecsdm.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <UserData>
        <SetupInstallPrinterDriver xmlns:auto-ns3="http://schemas.microsoft.com/win/2004/08/events" xmlns="http://manifests.microsoft.com/win/2005/08/windows/printing/spooler/core/events">
          <Label>InternalInstallPrinterDriverFromPackage</Label>
          <Message>InternalAddPrinterDriverEx failed</Message>
          <AdditionalInfo>-</AdditionalInfo>
          <InfPath>C:\Windows\System32\DriverStore\FileRepository\x2univp.inf_x86_neutral_4266ac7ce2556fc5\x2univp.inf</InfPath>
          <DriverName>Xerox Global Print Driver PS</DriverName>
          <InstallSection>Install_UNIVP_PS_NT60</InstallSection>
          <ProcessorArchitecture>Windows NT x86</ProcessorArchitecture>
          <PackageAware>Package aware</PackageAware>
          <CoreDriverDependencies>{D20EA372-DD35-4950-9ED8-A6335AFE79F1}</CoreDriverDependencies>
          <LastError>0x20</LastError>
          <HResult>0x80070020</HResult>
        </SetupInstallPrinterDriver>
      </UserData>
    </Event>


    -Richard R. Walter

    Monday, June 04, 2012 6:08 PM
  • Hi Both,

    I just wanted to point you in the direction of a thread my colleague has started here: http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/19bb64cc-249e-4f36-a02d-2b43703d5a0d in relation to this. It may be of interest and you also may be able to add value to the thread. Currently some suggestions there around post sp1 hotfixes which you may or may not have already applied and have feedback for?

    Cheers

    Sunday, June 10, 2012 10:52 AM
  • Hi all, we made 3 changes listed below as advised by MS support and the issue has not reoccurred - I hope this helps you too.

    1. Please disable Asynchronous RPC on the Windows 7 client machines by following the instructions below

    Disable Asynchronous RPC on the Windows 7 client by adding the following registry entry: HKLM\Software\Policies\Microsoft\Windows NT\Printers\EnabledProtocols

    Type: DWORD

    Data: 6

    2. Please disable CSR via policy on Windows 7 client- http://blogs.technet.com/b/askperf/archive/2008/02/10/ws2008-client-side-rendering.aspx 

    3. Install the print hotfix roll up package on the server as well.

    Description of an update rollup for the printing core components in Windows 7 and in Windows Server 2008 R2 

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

    • Proposed as answer by screendj Friday, June 29, 2012 12:52 PM
    Sunday, June 10, 2012 12:12 PM
  • Hi All

    I'm fighting this same issue and have a couple questions on the 3 changes:

    1.  Asynchronous RPC is typically an issue for 2003 servers from what I've seen posted elsewhere.  Is it causing issues on 2008 installations as well?

    2.  Changed this on its own and activity seems to have dropped but has reoccurred after a couple weeks :(

    3.  The print servers we have that are showing this issue are all 2008r1.  The rollup is for r2 and Win7.  Did you install this only on your server, or was the update applied to all clients as well?

    Thanks for any help you can provide


    Wednesday, July 11, 2012 1:27 AM
  • I would also like to know if each client needs the update rollup.
    Monday, October 15, 2012 8:36 PM
  • Hi All

    I'm fighting this same issue and have a couple questions on the 3 changes:

    1.  Asynchronous RPC is typically an issue for 2003 servers from what I've seen posted elsewhere.  Is it causing issues on 2008 installations as well?

    2.  Changed this on its own and activity seems to have dropped but has reoccurred after a couple weeks :(

    3.  The print servers we have that are showing this issue are all 2008r1.  The rollup is for r2 and Win7.  Did you install this only on your server, or was the update applied to all clients as well?

    Thanks for any help you can provide


    Hi, Could you advise if turning off RPC worked when the printer server was a Windows 2008 box?

    Many thanks

    Monday, December 03, 2012 3:11 PM
  • Can each of you comment as to whether the printer in question being changed is always the default printer for the user?

    There is nothing in the Windows 2008 R2 SP1 / Win 7 Sp1 rollup that addresses this particular issue (though we do want customer running the rollup on those systems regardless).

    Can you please set up some data collection on a cross set of users in hopes that we can catch what is changing the registry settings in the act?

     We can run Procmon in a way that uses very little memory, saves the events to a backing file rather than the paging file, and can be run remotely by an admin.

    Below are the steps for configuring Procmon to only grab events that access a reg key called Dependent Files:

    1.       Set Procmon to drop filtered events under Filter.
    2.       Set the Filter to “Path Contains ‘Dependent Files’”
    3.       File - Export Configuration to save the configuration to a file (ProcmonConfiguration.pmc is the default.  Use “DepFiles.pmc”)
    4.       Save Procmon.exe and DepFiles.pmc to c:\procmon folder on the client.1.      


    Command line for Procmon on the client:

    Procmon /accepteula /backingfile c:\procmon\DepFiles.pml /LoadConfig DepFiles.pmc /Quiet

     

    To use PSExec to run remotely:
    1.       Copy procmon and config file to \\computername\admin$ share.
    2.       Run the following command from the remote computer:

     

    Psexec \\<computername  /accepteula -s  -u admin username  Procmon /accepteula /backingfile <path\filename.pml> /LoadConfig <config file>


    This should get us the Procmon data for the stack information for anything touching the Dependent Files key of any printer.  Please reply to this post with the Procmon log attached or a link to it.


    Thanks in advance!

    Tuesday, January 29, 2013 3:53 PM
  • We have been having the exact same issue and don't want to turn on SSR.  We will update results in our thread:

    http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/08bc6b4b-0190-40b0-be16-8b82249148e4

    Tuesday, February 05, 2013 10:57 PM
  • We had the same problem with Toshiba drivers:

    - TOSHIBA Universal Printer - for older mfp models

    - TOSHIBA Universal Printer2 - for newer mfp models
    Only clients having the both drivers installed were missing dependent files.
    Both driver types using UNIDRV.DLL

    Our OSs:
    Clients: Windows 7 x86 & x64
    Print server: Windows Server 2008 R2 Enterprise x64
    - All patches installed

    How we solved the problem:
    As we want to keep the system as close to the standard installation and configuration as possible, we didn't want to apply all the three steps named here and first of all we didn't want to disable Client Side Rendering (we have more than 8000 clients in our network). 
    What we did: Uninstalled "TOSHIBA Universal Printer" and installed model-specific drivers for the printers that didn' t work with the universal driver 2. We kept "TOSHIBA Universal Printer2".

    Tip: This problem has something to do with UNIDRV.DLL. Do not install both PCL 5 and PCL 6 for the same printer driver either.
    Everything is working fine now.



    • Edited by Mr_Dadoo Wednesday, February 20, 2013 11:12 AM
    Wednesday, February 20, 2013 11:06 AM
  • We have exactly this same issue. We are now having a "cannot connect to printer" when trying to install drivers from a signed print server by a local admin. If the files exist in the FileRepository then the printer installs fine, but the files for the Xerox are not installing from the print server like they should be.  Someone mentioned a hotfix

    http://support.microsoft.com/default.aspx?scid=kb;en-US;2388142

    I will test and see if it helps.


    lforbes

    Thursday, February 21, 2013 3:48 AM
  • So, we have about 9000 Win 7 workstations that have been patched with KB2647753.  We still get this reoccuring "missing dependent files" problem.  Something gets reconfigured and wipes out that key.

    I have SCCM running a custom PS1 script to build an inventory file of problematic machines, and the same script is being run afterwards (after the collection populates) to fix (re-inject the filenames into the registry).

    some of the links on this page refer to a different problem.  This is clearly not a "DRIVER" issue but rather a Win 7 or Server 2008 issue. 

    Out of ~9000 Win 7 x64 systems - about 140 are regularly affected, not all the same computers, and even the reoccuring is random.

    All affected dep files seem to be related to HP print drivers that come from server...
    • Edited by Capocruz Wednesday, March 06, 2013 3:57 PM
    Wednesday, March 06, 2013 3:31 PM
  • The issue as we have been experiencing as well as you all for now 6 months is, spool svc for win7 clients are modifying the registry keys HKLM\CCS\Control\Print\Environments\Windows x64\Drivers\Version-3\....

    pick a universal or global driver, they will all eventually fail, spoolsvc is modifying the keys "dependent files" and the help file to null values, replacing these keys w/ the previous values and restarting the local spool svc will temporarily resolve the issue, til it happens again.

    I have been working w/ MS on this for much longer than I had hoped, tried the KB 2647753 hotfix etc, this will not be resolved unitl MS fixes their issue, not HPs, not Xerox's, not Toshiba, this is how spool is dealing w/ "universal printing drivers"....unforutnately many major printing vendors don't even supply model specific print drivers so your forced to use a UPD, which fails in win7...

    • Proposed as answer by tricera7 Thursday, March 07, 2013 1:33 PM
    • Unproposed as answer by rwalter Thursday, May 30, 2013 4:31 PM
    Thursday, March 07, 2013 1:11 PM
  • We currently have an issue that is similar in nature to both TRICERA7 and CAPOCRUZ - we have win 7 x64 and server 2008 r2 print servers and we are currently using Lexmark Universal print drivers V2 (a recent change to V2) - as soon as we switched to V2 we started getting several errors - including the SPLWOW64 crashing when printers with Lexmark V2 print driver are installed and freezing connections to Xen Citrix servers when V2 universal printers are loaded on system. If anyone has heard of any fixes from MS for the Universal print driver problems in Win 7 x64 /server 2008 R2 environment please let me know as this is becoming a high priority now.
    Thursday, April 25, 2013 7:01 PM
  • We are also having this problem.  2008R2 file/print role with Win7 x64 SP1 Professional clients.  Redirected folders for appdata and common file locations, roaming profile for personal registry settings, both stored on DFS (one referral enabled, forcing replication in just one direction to backup server - second target manually disabled).  Xerox Global PCL 6 driver is having the same issue.  Two-tab basic UI comes up instead of full Xerox dialog.  Our printers are deployed using machine GPO.  Since they cannot be removed manually, we removed the problem printer from GPO (currently affecting only 3 of about 15 people sharing the same policy).  We manually added that printer to those machines after forcing a gpupdate to remove the old ones.  We tried adding with the current driver and then deleting and adding again, overwriting the existing driver.  This did not resolve the issue.  Problem seems to be expanding over time - rolled out 50 machines this past weekend - had two reports on day 2, then one more today. Not sure if this will continue or not.  Will try the 3 reg keys to see if it helps but I know we've had a similar problem at another client site with GPO managed printers, Windows 7 x64 and printer dialog issues.  Did not realize others were experiencing this until seeing this post today.  I will post anything new we find.
    Thursday, May 16, 2013 6:51 PM
  • Per the other link in this thread, I've disabled async RPC and client side rendering.  Have also applied the server update noted and we continue to have the problem.  If we log in locally, delete the reg key, reboot and login to the domain again, the printer is re-added and works for a couple of days, but then the issue shows up again.  Anyone else make any headway on this?
    Tuesday, May 21, 2013 4:26 PM
  • We have removed all of our global drivers we were using for Xerox and Ricoh from our 2008 R2 x64 Print server. HP doesn't offer model specific drivers for a lot of their printers and we have several models, so we still have an HP universal driver. As of now we only see this issue with the HP universal driver. Wondering if Tricera7 has gotten anywhere with microsoft regarding this issue?

    -Richard R. Walter

    Thursday, May 30, 2013 4:31 PM
  • It looks like the real issue is when you redirect a print server Microsoft's spooler.exe service breaks whatever driver is installed. We recently redirected our print server again and went through the exact same issue again with multiple print drivers being corrupted a day. Myself and a colleague put together a .vbs script and rolled it into an .exe to fix printers for our help desk. They simply put in the computer name that is experiencing an issue and it will scan their registry for blank values in the "Dependent Files" key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3.  If it finds it it will delete it and restart the print spooler service on that computer prompting it to re-download the driver.

    This will work regardless of the domain, printer brand or driver you are using. We have seen corrupted drivers on and this has been tested with Xerox, Samsung and HP printers with multiple driver versions.  When run it will pop up a box letting you know the driver it deleted and when it is done restarting the print spooler. If no corrupt drivers are found it will also let you know. I would recommend telling your users to restart the application they are attempting to print from for best results.

    Rem Created 6/3/2013
    Rem Created by Nathan Warren and Trevor McClanahan
    Rem We were tired of fixing printer drivers after redirecting to a new print server
    Rem Fix for the DEFAULT printer driver becoming corrupted
    Rem This script will search for empty data values in the Dependant Files Reg key signifying a corrupt driver
    Rem If it finds a blank value it will delete the key associated and restart the print spooler prompting the computer to redownload the driver from the print server
    
    
    
    
    
    
    
    
    
    
    Const HKLM = &h80000002
    
    Const StartKey    = "SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3"
    Const SearchValue = "Dependent Files"
    Const MatcharrValues   = ""
    dim result
    
    strComputer = InputBox("Enter Name of the Remote Computer:","Corrupt Printer Driver")
    result = False
    
    Set reg = GetObject("winmgmts:" _
        & "{impersonationLevel=impersonate}!\\" _
        & strComputer & "\root\default:StdRegProv")
    Set objWMIService = GetObject("winmgmts:" _
        & "{impersonationLevel=impersonate}!\\" _
        & strComputer & "\root\cimv2")
    
    
    FindAndDeleteKey StartKey 
    RestartSpooler
    Message
    
    Sub FindAndDeleteKey(key)
      WScript.Echo "[HKLM\" & key & "]"
      rc = reg.GetMultiStringValue(HKLM, key, SearchValue, arrValues)
      If Not IsNull(arrValues) Then
      For Each strValue In ArrValues
        WScript.Echo """" & SearchValue & """=""" & strvalue & """"
    	next
    	For Each strValue In ArrValues
        If StrValue = MatcharrValues Then
          DelKey HKLM, key
    	  result = True
    	  Exit Sub
        End If 
    	Next
      End If
      
    
      reg.EnumKey HKLM, key, subkeys
      If Not IsNull(subkeys) Then
        For Each sk In subkeys
          FindAndDeleteKey key & "\" & sk
        Next
      End If
    End Sub
    
    Sub DelKey(root, key)
      reg.EnumKey root, key, subkeys
      If Not IsNull(subkeys) Then
        For Each sk In subkeys
          DelKey root, key & "\" & sk
        Next
      End If
      rc = reg.DeleteKey(root, key)
      msgbox "Deleting [HKLM\" & key & "]"
     End Sub
    
    Sub Message()
    	If result = True Then
    	msgbox "Corrupt Driver Deleted and Spooler Restarted"
    		else
    	msgbox "No Problems Found"
    	End If
    End sub
    
    Sub RestartSpooler()
    	
    Set colListOfServices = objWMIService.ExecQuery _
    ("Select * from Win32_Service Where DisplayName ='Print Spooler'")
    For Each objService in colListOfServices
          objService.StopService()
        Wscript.Echo "Stopped Spooler service"
          Wscript.Sleep(5000)
        objService.StartService()
        Wscript.Echo "Started Spooler service"
    	
    Next
    
    End Sub
    

    • Proposed as answer by 5cript3d Wednesday, June 12, 2013 3:05 PM
    Wednesday, June 12, 2013 3:04 PM
  • We are having the same issue described (corrupt or garbled output on multiple pages on HP UPD print). I appreciate the work around scripted solution posted as the "answer", and we are looking at using it. However, this isn't really a fix, it is a work-around. Does anyone know if Microsoft is aware of the problem and is working on a permanent solution?

    http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/e2acb625-027d-47a9-b4a7-1616e270bcbc

    http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/19bb64cc-249e-4f36-a02d-2b43703d5a0d

    http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/08bc6b4b-0190-40b0-be16-8b82249148e4

    New Windows Server 2008 R2 print servers, Windows 7 64bit clients using, machine-policy printer connections. KB2647753 installed on both servers and clients. Symptoms observed with "HP Universal Printing PCL 6" (v5.5.0, v5.6.0, and v5.6.1) driver, but not observed on Ricoh Aficio "PCL6 Driver for Universal Print" driver. Symptoms not observed on WinXP SP3 32bit clients.

    Monday, June 17, 2013 7:01 PM
  • I do agree with George here, it's a work around.  I sent a link to the support group that is investigating this issue when 5cript3d posted this last week. 

    So to answer your specific question, yes there are Microsoft people investigating this issue working toward understanding how this occurs in order to provide a permanent solution.


    Alan Morris Windows Printing Team

    Monday, June 17, 2013 7:21 PM
    Answerer
  • Thought I would post some info that may help.

    Yesterday I was deploying a series of six print drivers to some of our print servers. Those servers which I deployed the drivers too caused some workstations at those sites to have the dependent files value erased.

    This most notably happened on servers that had generated an Event 9 for every printer on the server.

    To stop logging warning events for the print spooler, in Control Panel, open Printers, right-click a blank area of the window, click Run as Administrator, click Server Properties, click the Advanced tab, and then clear the Log spooler warning events check box."

     

    - System
    - Provider
    [ Name] Microsoft-Windows-PrintSpooler
    [ Guid] {e4c60dfa-ecc5-4889-b406-e9ddd38463c8}
    [ EventSourceName] Print
    - EventID 9
    [ Qualifiers] 32768
    Version 0
    Level 4
    Task 0
    Opcode 0
    Keywords 0x80000000000000
    - TimeCreated
    [ SystemTime] 2013-07-08T20:04:24.000Z
    EventRecordID 18765783
    Correlation
    - Execution
    [ ProcessID] 0
    [ ThreadID] 0
    Channel System
    Computer xxxxxx.xxxxxx.com
    - Security
    [ UserID] S-1-5-18
    - EventData
    param1 PRNT_1751

    Tuesday, July 09, 2013 5:08 PM
  • Hi,

    was there any positive resolution on this subject?

    I hve missed the root cause from the all the posts..

    Thank you.

    Friday, July 12, 2013 1:03 PM
  • Based on Nathan Warren and Trevor McClanahan's script above .
    There is a slicker way to work around this nullified reg problem as the driver files are all present and are not corrupt. It is only the registry that requires attention/repair.

    In my organisation we have created a script which backs up ALL Dependent Files  entries (with content!) in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3

    with a new string value called Dependent Files Backup.

    The script scans the registry every couple of seconds and triggers on the two values Not matching. In the event of a mismatch, it replace the contents of Dependent files with the Dependent files Backup (rename) and then stop/starts the spooler. The users are unaware that a fault has ocurred.

    The script sends a log file containg the computername and the entry that has been replaced to a central share for audit/inspection

    Typically : "14/06/2013 15:49:52 [Fix] Restoring Xerox GPD PCL6 V2.2 Dependent Files Registry Value"

    In my organisation just over 900 W7 client devices have healed themselves in this way.

    Interestingly NONE of them have healed twice! 

     

    kb/2864755 acknowledges the issue and suggests that Microsoft is currently investigating.

    Monday, July 15, 2013 11:31 PM
  • And this awesome script is............

    You can't just tell us about this awesome thing where I don't even have to hear about these print tickets anymore and not share!!!

    Monday, July 15, 2013 11:36 PM
  • Hi Alan,

    I've posted an alternative workaround below but am not seeing any progress from Microsoft.

    Since Xerox HP and Toshiba global drivers reg entries are being nullified, this must be affecting a very large number of corporates worldwide.

    Is it not possible to look at the code for the Spooler service and check for any interaction with the registry? 

    Surely this would limit the number of lines that require inspection.

    Monday, July 15, 2013 11:41 PM
  • I'm sure that's how the support group is attempting to track this down.  Placing instrumentation around the code that could be getting to this point. 

    It's nothing we have experienced with Microsoft OS deployments and we deploy the client and server OS releases generally more rapidly than most companies. 

    I'm personally interested but busy with the next OS release and will let the support group track down the cause.


    Alan Morris Windows Printing Team

    Tuesday, July 16, 2013 7:16 PM
    Answerer
  • We seem to have resolved this through a fairly simple change.  We moved the system deployed printers to user deployed instead and the issue seemed to resolve itself.  Continuing to monitor but it seems to have made a pretty big difference.

    Eric

    Tuesday, July 16, 2013 7:23 PM
  • Eric,

    That's good for your organization. We have a need for computer policy based printer connections, so need the fix. We opened a case with Microsoft premiere support, and they gave us a trace which we are having difficulty getting results back due to intermittent nature of the problem.

    George

    Tuesday, July 16, 2013 7:48 PM
  • GetPeter,

    We are also interested in your script. Can you post it to this forum?

    George

    Tuesday, July 16, 2013 7:49 PM
  • Based on Nathan Warren and Trevor McClanahan's script above .
    There is a slicker way to work around this nullified reg problem as the driver files are all present and are not corrupt. It is only the registry that requires attention/repair.

    In my organisation we have created a script which backs up ALL Dependent Files  entries (with content!) in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3

    with a new string value called Dependent Files Backup.

    The script scans the registry every couple of seconds and triggers on the two values Not matching. In the event of a mismatch, it replace the contents of Dependent files with the Dependent files Backup (rename) and then stop/starts the spooler. The users are unaware that a fault has ocurred.

    The script sends a log file containg the computername and the entry that has been replaced to a central share for audit/inspection

    Typically : "14/06/2013 15:49:52 [Fix] Restoring Xerox GPD PCL6 V2.2 Dependent Files Registry Value"

    In my organisation just over 900 W7 client devices have healed themselves in this way.

    Interestingly NONE of them have healed twice! 

     

    kb/2864755 acknowledges the issue and suggests that Microsoft is currently investigating.

    GetPeter,

    any chance you can share the script?

    Thanks

    Wednesday, July 17, 2013 1:18 PM
  • 5cript3d,

    Thanks for your script. I am going to see if this work on my environment.

    Would it be fair to assume this will only work for x64 clients? I am under the impression that with x86 drivers, since the reg key is located under Windows NT x86.

    Thanks

    Wednesday, July 17, 2013 1:22 PM
  • If you simply change the line:

    Const StartKey = "SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3"

    To

    Const StartKey    = "SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3"

    It will work for 32 bit. We work with x64 everywhere here.  GetPeter better come through. I tried something similar when going through the troubleshooting and simply replacing the dependent files on a computer wasn't enough to bring printing back to life. It could be different in a x86 environment like GetPeter is in.  I will have to test it again here.


    • Edited by 5cript3d Friday, July 26, 2013 3:37 PM corrected 32bit reg path
    Wednesday, July 17, 2013 2:18 PM
  • Thanks,

    I will attempt the change see if its enough. try to put bot scripts together.. also a print spooler restart might be required, which I am aware your script does it. Will give it a try.

    I am aware of Alan Morris post, where states MS is aware and working on the issue, but I wonder if there is a reference number for this specific issue, where we can track status, or should this be logged via a premium request?

    Cheers


    • Edited by Larbac Wednesday, July 17, 2013 3:23 PM Clarificatin on my comments
    Wednesday, July 17, 2013 3:22 PM
  • Hi all,

    Is there a link to this script somewhere?

    Thank you.

    Tuesday, July 23, 2013 7:00 AM
  • Mr. Tpri,

    5cript has posted his above on Wednesday, June 12, 2013 3:04 PM.

    GetPeter did not post his.

    Tuesday, July 23, 2013 12:43 PM
  • I just wanted to confirm that replacing the dependent files missing and restarting the print spooler doesn't work on x64 drivers. Even tried restarting the computer after replacing them. The only thing that I can get to work is actually reinstalling the printer driver.
    Friday, July 26, 2013 3:35 PM
  • The three keys that get wiped are:

    [HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\DriverName]
    "DependentFiles" (REG_MULTI)
    "Monitor" (REG_SZ)
    "Help File" (REG_SZ)

    In my experience restoring the key from a saved .reg file from a known good system (via REGEDIT /S) and then cycling the SPOOLER service seems to resolve the issue temporaily.

    Interestingly, I've seen two related issues regarding these keys getting wiped:

    1. Users not able to print at all (using HP UPD)
    2. User's print jobs get printed all on one page - i.e. multi-page ducments are overlayed onto one sheet(!)
    • Edited by JonnyT1978 Tuesday, July 30, 2013 12:39 PM adding italics
    Tuesday, July 30, 2013 12:38 PM
  • I implemented a C# exe to perform what the script does, and put it in our machine startup scripts, since it has to run with admin privileges.  Basically if the DependentFiles key is empty, it just delete the entire driver-level key and stops/starts the spooler service.   The driver will magically reinstall via Point and Print. 

    Note that there are are a few printer drivers that "natively" have an empty dependent file list in the registry.  If you install the Win7-built-in "Journal Note Writer", it installs a virtual print driver similar to Microsoft XPS Document Writer driver.  The Journal Note Writer driver has an empty list, so I think we might've broken the one user who actually installed this.  The KIP 3000 large-scale printer also has blank DependentFiles list. So you all might want to be on the lookout for such drivers. 

    Finally, at our peak, about 35% of our 5000+ Win7 machines had at least one broken driver.   Sure hope a fix is coming soon. 

    • Proposed as answer by GetPeter Thursday, August 29, 2013 3:25 PM
    • Unproposed as answer by GetPeter Thursday, August 29, 2013 3:25 PM
    Thursday, August 22, 2013 5:06 PM
  • Hi all and sorry for the delay in responding,

    I now have a compiled standalone exe that should fix the problem for all that have posted here.

    As in my description in my earlier posts, the exe performs the following tasks when run as an admin:

    This code has fixed all GPD problems in my organisation whilst I still await a Microsoft fix (see my premier support report kb/2864755.) 

    1. Creates a backup of any Dependent Files entry ignoring any blank entries as some devices are natively blank.

    2. Checks every cycle to see if the Dependent Files regkey has been nullified and triggers the repair.

    3. When triggered the Dependent Fliles Backup is used to replace the nullified entry and the Spooler Service cycled.

    4 A local log is created in the folder where the exe has been run from.

    A GPDAutoFix.ini  file is not mandatory but will add following additional functionality if required.

    [GPPAutoFix]
    ; Time In seconds between check
    CycleTime=5

    ; Enable or Disable Local Logging (Enabled or Disabled)
    Logging=Enabled

    ; Network Logging Path to centralise any repair logs by computername

    ;(ensure the executing account has write permissions!)
    NetworkLogPath=\\Servername\Sharename\Foldername (Blank or not present =  No Logging)

    ; Print Driver Registry keys to check. An additional OS can be added,

    ;the default will be based on the OS that is running (this example covers x86 and x64)
    PrintDriverKeys=Windows NT x86,Windows x64

    ; Remember the exe ignores entries that are already nullified since some are by design so .

    ;This entry is used when clients are known to already have a nullified entry and need to be deleted.
    :The named hive and its subkeys will be completely removed and the spooler cycled.
    ;This will cause the OS to recreate the correct Dependent files entry and the backup process to function.
    AutoRemoveDrivers=Xerox GPD PCL6 V2.2,Microsoft XPS Document Writer.

    I can't attach here so I'll send the exe and ini to anyone who wants it. Write to me at getpeter101 which is at hotmail dot com

    Thursday, August 29, 2013 4:30 PM
  • Script now available as an exe with additional functionality . This has now been applied to 20,000 devices in my organisation and fixed them all!
    Friday, August 30, 2013 8:44 AM
  • There is forward motion within Microsoft to solve this problem. Some weeks ago we opened a case and they took it as a software bug in the spooler. There are several other customers with similar open cases. Initially Microsoft provided a debugging hotfix in an effort to capture the symptoms. We did not capture the symptoms, but other customers must have. A couple of weeks later Microsoft then provided a private hotfix which is "alpha" or "beta" code that they believe addresses this issue. If you open a case with Microsoft you can get the private hotfix. It has not gone through regression testing and is therefore not available as a public hotfix yet. I am told that is at least 3 weeks away. Although I have the hotfix, the EULA prevents me from distributing it.

    Our testing of the private hotfix was limited, but we did report success to Microsoft.

    Most client computers which have this symptom (perhaps half of our clients?) have the symptom only once. We have developed a simple fix that our help desk has become very adept at using to fix printing issues when end-users report it. In our case we see the symptoms (unable to print or prints symbols and empties paper tray) only on the HP universal print driver. We also use the Ricoh universal driver, but have not seen this symptom on Ricoh printers. The registry key HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 6 (v5.x.x)\ is damaged by the local Windows print spooler service.

    Our help desk identified a use case that continuously had the symptom on two computers. A third computer was selected as a control. The control computer had no new problems. The two computers with problems now seem stable and is no longer having printing issues. We are now awaiting the private hotfix to go through QA and be released to public by Microsoft.

    I meant to add that this KB articles are related to this issue:

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

    • Edited by George Perkins Thursday, September 26, 2013 3:37 PM added KB link
    Thursday, September 26, 2013 3:27 PM
  • Thank you George,

    these are great news.

    Thursday, September 26, 2013 3:45 PM
  • George thanks for posting the information you have.  I can't / shouldn't comment on the issue until a fix is publically available.  Thanks for participating in validating private binaries.

    Alan Morris Windows Printing Team

    Friday, September 27, 2013 5:35 PM
    Answerer
  • Alan/George, we've just started experiencing this issue.  We have 80 users and about 10-15 (so far) of them have run into this problem at various times over the past week.

    Today we placed a support ticket with Microsoft and referenced the KB article (http://support.microsoft.com/kb/2864755) and this forum post.  Once we got to talk to a technician we were basically told that if we have a work around, then there's not much that can be done. BTW, our workaround has been to stop the print spooler on the user's computer, delete the HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 6 (v5.x.x)\ registry key, and then restart the print spooler. 

    So right now we're in the process of working the ticket up the chain of command with the support people until we find somebody that can help us talk to a technician or engineer that has experience with this issue.  Do you guys happen to have a contact we could reach out to get our ticket in the hands of the team working on this problem?  Thanks.

    Thursday, October 17, 2013 10:26 PM
  • Tell the support person thanks.  The investigation is complete.  The customers that ran instrumented spooler binaries to track down the issue should have already obtained and validated the changes that have gone into a version of the fix which is not yet public. 

    Since no more investigation is needed and a public fix has not been released, you will be on hold until the fix is made public.  I can't tell you when a fix is scheduled but hang tight and let the test and sign off process continue without interuption.

    I'm assuming your support person is already in contact with the group that has tracked down the problem.  If not, give them my name.  I can redirect so that your ticket is can be placed with others waiting for final sign off.  I'm actually on vacation and will not have email until next Monday night so if you give them my name it will be a few days.


    Alan Morris Windows Printing Team

    Friday, October 18, 2013 7:23 AM
    Answerer
  • Sounds like Alan's response is the way to go. But if you want the names and contact info for the specific support personnel at Microsoft we worked with, send me a private e-mail and I can reply with that contact information. My e-mail is gperkins (at) meriter (dot) com. (I have no idea of the urgency of your problem; maybe you can talk Microsoft into sending you the private fix we tested. The work-around to script a cleanup of the registry is in this thread above and that seems to work fairly well, although it does require help desk support staff intervention.)

    George Perkins

    Friday, October 18, 2013 4:07 PM
  • Thanks Alan.  I just emailed the support person we've been working with and gave him your name.  I'll check in with them and on here again next week. 
    Friday, October 18, 2013 5:40 PM
  • They will not and really should not send you a private binary until it is released since a private would be a different version and you would need to go through the install process again with the public version (sorry George-- and thanks once again for validating the fix).

    I did not get any mail today but like I said I am on vacation ---  why am I responding to this.  I guess I'm just dumb or care the print server community too much.

    Have a great weekend all.  When the fix is public, I'm sure a pointer to the KB will circulate quickly.


    Alan Morris Windows Printing Team

    Saturday, October 19, 2013 1:00 AM
    Answerer
  • Just curious....is this pending hotfix for Windows 7 clients, or for the back-end Win2008 R2 print servers? 
    Tuesday, October 22, 2013 6:27 PM
  • The fix will be a client side only for Windows 7 SP1.

    John Dickson Senior Support Escalation Engineer Microsoft Platforms Core Team

    Tuesday, October 22, 2013 6:29 PM
  • Has anyone seen a public release fix for this issue?  I have a customer who needs the fix and I hate to point them to MS for the private bits.

    Thanks!

    Cody

    Monday, November 04, 2013 10:01 PM
  • I not received any notification from Microsoft.
    Monday, November 04, 2013 10:20 PM
  • The fix is not yet public.  Hang in there. 

    Alan Morris Windows Printing Team

    Tuesday, November 05, 2013 2:33 AM
    Answerer
  • Another question to those who have tested this fix:  upon installation, does this hotfix fix a currently-broken machine, or does it only prevent non-broken machines from getting broken in the future? 
    Tuesday, November 05, 2013 5:26 PM
  • A broken machine will need to be fixed first. Uninstalling and re-installing the universal print driver should do this, or the scripted solution provided above in this thread also works.

    My supposition is that the patch prevents the spooler from wiping out the registry. It does not know the registry contents are corrupted and wouldn't know which values to rebuild. This seems reasonable given there could potentially be different UPD versions (different values) or possibly other printer hardware: non-HP, with different keys and values.


    Edit 12/2/2013: The above is NOT the answer to this particular forum's original question.
    Tuesday, November 05, 2013 5:41 PM
  • Any update on the availability of this patch?
    Friday, November 08, 2013 6:16 PM
  • Hi there,

    First, thank you a lot for all those details provided. It really help me to understand the problem we are actually facing in our environnement.

    One point that seems not really clear for me is the reason of this problem. When you say"It looks like the real issue is when you redirect a print server Microsoft's spooler.exe service breaks whatever driver is installed.", what do you really mean about "redirect a print server" ? Does it mean that this problem happens when you have clustered print servers ?

    It's quite important for me to understand what causes this issue. Do you think that virtual clustering can cause thos kind of issue ?

    Thanks in advance.

    Christopher

    Wednesday, November 13, 2013 3:59 PM
  • We do not have clustered print servers, and we definitely have this problem.   My impression is that this is strictly a Windows 7 issue, since it is a Windows 7 patch forthcoming.   (maybe Windows 8 too?).  

    Friday, November 15, 2013 5:56 PM
  • Ah crud, the article does not contain the download information. 

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

    Print drivers on Windows 7 clients missing dependent files

    Okay another QFE was published that contains the fix for dependent files and an issue when adding connections during logon to TS servers.

    http://support.microsoft.com/kb/2896881/en-us

    Long logon time when you use the AddPrinterConnection VBScript command to map printers for users during logon process in Windows Server 2008 R2 SP1


    Alan Morris Windows Printing Team




    Friday, November 15, 2013 5:57 PM
    Answerer
  • Alan, I assume this hotfix also works on Windows 7 SP1 even though it says Windows Server 2008 R2 SP1?
    Monday, November 18, 2013 7:45 PM
  • That's just a document title.  This is a client side fix.  The other is also a client side fix but it pertains to Terminal Server environments.  The binary that is important is win32spl.dll.

    Select Product Language Platform Fix name Release Version Build File size (bytes) Modified date
    Windows 7/Windows Server2008 R2 SP1 All (Global) x86 Fix463083 sp2 SP1 7600 833432 11/5/2013 5:31:03 PM
    Windows 7/Windows Server2008 R2 SP1 All (Global) x64 Fix463083

    Alan Morris Windows Printing Team



    Tuesday, November 19, 2013 8:33 AM
    Answerer
  • Hi Alan,

    Can you please confirm that the hotfix (http://support.microsoft.com/kb/2896881/en-us) should fix the issue where Windows 7 clients print a high volume of pages with individual lines of garbage?

    The fix that I have been applying currently is as follows:

    Delete HKLM->SYSTEM->CurrentControlSet->Control->Print->Environments->Windows x64->Drivers->Version-3->HP Universal....

    Restart Print Spooler

    Please advise.

    Thanks,

    Tom

    Tuesday, November 19, 2013 9:36 PM
  • That's just a document title.  This is a client side fix.  The other is also a client side fix but it pertains to Terminal Server environments.  The binary that is important is win32spl.dll.

    Select Product Language Platform Fix name Release Version Build File size (bytes) Modified date
    Windows 7/Windows Server2008 R2 SP1 All (Global) x86 Fix463083 sp2 SP1 7600 833432 11/5/2013 5:31:03 PM
    Windows 7/Windows Server2008 R2 SP1 All (Global) x64 Fix463083

    Alan Morris Windows Printing Team



    Does it mean the hotfix on http://support.microsoft.com/kb/2896881 will solve the printer driver registry error on this forum?  We don't use Terminal services, just a regular print server with bunch of printers/clients having the same issue. What exactly is the hotfix we should apply?
    Tuesday, November 19, 2013 10:21 PM
  • I would like to second this.  Has anyone applied the client side fix from http://support.microsoft.com/kb/2896881/en-us to address all of these issues with success?

    This affects our internationals folks connecting to our new Server 2008 R2 print server where their 64-bit Win7 clients cannot see the advanced printing properties from our Xerox & Toshiba printers due to these blank fields in the registry.

    They are getting newer Toshiba printers that ONLY have a UPD offered, so this will become a bigger proplem.

    Thanks,

    Thursday, November 21, 2013 6:48 PM
  • The article at http://support.microsoft.com/kb/2864755 has been updated.  I think next month they will actually link the download to the article.

    Resolution

    To repair the printer, remove and reconnect the network printer that is using the problem driver.

    To prevent the issue from occurring, apply the hotfix for KB 2896881 - 

    http://support.microsoft.com/kb/2896881
          (http://support.microsoft.com/kb/2896881)    


    "Long logon time when you use the AddPrinterConnection VBScript command to map printers for users during logon process in Windows Server 2008 R2 SP1"

    Alan Morris Windows Printing Team

    Friday, November 22, 2013 1:26 AM
    Answerer
  • The article at http://support.microsoft.com/kb/2864755 has been updated.  I think next month they will actually link the download to the article.

    Resolution

    To repair the printer, remove and reconnect the network printer that is using the problem driver.

    To prevent the issue from occurring, apply the hotfix for KB 2896881 - 

    http://support.microsoft.com/kb/2896881
          (http://support.microsoft.com/kb/2896881)    


    "Long logon time when you use the AddPrinterConnection VBScript command to map printers for users during logon process in Windows Server 2008 R2 SP1"

    Alan Morris Windows Printing Team

    Friday, November 22, 2013 1:26 AM
    Answerer
  • One other note.  The Print Spooler service and components are EXACTLY the same on the client version as what you have on your print servers.  In TS server cases the server IS the client.  PS you can also share printers from the client where the client machine IS the server. 


    Alan Morris Windows Printing Team

    Friday, November 22, 2013 1:30 AM
    Answerer
  • We have been having the SPLWOW64.EXE error for over a year in our environment.  The usual notation is that a file such as x2utilGH.dll is not present on the machine (when in fact it is where it should be in the c:\Windows\System32\spool\drivers\x64\3 folder).  We are a primarily XEROX MFP environment with HP LaserJet models for black and white small jobs.  Although it is very rare we have had this affect the HP LJPs.  During that time we have created scripts that implemented many suggestions from many links across the internet.  We have taken suggestions from Xerox and feedback from Microsoft.  For the most part we developed a series of actions.

    1) Remove all print queues using a VBScript (to release any connections to the installed drivers).

    Set WshNetwork = WScript.CreateObject("WScript.Network")
    Set oPrinters = WshNetwork.EnumPrinterConnections

    'WScript.Echo "Network printer mappings:"

    For i = 0 to oPrinters.Count - 1 Step 2
     'WScript.Echo (i/2)+1 & " - Port " & oPrinters.Item(i) & " = " & oPrinters.Item(i+1)

     PrinterPath = oPrinters.Item(i+1)
     if left(PrinterPath,2)="\\" then
      WshNetwork.RemovePrinterConnection PrinterPath, true, true
     end if
    Next

    2) Delete all old (unprinted) queued jobs
    del c:\windows\system32\spool\printers\*.shd
    del c:\windows\system32\spool\printers\*.spl
    del c:\windows\system32\spool\printers\*.tmp

    3) Delete all Registry References for all drivers using a compiled .exe that implements a series of actions for each driver installed such as this.

    WshShell.RegDelete ("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows
    x64\Drivers\Version-3\Xerox ColorQube 9303 PCL6")

    4) Stop the spool service.

    CMD /C net stop "Print Spooler"

    5) Stop any connection to the Printer Isolation Host.

    tskill PrintIsolationHost.exe

    6) Implement a series of deletion routines specific to the DEPENDENT FILES used by the drivers from the c:\Windows\System32\spool\drivers\x64\3 folder.  This was suggested by Xerox to "REMOVE OLD FILES".  While that did not seem to be the issue from other information we found including what has been posted on this link.

    7) Present the Print Server Properties applet for Windows 7

    PRINTUI /S /T2    - to allow the selection and deletion of any drivers that for some reason might have survived the previous steps.

    8) Remap all printers for a given work area / work floor using a custom script.  Part of the script runs through the printers to be installed and compares it to the already installed printers.  If a printer is already install then it is not addrf so if they are all installed then no ADD actions are ever carried out.

    We were provided the recently released http://support.microsoft.com/kb/2896881 Hotfix prior to public release and have for good measure downloaded the Public release version (which by the way is one where you provide Microsoft an e-mail address for them to track who is using the fix - this is a good thing).

    9) Apply the Hotfix provided via the recently released http://support.microsoft.com/kb/2896881 link.
    (This must be done with Admin Rights).

    10) Reboot the computer.

    Total process time of steps 1-8 is usually 3-5 minutes after connecting into the employee's computer as a Service Desk team member that has Admin privileges.  Since all drivers in our method are actually removed down to the actual files some of this time is the re-mapping of the printers and pulling the drivers.

    Then it becomes a wait and see as to if and when it affects a computer again.  Since we are a company of 4,000 employees in our city and our Service Desk receives on average 18-20 calls a day, everyday, of every week we need a final fix for this issue.

    Like many others on these postings the issue is on Windows 7 64-bit computers while using a Windows 2008 R2 print server.  We have switched print queues to use the WinPrint Print Processor (for our Xerox MFP devices) away from the XeroxV5Print.  We do Client Side Rendering / Start printing after last page is spooled / have only 64-bit drivers since it is a Windows 7 client printer server after retiring our XP systems.  The affected employees are random in that it can not be determined by location / by specific printing device (although MFPs are usually what are affected) / or type of employee by their job role.  We have noticed maybe by coincidence that after our monthly Windows Updates are applied we have employees affected that never had the issue before.

    We unfortunately have had employees call our Service Desk just one day after applying the above process (including the MS Hotfix) with the same issue.  We have verified that the DEPENDENT FILES field for the print driver (in our case Xerox MFP drivers) are blank.  The actual export of the registry key shows not truly a blank value but the following: "Dependent Files"=hex(7):00,00,00,00 .  When looking at the registry value in RegEdit it shows the cursor flashing one line down from the top of the dialog text box.

    The latest registry export was taken when an employee had been prompted to reboot the computer after monthly Windows Updates were applied by WSUS.  The employee had been printing just fine but after the reboot received the SPLWOW64.EXE error as a result of the Dependent Files field being blank when going into print a document.  The drivers affected are used for this computer involved a Xerox 9203 and a Xerox 5655 (both are the PCL 6 type).  Based on the way we map printers the printers are not mapped on laptops while they are on Wifi since we determine employee's locations by floor sub-net.  So the assertion that the AddPrinterConnection action is at fault might be valid as we use it in our mapping scripts, but that did not apply in this specific instance.  Usually a person is fine and no real actions have to happen (no reboot / no re-login) and then a person all of a sudden has the Error occur.

    We have been able to FIX the problem with the above actions but it is not a permanent fix. The MS Hotfix does not seem to have solved the problem in its current version.  The DEPENDENT FILES value is still being cleared of the expected file names that should be present for the driver registry keys.

    We have created a QUICK SCRIPT that simply deals ONLY with the values in the DEPENDENT FILES keys by populating them with a .REG import action and then doing a STOP/START of the Printer Spooler. We run this as an .EXE that has admin rights. This takes less then 30 seconds and does not require switching to a Service Desk Team Members login to perform the actions but it is also nothing more that a work around the problem.

    I hope this information helps others reading these postings and might also help us all in finding a final solution.


    Saturday, November 23, 2013 3:00 AM
  • I think Microsoft has released a fix on November 15... but I am unsure of its applicability. See http://support.microsoft.com/kb/2864755 which describes the cause (if not the effect entirely) in Windows 7 (client OS). The KB 2864755 points to a resolution http://support.microsoft.com/kb/2896881 although the hotfix description in KB 2896881 is a resolution only for Windows Server 2008 R2 SP1 in Terminal Services mode (not Windows 7)!!

    It seems like Microsoft has dropped the ball on this one. We also need a similar hotfix for Windows 7.

    I am cross-posting this information at http://social.technet.microsoft.com/Forums/windowsserver/en-US/08bc6b4b-0190-40b0-be16-8b82249148e4/print-driver-being-modifyied?forum=winserverprint

    Alan Morris, do you have insight into what is going on? I don't consider this forum topic answered unless we have a hotfix for Windows 7. Please unmark my "answer" above so it is not "answered". Thanks.

    Monday, December 02, 2013 4:30 PM
  • I have provided website feedback on both KB 2864755 and 2896881 indicating the problematic linkage between the KB 2864755 Windows 7 issue and the proposed "solution" in KB 2896881.

    We need a solution to KB 2864755 that applies to Windows 7 (not Windows Server 2008 R2).

    Thank you.

    Monday, December 02, 2013 4:44 PM
  • To quote  http://support.microsoft.com/kb/2864755 Resolution Section:

    "Long logon time when you use the AddPrinterConnection VBScript command to map printers for users during logon process in Windows Server 2008 R2 SP1".

    There may indeed be an issue with "Long Logon Times" and it may also affect when using "AddPrinterConnection VBScript command to map printers". 

    But that does not explain the times when mappings are not happening.  Long Logon Times might happen when "Windows / Microsoft updates are being applied".  Long Logon times might happen when connecting to new printers and pulling drivers.  However, our networks in general are GigaBit networks and this "Dependent Files" key can some how / some way get cleared over lunch. 

    I can not go with the fix related to when a script is running to map a printer causing this as I stated in my detail write-up above.  We do not map printers while an employee is on Wi-Fi because we do not know where the employee is located to know which printers we should map to the computer.  There has to be another solution.  This issue is not just written about in this forum.  You can BING all over the internet for issues with HP / Xerox / etc Global Print Drivers and so on using PCL / PS / etc.

    As a random example that happens to be for a different model of MFP from back in early 2012 you can see this is not a new issue: http://www.networksteve.com/windows/topic.php/Reg_values_for_a_local_driver_are_lost_every_2-3_days/?TopicId=50798&Posts=2

    That link is a CLOSED / ARCHIVED link - but again it shows this is an issue that for us has not been addressed.

    Monday, December 02, 2013 7:30 PM
  • I bumped this up to Microsoft Premier support (we had a case opened with them) and got this response:

    >>>>

    I just confirmed internally and this is the KB 2896881 which will fix the dependent files issue. Please note, we include multiple fixes in a KB and provide it as a single download. Hence you do not see the specific issue being mentioned in the KB heading or the Symptoms section.

    We are working internally in getting the ‘Applies To’ section updated to reflect Windows 7.

    I confirm that in both the cases KB2896881 is applicable for Windows 7 which will fix the Dependent files issue also.

    <<<<

    We are reviewing internally our testing and deployment tactics for KB 2864755.

    George

    P.S. Moderator: I suggest keeping this thread "unanswered" until someone posts their findings on the success of KB 2864755 in their environment. Thanks.

    Monday, December 09, 2013 9:44 PM
  • Alan,

    Somehow this forum thread got forked and there appear to be two discussion "conversations" (at least in the view I see). Can you mark this question as "unanswered" (see the other conversation). Thank you.

    George

    Monday, December 09, 2013 9:48 PM
  • Sure.  There are a bunch of questions here that have been answered.  It's just the title question that remains IN question.

    Alan Morris Windows Printing Team

    Tuesday, December 10, 2013 9:03 AM
    Answerer
  • have any of you had any luck confirming that the proposed fix has worked?

    we have installed it on our site but we are still reciving calls about this problem.

    Monday, January 13, 2014 1:14 PM
  • It would apper that it does not Work for us as we still have calls concerning this error even though we have deployed the hotfix.

    We have checked the computers and they have all had the hotfixed installed before the error ocurred.

    Monday, January 20, 2014 12:59 PM
  • We had the same problem whit Toshiba Universal 2 Driver. We updated  some schools with new printers and drivers and on some schools the problem occurred. A workaround was to empty the driver folder on the client and add the printer again.

    After further investigation we made the following solution

    Reg Replace GPO:

    We created a Computer gpo that replaces Depending Files and Help entry's in the registry location, whit the right vallues

    SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\TOSHIBA Universal Printer 2

    so at each reboot it will put in the right values. (this could work on any driver if you ask me)

    Hotfix:

    we also aplied the hotfix:http://support.microsoft.com/kb/2896881 to our win 7 clients (yes i know it says 2008, but it works)

    we applied it whit a start up script in gpo:

    scriptname:  wusa.exe
    script parameter: \\DOMAIN.LOCAL\SysVol\DOMAIN.LOCAL\Policies\{7D0D7C0A-2482-4634-9733-29A399730A96}\Machine\Scripts\Startup\Windows6.1-KB2896881-v2-x64.msu /quiet /norestart

    extract the hoffix.exe to: \\DOMAIN.LOCAL\SysVol\DOMAIN.LOCAL\Policies\{7D0D7C0A-2482-4634-9733-29A399730A96}\Machine\Scripts\Startup\

    not sure if you have to do both (hotfix and Reg Replace GPO), but to be sure we did both.

    grtz Robin

    Thursday, January 23, 2014 11:31 AM
  • I got a phone call from Microsoft Development after asking our Microsoft Premier Agreement Technical Account Manager to escalate. They believe everything is in order and we should apply the hotfix in KB 2896881.

    The symptom we have is documented in KB 2864755. It indicates Windows 7. That KB redirects to 2896881.

    1. Although 2896881 isn’t our symptom, because 2864755 redirects us, we should accept 2896881 as our solution. The updated DLLs are shared by Windows Server 2008 R2 and Windows 7; therefore as 2864755 indicates, 2896881 is applicable to the workstation OS symptoms we have observed.

    We believe the hotfix is stable, and will apply it to the server OS as well. Some servers do printing and may benefit.

    Friday, January 24, 2014 5:36 PM
  • The hotfix for 2896881 does not resolve this problem. We have deployed the hotfix enterprise-wide (3,000 computers) and are still getting intermmittent symptoms. I have opened a new case with Microsoft.

    Please unmark this question as answered; it is not answered yet.

    Wednesday, March 12, 2014 5:29 PM
  • Done.   I'll assume you are not using Package Aware print drivers.

    Alan Morris Windows Printing Team

    Wednesday, March 12, 2014 6:35 PM
    Answerer
  • We have deployed HP's Universal Print Driver 5.5.0 and 5.6.1 both with the same intermittent symptom and 2896881 did not fix the problem. I really don't know what a "Package Aware" print driver is or if HP's UPD is one.

    We opened a Premiere case with Microsoft Support and have learned that Microsoft is unable to reproduce the issue in-house and that several other clients like us are continuing to experience the intermittent symptom and also have open support cases. We are deploying a diagnostic version of 2896881 supplied by software development which Microsoft hopes will capture symptom data and allow them to figure out what is going on.

    Tuesday, March 25, 2014 6:22 PM
  • We have deployed HP's Universal Print Driver 5.5.0 and 5.6.1 both with the same intermittent symptom and 2896881 did not fix the problem. I really don't know what a "Package Aware" print driver is or if HP's UPD is one.

    Per http://msdn.microsoft.com/en-us/library/windows/hardware/ff559698%28v=vs.85%29.aspx  and looking at the contents of HP UPD 5.6 (hpcu140u.inf), one does see:

    [PrinterPackageInstallation.amd64]
    PackageAware=TRUE
    http://technet.microsoft.com/en-us/library/jj590748.aspx has more details part way down on what package aware entails.

    Tuesday, March 25, 2014 6:34 PM
  • George:

    Thanks for the update and your continued persistence.  You are in the right hands.  I'm curious what the heck is happening with the clients. 


    Alan Morris Windows Printing Team

    Tuesday, March 25, 2014 6:53 PM
    Answerer
  •  We are seeing the same thing here in an educational setting with 1800 computers running 64 bit Win 7 SP1.  The Print Servers are 2008 R2.  We run Xerox and HP printers.  People will be in the middle of printing a document and mid printing the printer starts spitting out garbage.  Every occurrence has had the Dependent Files value wiped out in the registry.  Stopping the spooler, re-populating this value and restarting the spooler fixes the issue.  While replacing this value via GPO can help the issue it doesn't prevent the problem from occurring since it often happens mid print job and won't be corrected until the GPO refresh.

      We are piloting 2896881 but have already seen one instance where the same problem had again happened.  Please keep this thread updated with any progress.

      Thanks.

    Monday, April 07, 2014 1:10 PM
  • Hi, we are also still experiencing this problem after applying hotfix KB2896881 to all Win7 x86/x64 machines. The dependent files registry is empty on machines experiencing the issue. We use HP UPD PCL 5/6 print drivers.

    George, have you had any update from Microsoft since your last post?

    Thursday, April 10, 2014 12:42 AM
  • Hi,

    unlikely we are also expiriencing this kind of Print Problems. We running Win 7 Sp1 (64 Bit) and two W2K8R2 Print Servers divided in Lexmark and Samsung Printers with Universal drivers and dedicated Print drivers. In February we applied the Hotfix on all clients as Microsoft told us. Since then we had few Print Incidents per day until today. As we reopened the Call at Microsoft, they told us, that there is a regression of the bug. So, we are still waiting for a new fix from Microsoft.
    If there are any news from Microsoft, I'll keep you informed - otherwise I would be pleased to hear news from you here.
    Tuesday, April 15, 2014 8:26 AM
  • Hi there, we have implemented the new fix from Microsoft to all machines and will wait and see if this is the resolution.

    Fix is to add these two registry settings to Windows 7 workstations

    HKLM\System\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers


    LoadTrustedDrivers(REG_DWORD) = 1
    TrustedDriverPath(REG_SZ) = no value

    Wednesday, April 16, 2014 11:31 PM
  • Confirming, 2896881 does NOT fix the problem (we deployed 2896881 enterprise wide, still have issues).

    We deployed a diagnostic version of the hotfix designed to capture symptoms for Microsoft. Unfortunately, deployment is extremely difficult because it modifies the boot configuration descriptor which invalidates the BitLocker encryption signature.  So we deployed on a couple of non-encrypted systems only. The problem is so intermittent for us (we have 10-20 reports per month on 2500 computers) that in the month, the 4 computers with the diagnostic fix haven't had the problem.

    In the mean time Microsoft asked us to deploy a registry change to disable non-packaged driver support across our enterprise - they think the logic containing the bug is taking the non-packaged fork even when the driver is packaged - but we've had some staff resignations and are operating very lean right now in the desktop support area and have declined taking on this additonal work on top of finishing off the last stubborn 5% of WinXP conversions.

    Sorry for the delay in posting, I thought I had this thread subscribed, but I got no notification from the forum of the recent updates. I'll try re-subscribing.

    Friday, April 25, 2014 2:38 PM
  • This is the same registry change Microsoft asked us to test. We were unable to test because of staffing limitations and project workloads. Very interested to hear of your success/not if this works.
    Friday, April 25, 2014 2:41 PM
  • Hi Everyone,

    I work on the team at Microsoft that is aware of the Dependent Files issue with Windows 7 clients.

    Need to update the registry key information as the post from Carlitog is incorrect.

    What we have discovered what is causing the Dependent Files issue is that the Windows 7 Client is being told to change to Legacy Point and Print (think Server 2003) instead of Server 2008 R2 that uses Package Aware print drivers.

    We want to test the following by configuring the clients to only work with Package Aware type Print servers

    so if you have any 2003 Print Servers, this would cause a connection failure when installing/updating print drivers.

    Action Plan:

    1. On the Windows  7 client, create the following registry keys below

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print

    Services\Servers

    Values:

    LoadTrustedDrivers(REG_DWORD) – This should be set to 1.

    TrustedDriverPath(REG_SZ) – This should be set to (“”)

    This is the file path that will be searched for the driver. Set this value to a NULL string of  (“”)

    Type beginning parenthesis then two double-quotes then ending parenthesis.

    2. Reboot machine and test

    3. Install 2896881 which contains another fix for Dependent Files issue

    Please post back if this resolves your issue

    Thanks,

    John Dickson

    Microsoft Windows Core Performance Support Team


    John Dickson Senior Support Escalation Engineer Microsoft Platforms Core Team


    Friday, April 25, 2014 4:17 PM
  • I put the above 2 registry changes in play on Wed to 1800 computers via GPO and so far have not seen the issue.  However we are between semesters so the users/amount of printing is fairly light right now.  Will keep you posted if I see the issue re-appear.
    Friday, April 25, 2014 7:20 PM
  • I entered the two registry entries, applied kb2896881, rebooted and so far the issue appears to be RESOLVED.
    Monday, April 28, 2014 1:16 PM
  • I have never had the missing dependent file issue but have all the other symptoms. If I apply these 2 new regkeys to my environment can they possibly help.
    Monday, April 28, 2014 6:39 PM
    • Hello all,

      We have 2 different domains with their own printer servers. All are running Server2008R2x64 and here is what we are seeing:

      All the machines have the same base image being Win7x64 Enterprise. We have approx. 600 computers total

      One domain is called ABC had the Print server initially with HP Universal Drivers 5.4 PCL that were upgrade to 5.5 PCL
      This domain suffer from the random unable to print Event 372 issue with  the the error of 5 Access Denied. Were get random calls about the inability to print and most of the calls tend to be on a Monday.

      The other Domain is called DEF has 3 Print Servers. Two of the Print severs are in the USA and one is in LDN. The two PS in the states originally were configured with HP universal Drivers 5.4 PCL and both were upgraded to 5.5 We get calls from users of these 2 print servers ever single day. Aproxximately 5 a day complaining that they cant print.

      Built a brand new SVR2008r2x64 server with only HP universal 5.7 PCL and added only 20 machines of known people whose machines were having printing issues. We have purged out all the old drivers and their settings etc with the registry changes shown below. Even on a brand new PS with the HP 5.7 drivers added initially we see the same printing error  Event 372 Access Denied 5......

      The LDN PS that only the London users connect to for printing is still using 5.4 pcl and hasnt been upgrade. These users have NEVER had a client lose their ability to print. They are in good shape.

      We have  Lumension Sanctuary Device control on all our machines. I use to believe that this was the culprit in such a way that is was too restricted on the machines but if it was all the machines would suffer and not simply a random handful which is the case for us.

      This is the script we run on machine that are afflicted. Even doing this doesn't prevent the same machine from becoming a victim again. 

      FYI the last 2 lines of the regkey  are added as of today per the new thread so I can't confirm if the LOADTRUSTEDDRIVERS and TRUSTEDDRIVERPATH work or don't work for us. I will update as i get more info.

      pushd %~dp0
      ECHO OFF
      Echo You must run this as Local Administrator to allow write access to the registry
      pause
      regedit.exe /S "HPDriversCleanUp.reg"
      Echo The Registry has just been modifed.
      net stop spooler
      net start spooler
      Echo The Print Spooler has Sucessfully been stopped and restarted
      Echo Add back the necessary HP user's printers to the machine
      Echo You might need to restart the computer in order to finalize these changes
      Echo Hit any key to exit this CMD Window
      popd
      pause

      Below is the contents of the HPDriversCleanUp.reg key  Basically it cleans up the junk files and whatver we believe needs to be purged. A compliation of all the posts for the internet and their remedies.

      Windows Registry Editor Version 5.00
       [-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 5 (v5.5.0)] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 5 (v5.7.0)] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 6 (v5.4)] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 6 (v5.5.0)] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\HPMLM135] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\HPMLM121] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\HPPMOPJL] /f
       [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\HP Universal Print Monitor] /f
       [-HKEY_CURRENT_USER\Printers\Connections] /f
       [-HKEY_CURRENT_USER\Printers\Settings] /f
       [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers] /f
      "LoadTrustedDrivers"=dword:00000001
      "TrustedDriverPath"="(“”)"

      I know we aren't alone with this issue and it is a very serious problem in my organization that needs resolution. Hopefully my scenarios can shed new light on this. It been ongoing for over 8 months. Any suggestions are welcome. Thanks for reading.


    Monday, April 28, 2014 8:04 PM
  •   It has been a week since I added the two registry settings to all workstations via GPO and no corrupt printing so far.  (Combination of Dell,  HP and Xerox printers installed from Windows 2008 R2 load balanced print servers to Windows 7 SP1 x64 workstations).  Fingers crossed.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers]
    "LoadTrustedDrivers"=dword:00000001
    "TrustedDriverPath"=""

    Thursday, May 01, 2014 2:39 PM
  • Hi all, I just want to update that the registry entries I posted above are correct i.e. enter TrustedDriverPath as blank and not ("").

    I've had these registry settings re-confirmed  by Microsoft support.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers]
    "LoadTrustedDrivers"=dword:00000001
    "TrustedDriverPath"=""

    We haven't experienced the corrupt printing since implementing the fix, however the issue normally occurs when there is a driver change on our print server. We haven't added/updated a driver yet, so will wait until this occurs and no issues are encountered before confirmed the fix.

    Friday, May 02, 2014 1:40 AM
  • I have been implementing this change to the registry. Regardless of setting the "TrustedDriverPath"  to ""TrustedDriverPath"="" or"TrustedDriverPath"("")" I find myself running into a different issue. Because we use both HP and Canon printers once you add the "LoadTrustedDrivers"=dword:00000001 our users can no longer add any Canon printers. I get an error as shown. If I change the "LoadTrustedDrivers"=dword:00000001 back to "LoadTrustedDrivers"=dword:00000000  it works correctly

    is anyone else having this behavior?

    Monday, May 05, 2014 7:11 PM
  • I have been testing the suggested registry changes in our environment as well. The change disables the ability to add our Canon printers as well as several older Xerox drivers on our Windows 7 x64 devices. As you mentioned, removing the LoadTrustedDrivers key allows for the printers to add.

    I would assume that Microsoft is considering these drivers to be "untrusted" or "legacy".

    Wednesday, May 07, 2014 2:02 PM
  • It has been another week without an more printer issues since implementing the registry fix and users have been printing heavily since Friday.  We only use signed trusted drivers in our environment so have experienced no issues with deploying printers/drivers via GPO. (Dell, Xerox and HP).
    Wednesday, May 07, 2014 7:38 PM
  • Hi there, we too have encountered the issue with users not being able to map printers that use downlevel drivers. However we now have a resolution to this - I have tested this but this wont be in production til the end of next week.

    For the TrustedDriverPath registry entry add one of the following entries depending on OS

    x86 ->  \\PrintServerName\print$\W32X86

    x64 \\PrintServerName\print$\x64

    where PrintServerName is your print server with the required drivers.

    This allows the spooler to locate the drivers for these down-level printers and users can then map these printers.

    Thursday, May 08, 2014 11:11 PM
  • Hi GetPeter,

    I work in an enterprise environment that is being effected by this issue.  I tried emailing the address you provided but did not receive a reply.  I am very interested in obtaining your custom .exe file.  If you no longer have the file, do you think you could post the script in question?  That would be appreciated.  Thanks GetPeter.

    Thursday, May 22, 2014 10:23 PM
  • Is there still going to be an official fix/patch to install on clients? This really is a huge issue. We don't want to push out temp fixes if a true fix is in the works.
    Tuesday, May 27, 2014 12:32 AM
  • Alan,

    Would it be possible for you to provide a status update on where Microsoft is with this issue? This thread has been informative be there doesn't seem to be a clear solution.

    Thanks

    Wednesday, June 11, 2014 2:42 PM
  • We are seeing the same issue trying to add Canon printers from non-admin accounts with the registry entry "LoadTrustedDrivers"=dword:00000001 in place. That makes this "solution" unworkable since we have a significant number of Canon MFDs in use.

    Trying to work around the Canon issue by specifying the print server name in the TrustedDriverPath would be problematic to implement due to the number of print servers in place and a real nightmare to maintain as our print server environment changes over time.

    Thursday, June 12, 2014 1:05 PM
  • Carlitog,

    My only question about your resolution for allowing older drivers to install would be the following:

    Does adding the print server's driver repository to the "TrustedDriverPath" totally negate the "workaround" suggested by Microsoft. Wouldn't adding the path allow the computer to treat the "Package Aware" drivers as legacy "Point and Print" drivers instead?

    I'd love to hear feedback form your results or a statement from Microsoft related to their original "workaround".

    Monday, June 16, 2014 5:06 PM
  • I feel you pain as I am in the same boat due to the multiple printer servers on the domain. Microsoft really needs to listen to the issues that were are experiencing  and work with the people better. Large companies running around to address access denied printing issues.  Has anyone tried anything else recently?
    Monday, June 23, 2014 1:35 PM
  • 2896881 applies to x64 bit version of windows, what about x32bit? Is there any hotfix for it?

    Regards,

    Kris.

    Wednesday, June 25, 2014 11:49 AM
  • 2864755 has been removed from support.microsoft.com. It was there yesterday.

    Article ID: 2864755
    “Printing fails when you use a shared printer in Windows 7”
    http://support.microsoft.com/kb/2864755

    The error is:
    Oops! The page you are looking for may have a new location, or is no longer available."=
    Wednesday, July 16, 2014 12:03 AM
  • ha, ha ! Maybe it's my fault. I asked Microsoft for this fix because the link to download the hotfix was going to a Call Center. They told to me that this fix was for Microsoft private only and not for Enterprise. A few minutes after my call (In Switzerland) the link button for the hotfix was removed. And now it is the URL..

    In my enterprise we have 5200 Windows 7 32bits OS and this trouble is very painful !!

    Please Microsoft ! Do something very, very quickly !!


    Thursday, July 17, 2014 11:45 AM
  • The page is back online and the date has been updated. It does not look like Microsoft has a fix yet for this issue, just workarounds.
    Monday, July 21, 2014 1:07 PM
  • The page is back online and the date has been updated. It does not look like Microsoft has a fix yet for this issue, just workarounds.
    Interesting. The new article has the workaround steps John Dickson provided (adding those two reg keys) removed along with removing the section about an available hotfix.   Google had the revision 7 of the article cached so I could compare the differences. 
    Monday, July 21, 2014 5:39 PM
  • We opened a case with MS Premier Support and I was told that article 2864755 had been pulled (along with the Hotfix) due to some side effects. They have since provided me a copy of the updated Hotfix "for testing purposes only" and I am currently trying to get a few systems to test with. Since our Customer Service Center systems are the heaviest hit with the issue, it is hard to get willing testers. I will post in a few days with the initial results of the Hotfix testing. 

    To date we have seen most of the issues mentioned in this thread. We can temporarily correct some of the issues by either deleting the printers and cleaning up the Driver Store or by deleting the following Registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\PRINT_DRIVER_NAME

    The one we cannot resolve yet is the Error 57. To work around these we are connecting the users directly to the printers IP address, bypassing the print server.

    I am hopeful the Hotfix will correct the Error 57 issue and prevent the other issues from occurring .My fingers are crossed that this does the trick!
    Monday, July 28, 2014 6:49 PM
  • I have opened a premiere support case with Microsoft. I have learned that there is a new (created in June 2014) private hotfix available that is still being beta tested. If you open a case with Microsoft you can request the hotfix for your environment. I learned that about 60 enterprise customers are currently testing the hotfix and due to the intermittent nature of the problem, feedback is slowly being reported, but there is no definitive fix yet. We will try the hotfix on a few known-problem computers and see if it fixes the issue. 

    Summary (still having intermittent issues):

    This is not working. In addition to hotfix 2896881, the proposed work-around registry tweak is:

    HKLM\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers

    Values:

    LoadTrustedDrivers(REG_DWORD) – This should be set to 1.

    TrustedDriverPath(REG_SZ) – This should be set to (“”) This is the file path that will be searched for the driver. Set this value to a NULL string of  (“”).Type beginning parenthesis then two double-quotes then ending parenthesis.

    The problem-indicating symptom is missing printer dependent files in registry:

    HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\HP Universal Printing PCL 6 (v5.x.x)

    HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\HP Universal Printing PCL 6 (v5.x.x)

    "Configuration File"="hpmdpxxx.dll"

    "Data File"="hpcu1xxx.gpd"

    "Driver"="unidrv.dll"

    "Help File"="unidrv.hlp"

    "Print Processor"="HPCPPxxx"

    "InfPath"="C:\\Windows\\System32\\DriverStore\\FileRepository\\hpcuxxx.inf_x86_neutral_d00f6e069db97f95\\hpcuxxxc.inf"

    The problem symptom can be any of the following:

    Corrupted “hierglyphics” printing one character per page with paper drawer emptied

    Grayed-out, non-available Printer Properties form (can only print using default settings)

    No printed output, print spooler does not create print file

    Work-around fix:

    1. Wait for end-user to report problem symptoms
    2. If a thick client (laptop or computer):
      1. Remove printer connections (use scripted in-house tool)
      2. Recreate printer dependent files registry settings (use scripted in-house tool)
      3. Restart Print Spooler service
      4. Add printer connections (use scripted in-house tool)
    3. If a thin client (virtual desktop):
      1. User logs off VDI machine (not just disconnect; logoff has effect of power off of virtual machine and disposal)
      2. New VDI machine is created on-the-fly from known-good working template



    Tuesday, July 29, 2014 8:16 PM
  • Is anyone else finding that this issue seems to come and go?

    We had developed a VB application to be able to scan particular OUs for computers that were missing the dependent files key (and if it detected any to log them, and then give you the option to reset those keys remotely) - we were finding a low percentage of our computers were having this issue globally, but one particular office was having it happen nearly daily to ~30-40% of the machines.

    We contacted MS and opened a premiere support case and recieved a private hotfix and some ETL logging scripts, but the issue seems to have stopped happening to as many machines as before.  We had the same thing happen about a year and a half ago, where it was affecting 30-40% of the machines in one particular office (of ~200 users) but it seemed to just stop happening then as well.

    Tuesday, August 12, 2014 4:29 PM
  • Has anyone experienced this with a Windows 2012 print server?

    As this thread was started over two years ago now, and there's been no successful publicly released fix, I'm considering whether migrating our print servers to 2012 would be the quickest resolution.

    Could anyone from MS comment on the scope of the issue?

    Friday, August 22, 2014 8:23 AM
  • We tried switching one of our divisions over to a test print server running 2012 R2 early on when our issues started, and it did not resolve the problems. It sounds like this is a client-side issue with Windows 7. The few 8.1 machines we have in our environment have so far not had any problems.
    Tuesday, September 16, 2014 8:37 PM
  • We are currently experiencing the issue on Windows 7 32 & 64 bit Win 7 clients connected to both 2008 and 2012 servers.  The commonality we notice is that we are using HP PCL6 UPD as we have many different models of printers.  Is this happening to everyone who is strictly using UPD drivers?
    Thursday, September 18, 2014 2:12 PM
  • I've experienced this issue with multiple printer vendors (HP & Ricoh) UPD drivers on Win7x64. 
    Thursday, September 18, 2014 7:20 PM
  • We use HP, Xerox, and Ricoh printers in our environment mostly. We use a hybrid of some UPDs and some not, depending on functionality and what is available for a specific model (We have a lot of absolutely ancient printers). It seems that while the UPDs may be causing the issue, they are not the only ones affected. We have non-global print drivers that also sometimes lose the dependent files value.
    Thursday, September 18, 2014 8:08 PM
  • Hello all,

    I know that this thread is old, but we are experiencing the same problem described here. We have tried all of the fixes that were listed, the KB2896881, the registry entries, etc, but nothing is fixing the issue permanently. To fix the problem for our customers, I've created an Altiris Deployment Solution job that just re merges the dependent files back into the HP Universal Driver reg key, stop and start the spooler, and it works...for a while. 

    We have opened a case with Premier support, so I am waiting to hear back from them. The last post here was from a couple months ago, so are there any updates to this issue from your perspectives?

    Thanks!

    Thursday, November 13, 2014 5:16 PM
  • We have released a new hotfix that resolves the dependent files issue.

    The machine must be in a working state for the hotfix to prevent it from occurring again.

    Below is the link to the hotfix:

    Print jobs fail in Windows 7 and Windows Server 2008 R2
    http://support.microsoft.com/kb/3001232


    John Dickson Senior Support Escalation Engineer Microsoft Platforms Core Team

    Wednesday, November 19, 2014 2:45 PM
  • Has anyone tried out this hotfix yet?

    I've been using an auto-remediate method utilizing ConfigMgr and PowerShell for awhile:

    http://myitforum.com/myitforumwp/2014/12/29/remediate-registry-string-array-values-using-compliance-settings-and-powershell/

    Monday, December 29, 2014 8:17 PM
  • Hi John,

    Does this new hotfix need to be applied to the Windows 7 clients only or to the Server 2008R2 as well?

    Tuesday, August 04, 2015 1:53 PM
  • We have a Server 2012 R2 server, using the HP Universal Print Driver 6.0.0 and we are seeing this on a lot of our PCs, I did create a powershell script to check for the missing Dependent Files Key and update the key with the correct information which solves the issue, now we'll roll out the hotfix. 

    Do we know why this is happening? 

    Friday, August 14, 2015 11:41 AM
  • Do we also need to apply this patch on our Windows Server 2012 R2 servers?  or only the clients?
    Thursday, December 10, 2015 6:02 PM
  • To client machines.

    If the 2012R2 is making a connection to a shared printer, then yes, since it is a client at this point.


    Alan Morris formerly with Windows Printing Team

    Monday, December 14, 2015 3:02 AM
    Answerer
  • I've been following this issue, since around the time this thread was opened.

    The clients in our organization (> 4000), started suffering the symptoms listed here, almost immediately following the migration to Windows 7.

    We've deployed the permanent hotfix kb3001232, with some success.  It has also been placed on our build image to prevent new incidents.

    Today, I've received the first instance of the issue on one of our Windows 8.1 Surface Pro devices.  As the KB article only applies to Windows 7 clients, I don't have a permanent fix for the device.

    Is there an equivalent hotfix for Windows 8.1+ anywhere?
    Monday, April 04, 2016 3:23 PM
  • I've been following this issue, since around the time this thread was opened.

    The clients in our organization (> 4000), started suffering the symptoms listed here, almost immediately following the migration to Windows 7.

    We've deployed the permanent hotfix kb3001232, with some success.  It has also been placed on our build image to prevent new incidents.

    Today, I've received the first instance of the issue on one of our Windows 8.1 Surface Pro devices.  As the KB article only applies to Windows 7 clients, I don't have a permanent fix for the device.

    Is there an equivalent hotfix for Windows 8.1+ anywhere?
    The print server remains at Windows 2008 R2.
    Monday, April 04, 2016 3:25 PM