Some problem here...

Deleted: issue860537.JPG 28.4 KB

	issue860537.JPG 28.4 KB View Download

We are in a terminal server environment and therefore have to disable updates. 

After Install we delete the following registry keys:
ECHO Y| Reg delete "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{8A69D345-D564-463c-AFF1-A69D9E530F96}"
ECHO Y| Reg delete "HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallSources"
ECHO Y| Reg delete "HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist"
ECHO Y| Reg delete "HKLM\SOFTWARE\Wow6432Node\Google\Update\Clients"

We disable the Update Services:
sc config gupdate start= disabled
sc config gupdatem start= disabled

We delete the two scheduled tasks that are created by Google:
“GoogleUpdateTaskMachineUA"
"GoogleUpdateTaskMachineCore”

And we set the following GPO:
Computer configuration > Policies > Administrative Templates > Google Update > Applications > Google Chrome >
“Allow installation” is Disabled
“Update policy override” is Enabled > Updates disabled

I can't say for sure if this is the issue. The owner of the bug is our installer guru but I know that disabling the service has been cause for weird errors like this before. I would suggest to check the official documentation about managing Google Update by policy here https://support.google.com/chrome/a/answer/6350036?hl=en which should allow you to achieve the same results without the need for such radical intervention.

Thank you for your feedback. Let's see what other people in this thread report. People also seem to have this issue on private home installations and I doubt that they disable services and stuff like that.
Are there people who have the google updater enabled but still see this issue?

case: 16303323
ProcMon File (CSV format) : https://drive.google.com/open?id=1Pe0LmTYH2viCX5eg15jAQ-F61ypQQTvs
screenshot of the error: https://drive.google.com/open?id=1DI_kW8RWfBK5QOgfAAxcWYqII8hPs-0I
the source of the MSI file is in c:\windows\ccmcache\6\

No, we do not disable the update service here. 

Same issue Win10 Pro 64bit  + Chrome 67.0.3396.99 (Official) (64bit) + Notes 9.0.1

Same issue Windows 10 Pro 64 bit. Chrome 67.0.3396.99 (Official Build) (64-bit). Started about a week ago with TurboCAD Symbols.msi, foler: C:\Users\RRB\AppData\Local\Temp\pft3EEB.tmp\. This is a home computer.

Private installation here and i do not disable the updater

Version 67.0.3396.99 (Offizieller Build) (64-Bit) Win 10 Pro 64 Bit / Notes 9.0.1.Social Edition / Same issue on more than 50 computers but not on Terminalservers (so far)

@matzal is Google Update disabled on those 50 computers?

I found similar issue in Chrome67 - see https://productforums.google.com/forum/#!topic/chrome/sck_PZ4Z7a0

I renamed C:\Users\username\AppData\Local\Google\Chrome to Chrome.old and restarted Chrome and the problem went away.

"Version 67.0.3396.99 (Offizieller Build) (64-Bit) Win 10 Pro 64 Bit / Notes 9.0.1.Social Edition / Same issue on more than 50 computers but not on Terminalservers (so far)"

Google Update is enabled

"I renamed C:\Users\username\AppData\Local\Google\Chrome to Chrome.old and restarted Chrome and the problem went away."

We also tried this but the problem reappeared after some time.

@matzal...@googlemail.com
Is the Lotus Notes Source maybe still on the server?
We are experiencing this with 10+ users. After "Cancel" the user can use chrome again. Renaming the directory is no option for about 350 Users.

Same problem here whenever using Google Chrome with the latest update. It's quite a nuisance. 

Deleted: popup.jpg 22.0 KB

	popup.jpg 22.0 KB View Download

Same issue here as well... the impact is to approx 46,000 clients. Same issue in the Canary build, FYI.

Needless to say, this is not good... :/

Looking more into the attached procmon logs it seems this can be related to our dll conflict detection logic. Adding the experts here to this bug.

Might be a red herring but all MSI related lines in the log lead to code paths inside c/b/conflits.

Chris can you please take a look?

Sample stack trace:
0	ntoskrnl.exe	CmpCallCallBacksEx + 0x375	0xfffff801e7563475	C:\Windows\system32\ntoskrnl.exe
1	ntoskrnl.exe	NtQueryValueKey + 0x416	0xfffff801e756b446	C:\Windows\system32\ntoskrnl.exe
2	ntoskrnl.exe	KiSystemServiceCopyEnd + 0x13	0xfffff801e721f043	C:\Windows\system32\ntoskrnl.exe
3	ntdll.dll	NtQueryValueKey + 0x14	0x7ffdfcf55684	C:\Windows\System32\ntdll.dll
4	KernelBase.dll	LocalBaseRegQueryValue + 0x15e	0x7ffdf940d60e	C:\Windows\System32\KernelBase.dll
5	KernelBase.dll	RegQueryValueExW + 0xed	0x7ffdf940c75d	C:\Windows\System32\KernelBase.dll
6	msi.dll	GetInfo + 0x4b6	0x7ffde6994e96	C:\Windows\System32\msi.dll
7	msi.dll	MsiGetProductInfoW + 0xd8	0x7ffde6992698	C:\Windows\System32\msi.dll
8	chrome.dll	MsiUtil::GetMsiComponentPaths + 0x88, C:\b\c\b\win64_clang\src\chrome\browser\conflicts\msi_util_win.cc(144)	0x7ffdb72f7ba4	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
9	chrome.dll	InstalledPrograms::CheckRegistryKeyForInstalledProgram + 0x3c3, C:\b\c\b\win64_clang\src\chrome\browser\conflicts\installed_programs_win.cc(204)	0x7ffdb72c272d	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
10	chrome.dll	InstalledPrograms::InstalledPrograms + 0x228, C:\b\c\b\win64_clang\src\chrome\browser\conflicts\installed_programs_win.cc(144)	0x7ffdb72c1b7e	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
11	chrome.dll	InstalledPrograms::InstalledPrograms + 0x3b, C:\b\c\b\win64_clang\src\chrome\browser\conflicts\installed_programs_win.cc(101)	0x7ffdb72c193f	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
12	chrome.dll	base::internal::Invoker<base::internal::BindState<`lambda at ../../chrome/browser/conflicts/third_party_conflicts_manager_win.cc:71:22'>,std::unique_ptr<InstalledPrograms,std::default_delete<InstalledPrograms> > ()>::RunOnce + 0x1e, C:\b\c\b\win64_clang\src\base\bind_internal.h(572)	0x7ffdb7294d82	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
13	chrome.dll	base::internal::ReturnAsParamAdapter<std::unique_ptr<autofill::AddressValidator,std::default_delete<autofill::AddressValidator> > > + 0x3c, C:\b\c\b\win64_clang\src\base\post_task_and_reply_with_result_internal.h(19)	0x7ffdb54e6485	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
14	chrome.dll	base::internal::Invoker<base::internal::BindState<void (*)(base::OnceCallback<void (storage::BlobStorageLimits)>, storage::BlobStorageLimits *),base::OnceCallback<void (storage::BlobStorageLimits)>,base::internal::OwnedWrapper<storage::BlobStorageLimits> >,void ()>::RunOnce + 0x37, C:\b\c\b\win64_clang\src\base\bind_internal.h(572)	0x7ffdb51feda7	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
15	chrome.dll	base::`anonymous namespace'::PostTaskAndReplyRelay::RunTaskAndPostReply + 0x37, C:\b\c\b\win64_clang\src\base\threading\post_task_and_reply_impl.cc(77)	0x7ffdb63355d7	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
16	chrome.dll	base::internal::Invoker<base::internal::BindState<void (*)(base::(anonymous namespace)::PostTaskAndReplyRelay),base::(anonymous namespace)::PostTaskAndReplyRelay>,void ()>::RunOnce + 0x60, C:\b\c\b\win64_clang\src\base\bind_internal.h(572)	0x7ffdb6335860	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
17	chrome.dll	base::debug::TaskAnnotator::RunTask + 0x135, C:\b\c\b\win64_clang\src\base\debug\task_annotator.cc(100)	0x7ffdb5167335	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
18	chrome.dll	base::internal::TaskTracker::RunOrSkipTask + 0x39c, C:\b\c\b\win64_clang\src\base\task_scheduler\task_tracker.cc(478)	0x7ffdb51f9c2c	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
19	chrome.dll	base::internal::TaskTracker::RunAndPopNextTask + 0x103, C:\b\c\b\win64_clang\src\base\task_scheduler\task_tracker.cc(369)	0x7ffdb51f96e3	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
20	chrome.dll	base::internal::SchedulerWorker::Thread::ThreadMain + 0x1ac, C:\b\c\b\win64_clang\src\base\task_scheduler\scheduler_worker.cc(85)	0x7ffdb51f849c	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
21	chrome.dll	base::`anonymous namespace'::ThreadFunc + 0xf4, C:\b\c\b\win64_clang\src\base\threading\platform_thread_win.cc(91)	0x7ffdb6303144	C:\Program Files (x86)\Google\Chrome\Application\67.0.3396.99\chrome.dll
22	kernel32.dll	BaseThreadInitThunk + 0x14	0x7ffdfaae2774	C:\Windows\System32\kernel32.dll
23	ntdll.dll	RtlUserThreadStart + 0x21	0x7ffdfcf20d51	C:\Windows\System32\ntdll.dll

Just adding my input...I added the procmon logs earlier in the thread.  We don't have the Google Updater disabled at all here.  These are all default installs of Chrome that have been automatically updated (via Google Updater) to 67.

Update - I disabled the Google Updater services and tried to recreate the issue, but the issue still occurred.  From my perspective, it's not the Google Updater causing issues.

I have the same issue on my organisation as well.

I have been able to stop the problem by removing IBM Notes as the default mail program. My Proc Mon seemed to be querying IBM Notes because it is set as the default mail. 

Hello he...@curtiscollard.ca.  This has been tested from my side as well, but it does not work.  Most the people in my organization, including myself, have Outlook set as the default mail program, however the issue still occurs.

Hey dyelu
can you have a look in the registry @
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail

Lotus Notes somewho manages to set itself there.

I set mine to "Mail;" the windows email client. Maybe try that? That or my
user's issue will come back in a little while. :(

Regards,
Curtis

We are having this issue also. 900 clients impacted. We used to use Lotus but now are switched to Office 365. Unfortunately still reference Lotus Notes for the databases. Any help would be greatly appreciated. 

Deleted: Windows Installer.PNG 111 KB

	Windows Installer.PNG 111 KB View Download

Hello he...@curtiscollard.ca, stephan....@gmail.com 
If that workaround holds then that's nice for those using Notes for mail but it's not a fix for all others as it's not just occurring in combination with Notes' setup but also other software.

+chrisha, pmonette who know about the third party code

Hey stephan....@gmail.com,

The default key is set to Outlook as well.

Hey @Google,

Can we get this further escalated?  This could be affecting over 500,000-1,000,000+ machines globally and is creating quite the headache for all of IT.

dyelu... 1-up from me!

I have a bunch of users as well.

I am still trying to repro this issue. From what I gather from the callstack in #50, the call to MsiGetProductInfoW trigger a reconfiguration of Lotus Notes, which is not something that I would expect.

I don't know if it's a red herring or not, but the call to CmpCallCallBacksEx is also suspicious. A driver is registered to receive notification when the registry key is accessed. This driver could be doing a lot of stuff during this notification callback.

I'll post back whenever I find something.

> the call to MsiGetProductInfoW trigger a reconfiguration of
> Lotus Notes, which is not something that I would expect.

Yep. Searching on MsiGetProductInfoW "side effect" (with the quotes) confirms this. This is the first hit:

https://sdmsoftware.com/group-policy-blog/wmi/why-win32_product-is-bad-news/

and the crucial quote is:

"""
To make matters worse, querying this class has a very annoying side effect that I just learned about, and that is documented in this KB article (http://support.microsoft.com/kb/974524). Here’s the issue. When you query this class, the way the provider works is that it actually performs a Windows Installer “reconfiguration” on every MSI package on the system as its performing the query!
"""

It isn't strictly talking about MsiGetProductInfoW but it seems likely that it is discussing the same issue.

Good find @brucedaw.  With Windows 10, you can't do a call to Win32_Product with WMI without all of the MSI's doing a reconfigure; we (my friend and I) found this out the hard way with previous packages we have scripted (internally).  You have to call another WMI class for this (which I can't remember at the top of my head).  If this is the issue, can you quickly remove this error checking and push out an update?

Thanks for the link Bruce! It is very helpful.

@dyelucky Chances are that I will have this fixed tomorrow. I apologize for the inconvenience.

Fantastic news @pmonette!  Please let us know when it is resolved.

Any update on this?

My company is experiencing this issue was well. Any updates?

Same issue here in my organization. Awaiting for updates.

Yep we are having the same problem as well.  And update on an ETA for a fix?  We are about to start packaging version 99, but I want to hold off if a fix is coming later today or perhaps tomorrow.  

Hi everyone.

I made a server-side change that should be rolling out as I write this. Allow a few hours for it to propagate.

Let me know if it works or not. Thanks!

Fantastic news @pmonette!  Thank you so much!  I'll let you know if it fixes it.

@pmonette, will that be to stable channel or beta that will be showing up in?  

This is going only to the stable channel.

We are seeing a new version appearing which, at least in very initial testing/feedback, appears to have stopped the issue... 

Chrome is now updated to this build:

Version 67.0.3396.99 (Official Build) (64-bit)

Is this the latest build that you have pushed, @pmonette ??

You shouldn't expect a new Chrome build. The issue should be fixed on all m67 versions.

So, with this fix, there will not be a version increment?  It will stay at 67.0.3396.99?  @pmonette

Perfect... we did see a change from 67.*.87 to 67.*.99...

In any event, we cant make the error/self-healing occur as of about 30 minutes ago...

Seems to be resolved, but I withhold my congrats for a day or so.  :)

@dyelucky Correct.

@greg.deguire Fair enough :)

Cool, thanks @pmonette!  I just restarted all of my Chrome services, etc., and at the moment, it looks like it should be fixed.  Lets give this 24 hours and more feedback before we close this ticket.  Thanks for all of your help!

@Everyone else, 

How are things working?  Did this fix resolve your issues?  In my environment, things are looking really good.

All good here... Thanks for the quick turn-around on this one!

Good job Chromium team... much appreciated!

Great to hear @Greg!  Thanks!

Yep all was good in my environment as well...

Also, great to hear!  Thanks @csutter6!  Now that there has been more successfully testing that has been done, I'm feeling better about the ticket being closed.  Again, let's wait until tomorrow (COB) to make sure this issue is resolved for everyone.

It seems to be solved since the .99 update..

How to get the fix applied to a PC having already Chrome 67.0.3396.99 installed?

 I have 67.0.3396.99 and the issue has not been resolved for me.

How can we install this update if we have automatic updates disabled? Is there a file we can replace or an installer?

Is there any bread crumb or flag that can be found on a PC to indicate that this fix has been applied since the Chrome version does not change?  Perhaps a version update or a time/date stamp on a particular file that we can check?  Thanks.

Issue for 2 of our 15 affected users appears to have been resolved.  Have not confirmed with others yet.  

For most of our users the issue was consistent and repeatable however a couple of our users indicated the issue wasn’t consistent. 

As mentioned earlier it would be nice to be able to see at least a time stamp showing that a particular pc should have the update patch or whatever this fix is called 

@tklep & @bworr,

I completely agree.  This would have make this resolution easier to track in solutions like Altiris/Symantec Management Platform or SCCM.  :)

Could be a coincidence but for us the issue got resolved once the new SoftwareReporterTool was downloaded yesterday. Might be worth checking the path

C:\Users\%userdata%AppData\Local\Google\Chrome\User Data\SwReporter\31.162.206

I have had 67.0.3396.99 before and now - and since today the issue is solved.

To check if the issue should be solve for your case, go to chrome://version and look for the "e56c5101" string in the variations list.

If present: The issue is still happening. Try restarting the browser twice to force Chrome to fetch the new config on the first restart, and apply it on the second restart.

If not present: The issue is solved.

Are you sure this is the correct string? Our current installation without automatic updates turned on which is on version 67.0.3396.79 already has this string but we are experiencing this issue with this version. The string we see is e56c5101-720b026c.

Maybe I wasn't clear enough, but you want it to NOT appear to have it fixed.

Ok got it. Thanks.
Is there any way to get this update without automatic updates turned on? The connection to google update servers is blocked in our environment.

Actually I misled you a little sorry!

What you want:
e56c5101-a0e56f74

What you don't want
e56c5101-720b026c
e56c5101-7c7ea110

we have the String present (e56c5101-a0e56f7489) but the issue seems to be solved...

@dominik My understanding is that if your connection to the variations server was blocked, you would never have hit the issue in the first place. Have you tried restarting Chrome twice to see if your variation in chrome://version changes to e56c5101-a0e56f74?

@ matzalaxy Yeah my bad see comment #108

Issue is resolved for me.  Thank you!

For us it worked, thanks!

Hey all,

I'm trying to further diagnose the issue here and I'm looking for a common denominator here.

Is there anyone who hit the issue who did NOT have Lotus Notes installed?

Hey @pmonette,

From this forum post:

https://productforums.google.com/forum/#!msg/chrome/sck_PZ4Z7a0/cs8cFciTCgAJ

The only other issue I see is with TurboCAD.  Honestly, I believe this should affect any software that has a MSI based installer that no longer has the sources local to the machine.

We are working! Thank You!

This seems to be resolved now; both on my private computer and the companies computers.
Thank you !

@dyelucky I think it's more complicated than that.

First I still haven't been able to repro the issue. I've been experimenting with 7-zip. I tried just deleting the .msi (confirmed by trying to uninstall the application and getting the "The feature you are trying to use is on a network resource that is unavailable" popup) and causing a reconfiguration by enumerating installed applications using Win32_Product and powershell:

Get-WmiObject -Class Win32_Product -ComputerName .

This does not trigger the popup. In fact, the reconfiguration is skipped for 7-Zip if the .msi is deleted.

This is obviously a simplification, but it doesn't fit the theory that triggering a reconfiguration of all MSI when one of the product doesn't have its .msi available triggers the popup.

Second, another clue is that nothing showed up in the Event Log when the issue was happening, which you pointed out in comment #16. If you trigger a reconfiguration of all the MSIs (using the powershell command above), you will see one entry in the event log per application.

Third, I found this blog https://marcinotorowski.com/2018/03/04/enumerating-installed-msi-products-with-powershell/ that seems to indicate that the API I was using (MsiGetProductInfo()) should avoid the reconfiguration problem of using the Win32_Product class.

Other evidences are pretty weak, but most of the reports are coming for one application (Lotus Note - I know there are some exception) and from enterprise environments (Even though I know some people reported having this on their personal computer).

So I am still stomped on this. I am wondering if some other application/configuration that is common to all the people that reported this issue could be intercepting the MsiGetProductInfo() call and triggering the reconfiguration.

Good find @pmonette!  I'm very curious to see what was ultimately the issue, however for now the issue is resolved.  If I can be of any help to you, going forward, please feel free to reach out to me directly.

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

commit 5b60ccfb7ff6aad6db9c711495d72373378ff660
Author: Patrick Monette <pmonette@chromium.org>
Date: Tue Jul 24 18:32:31 2018

Don't use MsiGetComponentPath()

In some rare circumstances, that function trigger the reconfiguration of
a product, which can open the Windows Installer dialog. It is unknown
yet why this happens because we have no repro, but the fix was verified
with an external user.

Instead look for the path of the component directly in the registry.

Bug:  860537 
Change-Id: Ib1d32a9f8b64f234c20c11d04bb2d825d51f00eb
Reviewed-on: https://chromium-review.googlesource.com/1145821
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577618}
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/base/guid.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/base/guid.h
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/base/win/win_util.h
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/browser/conflicts/installed_applications_win.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/browser/conflicts/installed_applications_win.h
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/browser/conflicts/msi_util_win.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/browser/conflicts/msi_util_win.h
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/installer/setup/setup_main.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/installer/setup/setup_util.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/installer/setup/setup_util.h
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/installer/setup/setup_util_unittest.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/installer/util/install_util.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/installer/util/install_util.h
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/chrome/installer/util/install_util_unittest.cc
[modify] https://crrev.com/5b60ccfb7ff6aad6db9c711495d72373378ff660/tools/metrics/histograms/histograms.xml

Requesting a merge to m69

Also requesting a merge to m68 (pending on the approval to merge to m69)

This is a bug fix for the third-party software warning that we launched in m67 that we turned off because of this bug that happen for some of our enterprise users. We need this in m68 because we're about to turn on the blocking in m69 and we want to have a sufficiently long transition period.

This is a safe merge because the code has been running on canary for the past 2 days and is completely behind a finch flag.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

I support this merge to turn back on the warning, it would be great to get more coverage on the warning! Let me know if you need any other support.

Approving merge to M69 branch 3497 based on comment #122 and #124. Pls merge. Thank you.

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

commit 9814bd27d681718f82f3fa72468d5aa06d74cb14
Author: Patrick Monette <pmonette@chromium.org>
Date: Fri Jul 27 17:25:23 2018

Don't use MsiGetComponentPath()

In some rare circumstances, that function trigger the reconfiguration of
a product, which can open the Windows Installer dialog. It is unknown
yet why this happens because we have no repro, but the fix was verified
with an external user.

Instead look for the path of the component directly in the registry.

Bug:  860537 
Change-Id: Ib1d32a9f8b64f234c20c11d04bb2d825d51f00eb
Reviewed-on: https://chromium-review.googlesource.com/1145821
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#577618}(cherry picked from commit 5b60ccfb7ff6aad6db9c711495d72373378ff660)
Reviewed-on: https://chromium-review.googlesource.com/1153310
Reviewed-by: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#163}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/base/guid.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/base/guid.h
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/base/win/win_util.h
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/browser/conflicts/installed_applications_win.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/browser/conflicts/installed_applications_win.h
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/browser/conflicts/msi_util_win.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/browser/conflicts/msi_util_win.h
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/installer/setup/setup_main.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/installer/setup/setup_util.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/installer/setup/setup_util.h
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/installer/setup/setup_util_unittest.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/installer/util/install_util.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/installer/util/install_util.h
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/chrome/installer/util/install_util_unittest.cc
[modify] https://crrev.com/9814bd27d681718f82f3fa72468d5aa06d74cb14/tools/metrics/histograms/histograms.xml

Approving merge to M68. Branch:3440

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

commit 47bd8174da926bbcde5b1d1d1eab3440240b1c09
Author: Patrick Monette <pmonette@chromium.org>
Date: Fri Jul 27 18:29:10 2018

Don't use MsiGetComponentPath()

In some rare circumstances, that function trigger the reconfiguration of
a product, which can open the Windows Installer dialog. It is unknown
yet why this happens because we have no repro, but the fix was verified
with an external user.

Instead look for the path of the component directly in the registry.

Bug:  860537 
Change-Id: Ib1d32a9f8b64f234c20c11d04bb2d825d51f00eb
Reviewed-on: https://chromium-review.googlesource.com/1145821
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#577618}(cherry picked from commit 5b60ccfb7ff6aad6db9c711495d72373378ff660)
Reviewed-on: https://chromium-review.googlesource.com/1153228
Reviewed-by: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#760}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/base/guid.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/base/guid.h
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/base/win/win_util.h
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/browser/conflicts/installed_applications_win.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/browser/conflicts/installed_applications_win.h
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/browser/conflicts/msi_util_win.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/browser/conflicts/msi_util_win.h
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/installer/setup/setup_main.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/installer/setup/setup_util.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/installer/setup/setup_util.h
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/installer/setup/setup_util_unittest.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/installer/util/install_util.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/installer/util/install_util.h
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/chrome/installer/util/install_util_unittest.cc
[modify] https://crrev.com/47bd8174da926bbcde5b1d1d1eab3440240b1c09/tools/metrics/histograms/histograms.xml

***UI Mass Triage***

If there is no pending work to be done here, please close the issue.