Unable to repro this issue on Windows 7 using chrome version 59.0.3071.109. Seems this is related to Terminal Server Environment, adding TE-NeedsTriageHelp label and routing to the cloudprint team for further investigation.

Thanks!

Furthermore we found Error's like that while Printing:

[18204:12020:0713/083745.959:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_plugin from binding interface: memory_instrumentation::mojom::Coordinator exposed by: content_browser

Deleted: valeska.janke.log 912 KB

valeska.janke.log 912 KB View Download

Sorry NOT while Printing rather using Print-Preview.

As per the info in #5. lopping to few- //src/services/service_manager/OWNERS for further updates. 

In print preview, does "Save As PDF" work properly? Is the "Microsoft XPS Document Writer" available? If so, does that work properly?

re: comment 5 - that's probably a red herring.

"Save As PDF" works fine but the "Microsoft XPS Document Writer" works not as expected. XPS Document Writer is selectable but doesn't create the .xps file. 

If printing isn't possible the PDF Print Preview looks like the attached file

Deleted: Hoppla.jpg 92.0 KB

	Hoppla.jpg 92.0 KB View Download

+julian/georges to see if this is something chrome-enterprise can help with

In the meanwhile we have opened a support case:

[#13157871] Chrome Printing Issue

+Lei for visibility in the print team too.

Hi,
Same problem for me
RDS 2012 + Chrome up to date.
Since 1 st July i think.

Hi,

We have the same issue in our RDWeb/session host environments.

The issue was tracked back to Chrome deleting the 'per session temporary directory', where files are spooled briefly before being sent to a print server or the printer itself.

When you log into the session host, browse in Explorer to the top-level '%TEMP%' directory, you'll find a per-session folder named some pseudo-random integer; that integer maps to the session ID of the user on the session host.

If you launch Chrome and watch the folder (from the parent directory, so that you are not actively "using" the directory by being in it) for 1 - 20 minutes or so (it's totally arbitrary from what I can tell), you will see the directory get deleted.

I enabled advanced file auditing and tracked 'Chrome.exe' executing a 'DELETE' action on that folder; see the attached 'Events.zip' archive, which has a snippet of the Windows event log showing this.

I submitted a separate bug report about this, but never received any reply or update.

To resolve the issue, we Revo uninstalled Chrome, cleaned registry via CCleaner, and installed 58.0.3029.110 (64-bit). To prevent updates, we use the ADMX templates and disable updating on the session hosts.

Deleted: Events.zip 11.1 KB

Events.zip 11.1 KB Download

Hi Lei,

I am upping the prio on this bug to draw attention to it as it seems to be a blocker for whoever happens to be hit by it. 

C#15 lists a well reasoned investigation and it will be worth figuring out why would Chrome shoot itself in the foot like this. I can provide you with access to a test environment if this is not enough to figure out what is going wrong there.

As a side note, we initially noticed this issue because of the printing issues, but also because of third-party applications that make use of that directory.

When the temporary directory gets deleted, .NET applications (and, presumably, others) immediately crash because the exception of 'path does not exist' bubble all the way up. If you have other odd reports similar to this, it may be the culprit as well.

Tagging as RBS for tracking purpose.

 
When we start the logs (  chrome://net-export/ ) and then stop again, the print preview works and also the print. But this is not the solution but very strange.

Any update on this? We are having the issue at more and more clients.

Haven't had time to look into this. Too many bugs to work on.

Enterprise folks: Do you have a test environment that can reproduce this problem?

The original bug reporter said "Chrome PDF-Viewer is affected everytime" - so is only PDF printing affected? Can you print webpages? e.g. Wikipedia. I would like to understand if this is a PDF printing issue or general printing issue.

re: comment 10 - If "Microsoft XPS Document Writer" does not work, can you attach the log for that session? When the "XPS Document Writer is selectable but doesn't create the .xps file." does it get to the point where it pops up a "Save As" dialog?

Also, please note that screenshot is for the PDF preview in Gmail, which is not the same as the Chrome PDF Viewer. The UIs are very different.

re: comment 15 - What other bug report did you file? I don't see any bugs filed by you on this bug tracker. Is the "per session temporary directory" you are referring to the same for the entirety of Chrome's lifetime, or is it something that is generated per print job? Do you see any files in these temp directories? If so, what's inside?

re: comment 15 - The events for chrome.exe in Events.zip just say "an object has been deleted" but doesn't provide any more detail than that. Did I miss something?

Tried in Windows Terminal Server and Citrix Environments. I am able to save as PDF and XPS viewer. Unfortunately cannot have a classic printer / cloud printer setup to print a hard copy in our test environment.

Chrome Version: 60.0.3112.90
 

The original reporter also said "The problem is that sometimes no output reaches the print queue." - Is "sometimes" 10% of the time? 50%? 90%?

re: 21:
--------
The previous report I filed was was through whatever the bug report page that Chrome brings you to is.

Session hosts/terminal servers, by default, create a temporary directory for each active session on the server - see here for reference: https://technet.microsoft.com/en-us/library/cc755098(v=ws.11).aspx

The 'per session temporary directory' itself lives inside of the 'Local' %APPDATA%, and is used by all kinds of programs - and given the ephemeral nature of it, listing what's inside would be largely pointless and probably not useful. But yes, there's lots of stuff inside.

If I had to guess, it is probably used by programs (perhaps Chrome) that don't even know it, as it may be baked into .NET or other platforms as a "scratchpad" of some kind. But that's just my feeling, can't prove it.

re: 22
-------
In the logs, it shows what process deleted the temporary folder ('CHROME.EXE').

re: 24:
---------
first of all excuse me for response so late. I was in vacation.
Sometimes means 20 % of 2000 User every day. The problem is roaming and hits every day another user.

re: 25:
--------
Thank you for the good analysis. 
Additional it is not recommended include the %temp% folder when using roaming profiles because of reducing disk space. So in my point of view this can be a solution. 

M62 is branching soon and We will be taking only CRITICAL merges. Please plan accordingly.

What does that mean in terms of this bug?

We are using Chrome 60 since Monday and the printing issues are gone. Thanks for Support.

re: comment 28 - Well, I would like to solve this, but I have yet to be able to reproduce this bug. Anything I try is just a shot in the dark at this point.

re: comment 29 - Sorry to be pessimistic, but given the rates you mentioned in comment 26 - I'm concerned the issue is still there, but you may have gotten lucky. I really can't explain why it would work in M58, break in M59, and work again in M60.

Hi,

In terms of reproducing the issue, do you have an RDS farm set up? It was relatively easy to reproduce on the session host - log in, launch Chrome, watch '%TEMP%' for about 10 - 15 minutes, and it would eventually be deleted.

It was a little sporadic, where I'd have to log out and back in a few times for it trigger, but it would happen about 80% of the time.

If you'd like to go through this in more detail, I'd be happy to do a screenshare or something similar to walk through this.

Thanks,

-Lucas

thestig@ - A friendly ping.

Please can you provide an update on this issue, as this is a Stable Blocker issue.

Thanks.

thestig@ Since this issue is marked as RB-Stable, could you please let us know is there any latest update available on this issue?

Thanks!

thestig@ Gentle Ping! can we get any latest update on this issue? since it's blocking M62 stable release. 

Thanks!

Hello everybody,

for us error was gone since version 60. At the moment we are working with version 61 in a Citrix Environment with 2000 concurrent user. No problem here.

re: comment 35 - That's good to hear.

Has anyone else noticed a similar improvement?

Removing the release blocker label for now.

The original bug reporter says the problem has gone away, and nobody else has replied in 8 months. So I'm going to close this.