sorin@, can you please take a look since you've worked on similar kind of issue (https://bugs.chromium.org/p/chromium/issues/detail?id=741980) before?

I think that this is a bug in the component updater which may contain an execution path where that temporary directory is not deleted in case of some errors.

Is this a managed environment where downloads may be blocked for any reason?

Correct. This is on an intranet with only a handful of external websites that aren't blocked. We use Chrome enterprise edition that we can deploy with policies. For instance no Chrome user login, set bookmarks, manage extensions, ...

Thank you for responding. Can you please navigate to chrome://components and see if the components there are receiving updates?

I am almost certain that there there is an execution path that is leaking these directories, and I am trying to understand which one it is.

They are not receiving updates. We manually have to update Chrome on our clients with our own package system, because almost all external resources are blocked.

When I click update on any of the components I can see the temp folders being created and some even being removed again.

Deleted: Untitled.png 43.6 KB

	Untitled.png 43.6 KB View Download

As an unrelated topic, it seems to me that this instance of Chrome is not receiving component updates since the version of the components is 0.0.0.0, except for Widevine, which I assume it ships with Chrome.

Several of these components are related to security features, therefore not receiving updates for these components may be an issue.

I will continue working on resolving the directory leak.

I am not able to find an execution path that would result in creating and not deleting those directories, using the code on the tip of the tree.

Would it be possible for you to try the canary and the beta builds, since the code has been changed since M62?

The canary build is available here: https://www.google.com/chrome/browser/canary.html

and the beta build: 
https://www.google.com/chrome/browser/beta.html

I am certain there is a problem somewhere, I just can't find it yet.

Thank you!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/401f85a2ab3648de31140d6a739e8d405b71eefb

commit 401f85a2ab3648de31140d6a739e8d405b71eefb
Author: Sorin Jianu <sorin@chromium.org>
Date: Wed Nov 15 17:27:40 2017

UpdateClient: use containment for the UrlFetcher delegate.

This is a mechanical change.

Due to Clang code gen issue,
(https://bugs.chromium.org/p/chromium/issues/detail?id=785002), debugging
inside UrlFetcherDownloader is broken. Therefore, implemented the
delegate by containment, before fixing the directory leak.

Bug: 778150
Change-Id: I4513ee54394dd080988d556d0947c0dbe71508d2
Reviewed-on: https://chromium-review.googlesource.com/769771
Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Commit-Queue: Sorin Jianu <sorin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516733}
[modify] https://crrev.com/401f85a2ab3648de31140d6a739e8d405b71eefb/components/update_client/url_fetcher_downloader.cc
[modify] https://crrev.com/401f85a2ab3648de31140d6a739e8d405b71eefb/components/update_client/url_fetcher_downloader.h

Same behavior with Enterprise Beta MSI (32-bit) (v 63.0.3239.52)

Sidenote, we can not install canary/beta w/o MSI, the above is the only standalone I could find.

Thank you!

Would it be possible to run Procmon on a system that exhibits this behavior?
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

If yes,  I could provide further instructions on what we are looking for.

For some reason I can't add 'yes' as a comment... So yes, no problem.

Thank you for helping.

First, be aware that such traces may contain personally identifiable information. Please email me the trace instead of attaching it to the bug report. 

We will try to restrict the scope and minimize the data we collect from this machine.

When procmon starts, it opens a window asking the user to create of filter for the events to be displayed. I suggest adding a filter for "process name" contains "chrome.exe". After this, procmon starts collecting and displaying results that match the filter.

In the toolbar, there are a couple of important controls, starting from the left of the toolbar: capture/stop capture, and clear. We could use those to decide when to start capturing or clear the events.

I suggest the following steps to repro the bug, assuming it is possible to repro.
* clean up the temp dir where directories are leaked
* run chrome using the following command line arguments: --user-data-dir=c:\foo . This will make Chrome use a profile at the location C:\foo.
* navigate to chrome://components and trigger an update to one of the components there.
* inspect the temp dir and observe the directory leak.

If we can repro the bug like this, please use procmon to capture a trace for chrome.exe.
Please save the trace as a file, and email me the result. You could take a look at what was captured, by setting up additional filters, such as "path" contains "chrome_url_fetcher". I expect to see results such as:

2:58:53.4721126 PM	chrome.exe	14568	CreateFile	C:\Users\sorin\AppData\Local\Temp\chrome_url_fetcher_14568_15967	SUCCESS	Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created

2:58:53.6441139 PM	chrome.exe	14568	SetDispositionInformationFile	C:\Users\sorin\AppData\Local\Temp\chrome_url_fetcher_14568_15967	SUCCESS	Delete: True