Could someone from print team, please look into it.

- To be clear, VDI is a Citrix desktop virtualization product?
- What printer are you printing to exactly? What's the printer model / driver version? Is it a Citrix virtual printer of some sort that passes through to a real printer?
- If you add launch Chrome with the --disable-gdi-text-printing command line flag, does that help? https://www.chromium.org/for-testers/command-line-flags

VDI (Virtual desktop infrastructure) is just a term, we are using VMWare Horizon view to launch the virtual desktops for staff. I've had 3 staff members that suddenly have had this printing issues in Chrome on their virtual machine, if they are outside of chrome on the same virtual machine they can network print without issue.
The printers have been various Xerox copiers as well as one Konica Minolta Copier.
I will have a user try launching Chrome with the command line flag, I will try and report back today.

Also for clarification, this is just a standard network printer that they have added to their windows desktop. Nothing special that is passing through to anything.

Ok, please let us know if the command line flag helps. Also, can you elaborate on what "Jobs don't print" means exactly? You start in Chrome's print preview, you select a printer, you hit print... what happens next? Does the print preview dialog go away? Do you see a print job go in the printer's queue? Do you get an error message?

So far on the one user that I have been able to test with the printing is now working with the command line flag. 

Without it, when in Chrome, selecting print, the print window would appear, their printer would be selected (network printer), they would click print, the window would go away, nothing would be sent to the print server queue.

An example would be printing a PDF attachment from Gmail, it won't print from the print preview in Chrome, but if I download the same document and open it in Adobe Reader, the PDF will print without issue. 

An update from my end user that we were testing with. The printing worked for the first few documents, and then failed to print to the network printer. It seems to be sporadic when it will work and not work. The user can turn around and open the same document outside of Chrome and network printer still. 

So it sounds like --disable-gdi-text-printing improved the situation, but the same problem still comes back after a while? That's rather strange, since the switch is either on or off. There shouldn't be an in-between state where it works sometimes. Was it failing 100% of the time before you applied the command line switch?

With the users that have had the issue, network printing fails from the browser sporadically. I'm now up to 4 users who have experienced this issue. The command line flag doesn't seem to solve the issue as the issue seems to come and go.

So what is the failure rate like? i.e. If one repeatedly try to print, how long does it take hit the problem? If one was to downgrade to Chrome 53 for instance, how attempts would you say it takes to be confident that Chrome 53 does not have this problem?

Thank you for providing more feedback. Adding requester "thestig@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Another test worth doing is when the printing fails, can you try using the system printing dialog instead? Ctrl+Shift+P should do it.

Thanks for the tip. We will try that the next time we encounter an issue. We allow our users' browser to update automatically, which may mean we may never see the issue again from my side.

We also have several persons who have issues with printing from Chrome (54.0.2840.99). We are also in a VDI environment (VMs are hosted on VMWare ESX; Citrix is used to publish the desktop). All our users are using VDI, but not all have this issue or have not reported having the issue. In some cases the printing issues are specific enough that users may not be aware that there is an issue. 

Printing in Google Chrome, using the Chrome printer GUI does not work at all for certain users under certain circumstances.  

Scenario includes the following points: 
  •	All printers mapped for affected users are impacted
  •	Any page loaded in Chrome that are more than 1 page including webpages or PDF documents (simplex or duplex print settings does not affect this)
  •	Using the Chrome GUI to print causes the print job to be submitted and can be seen entering the printer queue but loads no data and passes through the printer queue with no print job resulting
Note: Printing documents or web pages that are 1 page long from Google Chrome Print UI succeeds, causing a “false positive” where the user may not be aware that they are affected. 

Work around (each work around works every time): 
  •	In the Chrome print GUI – print each page simplex, one page at a time
  •	In Chrome – press ctrl + shift + P to bring up the Windows print dialog
  •	Use another application to print the document, if possible

This appears to be consistent for those who are impacted and can be repeated. 

+James for comment + info on next steps

We're considering adding an admin control to make the system dialogue the default, but no definitive timelines for this. For now, I'd suggest continuing to use the workarounds described #16.

We've been experiencing the same issues as described above. Our VDI environment is VMWare View; we noticed the issue came up after we upgraded from 53. 

Is there any way we can request an official Chrome 53 (offline) installer? 

Original poster here.

We are still having the issue with network printing within Chrome, now up to version 55. At times the work around for using the windows print dialog doesn't work either from Chrome. Our current workaround is to have people switch to Google Cloud printing to print from Chrome, they can network print from other applications.

Thank you!!  Misery loves company and I feel so much better now;)  I was going crazy thinking we were the only ones when this printing issue popped up in our Horizon View 5.5 VDI environment.  Desktops are Windows 7 Professional.  Our Chrome printing difficulties are primarily with printing Google Docs but there have been some reports printing web pages also.  Printing was fine until we first updated to Chrome 54 and then continued with 55 and 56.  Behavior is intermittent but fairly easy to reproduce:  click print,  the print preview displays,  we select the printer and then click print.  The job looks like it enters the print queue briefly with "spooling" as the status but then disappears with nothing printed.  I've tested with Windows print shares,  locally installed IP printers, networked Xerox copiers, and CutePDF writer.  CutePDF is excellent for troubleshooting this issue without wasting paper.  We've noticed that CTRL+SHIFT+P usually works as a workaround, but we are not certain if it works 100% of the time.  Toggling some settings in the print preview such as changing the margins, changing which pages to print, or changing between color/B&W will usually produce a successful spool and then print out.  It also seems as if toggling to a different printer like the "Save as PDF" option and then back to my actual printer seems to also work.  Is Chrome having a problem when using the last remembered/used printer?  Reverting back to version 53 always resolves the issue, but we don't want to hold these pools back this long.  I'm going to try the --disable-gdi-text-printing option tomorrow and report back.  

Thanks in advance for any other suggestions/clues.  

H.

RE: comment 22: --disable-gdi-text-printing is the default in Chrome 55 and 56 (and later versions of 54). GDI was disabled by default due to  http://crbug.com/658606  and while we think that issue has been resolved we have not rolled it back out to Stable yet. So unless you are on Canary, GDI text printing should already be disabled.

RE: comment #23: Thanks for version clarification and --disable-gdi-text-printing info.

RE: comment #16:  +1 on problem only seems to be with print jobs which are more that 1 page.  Single pages print every time for us.

Event logs confirm what I see happening in the print queue.  I enabled operational event logging under Event Log-->Applications and Services Logs-->Microsoft--> Windows -->PrintService and can see the following two entries when the printing fails: 


Information	3/1/2017 6:41:16 PM	Microsoft-Windows-PrintService	310	Deleting a document	Document 16, Test Google Doc - Google Docs owned by JoeBob was deleted on PDF Writer. No user action is required.

Information	3/1/2017 6:41:15 PM	Microsoft-Windows-PrintService	800	Print job diagnostics	Spooling job 16.

Any updates on this issue?  I am experiencing the same issue, on Windows 7, Chrome Version 57.0.2987.110 (64-bit).  (we've updated several times - this started Feb 28.)  Note:  Chrome browser is the only application not printing successfully.

No matter how i access the Print function, once i click "print" i can see the doc show up momentarily in "spooling" status, and then it disappears.  If I change settings before printing, i can sometime get to it stick in the Print Properties box, but it never leaves "spooling" status.

I've tried several things per the suggestions above, but the message in the even log indicates:

Log Name:      Microsoft-Windows-PrintService/Admin
Source:        Microsoft-Windows-PrintService
Date:          3/20/2017 6:09:14 PM
Event ID:      372
Task Category: Printing a document
Level:         Error
Keywords:      Classic Spooler Event,Document Print Job
User:          Dell7100-PC\username
Computer:      Dell7100-PC
Description:
The document c-i-14.pdf, owned by uesrname, failed to print on printer Brother MFC-9340CDW Printer. Try to print the document again, or restart the print spooler. 
Data type: NT EMF 1.008. Size of the spool file in bytes: 0. Number of bytes printed: 0. Total number of pages in the document: 0. Number of pages printed: 0. Client computer: \\DELL7100-PC. Win32 error code returned by the print processor: 259. No more data is available.

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>372</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>26</Task>
    <Opcode>12</Opcode>
    <Keywords>0x8000000000000840</Keywords>
    <TimeCreated SystemTime="2017-03-20T23:09:14.071240600Z" />
    <EventRecordID>1533</EventRecordID>
    <Correlation />
    <Execution ProcessID="1972" ThreadID="12864" />
    <Channel>Microsoft-Windows-PrintService/Admin</Channel>
    <Computer>Dell7100-PC</Computer>
    <Security UserID="" />
  </System>
  <UserData>
    <PrintOnProcFailedEd xmlns:auto-ns3="http://schemas.microsoft.com/win/2004/08/events" xmlns="http://manifests.microsoft.com/win/2005/08/windows/printing/spooler/core/events">
      <Param1>c-i-14.pdf</Param1>
      <Param2>username</Param2>
      <Param3>Brother MFC-9340CDW Printer</Param3>
      <Param4>NT EMF 1.008</Param4>
      <Param5>0</Param5>
      <Param6>0</Param6>
      <Param7>0</Param7>
      <Param8>0</Param8>
      <Param9>\\DELL7100-PC</Param9>
      <Param10>259</Param10>
      <Param11>No more data is available.
</Param11>
    </PrintOnProcFailedEd>
  </UserData>
</Event>

any insight is greatly appreciated!

Have not found a solution yet aside from workarounds described above, but I have not tried version 57 yet.  Will report back after we test 57.  
Your problem seems a bit different than ours though.  This only happens to us with our Horizon View virtual desktops.  Regular desktops are fine.  You are getting an error message on print failure, ours just quietly disappears from the queue.  Our View environment is a few versions back so that might have something to do with it, but we won't be updating that until the summer.  


   

We finally got a working set up with the help of our enterprise team, and we can reproduce this problem. Will keep looking into it.

This is encouraging. Please let me know if you need any further information. We are still seeing this issue even with the Chrome releases since I put in this issue. 

Is there any particular setting, page to print, or sequence of steps that makes this bug more likely to occur? We were able to reproduce this very inconsistently the first day we tried it but more recent attempts to reproduce it with the same sequence of steps have failed, and the low frequency of the bug made it impossible to precisely track down where this might have regressed. When it did reproduce it seemed to occur <10% of the time; it would be helpful to know if there is some case that fails more frequently than that.

It's hard to say if there is something particular to key in on. We saw the issue the most prevalent in our school district's copy center. They print documents that are emailed to them from staff, many times attempting to print from the built in Chrome document viewer. The same document could be downloaded and saved and then opened in the native program and printed without issues. However we have also seen the same problems printing from our student information system which generally generates PDF's or is just web pages that are printed.  

Okay. Are you still seeing this at the same frequency you were originally? I can reproduce it somewhat consistently using Chrome 54 with GDI printing enabled, but it seems to happen only very sporadically on current stable (57). Have you seen a similar improvement between 54 and 57 or is it still just as bad as it was?

Thanks for looking into this.  

Most of my testing centered around printing from Google docs.  The document I would test with just contained text and was two pages long, no graphics or anything embedded.  I also did most of my testing with CutePDF so I didn't waste reams of paper.

It would fail pretty consistently if I opened the Doc and just selected Print from the menu and then the Print button in the preview, without touching anything else.  If one of the settings were changed such as pages to print or the margins it seemed to print OK.  

re: comment 32 - If there is a doc that reproduces this problem for you more consistently, and it's not confidential, can you share a link?

Definitely not confidential ;)  Here you go:
https://docs.google.com/document/d/1AftEi2hNZL_HfAtILVHVzd9XtfEVF38Q7fB4GhhaFHc/edit?usp=sharing

To clarify, CutePDF is installed as a local printer on the VM? Trying to determine if this is an issue on all printers or only network printers.

Also, how frequently does the issue occur? With the document linked in comment 34 I have seen a < 5% failure rate so far on Chrome 57. Does that seem correct or is this problem occurring more frequently than that? 

Happens with network IP and Windows shared printers as well.  CutePdf was
just used for testing.

Didn't really pay attention to the failure rates as I would go right to
print testing from a fresh logon session and try settings until it
printed.   Once a print was successful it seemed to "hold" for a few
prints.

Testing observations so far:
- This bug reproduces reasonably consistently on Chrome 54 with GDI enabled. 
- It seems to very occasionally reproduce on versions before that (53 and below) as well as on more recent versions.
- Specifically, with the doc provided in comment 34 and a few other test cases we have been trying, this will often work at least 50-60 times in a row (generally stopped testing after 50+ successful attempts) on current versions of Chrome.
- On newer versions of Chrome the state of the GDI flag does not seem to have any effect on the failure rate.

The very low failure rate on current versions of Chrome makes this extremely time consuming to debug, so progress on this will be slow until we can find a consistent (or at least semi consistent) way to reproduce the issue. Please update if you see this happening more consistently and if possible let us know what setup/driver/printer/document causes it to occur frequently so that we can investigate further.

Been watching this for a little bit now. Here is our environment in case it helps. So far across our organization this is only happening for 3 different users, all using the same machine. When printing from chrome it's almost like the job gets lost. The same document needs to be printed multiple times for it to actually print. Printing outside of chrome has no issue. 

Hardware
HP T620 Thin Client

Software
VMware Horizon 7 version 7.0.3
Chrome Version 57.0.2987.133

Network Printer
HP LaserJet Enterprise M606

Print Driver
HP Universal Printing PCL 6(v5.3) Print Driver

Im happy to collect any other logs or details if it helps the cause. 

I had a user who experienced this same issue again today. She was printing a PDF document out of our student information system.

Hardware:
Samsung Zero Client

Connecting to our VMware Horizon 6.1.1 environment

Network Printer:
Konica Minolta C654

Printer Driver:
Konica Minolta C754 Series PCL (same driver for both C654 and C754)

If I manually downloaded the document and opened in Adobe it would print properly. Every time it would not print from Chrome, if I watched the print queue, it would briefly flash in, but nothing would ever print.

Just wanted to check in and see if the situation has improved with Chrome 61 or newer.

Nope. We updated our VDI desktops to v61 for the opening of school. After a week, we reverted back to v53 to get printing capabilities stable.

We are still seeing issues with 61 as well. We are continuing to point our users to use the system dialog, which seems to continue to be the best workaround.

Ditto on staying at v53 or instructing to use system print dialog on higher
versions.

Thanks for the update. We'll try looking at this some more so folks affected can stop using v53.

More questions - In these VDI sessions, are the user profiles on the c:\ drive or are they some kind of roaming profiles? If they are on the c:\ drive, is that drive a hard disk from Windows's perspective, or is it a network share, or something fancy? What is %TMP% and %TEMP% set to?