Unable to reproduce the issue with the steps mentioned below:
1) Launched chrome Stable, Canary and Beta versions and opened chrome Task Manager
2) Able to see the entries of three opened chrome versions with respect to their icons(Stable with normal chrome symbol, Canary with Yellow icon and Beta with Chrome symbol overlaid with Beta name).

@Reporter:
Please find the attached screenshot for your reference and let us know your inputs on it which helps us in further triaging it.

Thanks!

Deleted: 814029.PNG 266 KB

	814029.PNG 266 KB View Download

viswa.karala@ your screenshot confirms the issue: as you can see all three "Google Chrome" entries have the same icon.

Also, you can see the same icon in Windows Explorer if you open the application directories:
  %LocalAppData%\Google\Chrome SxS\Application
  %LocalAppData%\Google\Chrome\Application

Deleted: same-icon.png 110 KB

	same-icon.png 110 KB View Download

I'm not even seeing the different icons in the expanded tree for the individual chrome processes

Thank you for providing more feedback. Adding the requester to the cc list.

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

@Reporter: Could you please let us know what all chrome versions are installed in your system? Also please provide us a screenshot of your task manager where you are not seeing this chrome processes. Further info would help us in triaging the issue in a better way.

Thanks!

current chrome stable and canary

Version 67.0.3368.1 (Official Build) canary (64-bit)
Version 65.0.3325.146 (Official Build) (64-bit)

Deleted: chome duplicates in task manager.jpg 314 KB

	chome duplicates in task manager.jpg 314 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce the issue mentioned in comment#3. All Google entries have default chrome icon as main icon. Hence considering this issue as Non-Regression and marking as Untriaged. Tentatively adding Internals>Installer component. Please remove if not the case.

But not observing issue mentioned in comment#4 and comment#7.

@REporter: From where did you install the latest stable, beta and chromium builds? Try installing from https://www.chromium.org/getting-involved/dev-channel and check the issue.

Thanks!

I don't know that MS has documented exactly how Task Manager picks the icon it shows. I see some mention of setting ICON_SMALL on windows owned by the proc. We could experiment with making sure we consistently set it for all top-level windows we create. Maybe that would help.

grt@ I *guess* it could be using the exe file icon because that seems simple and straightforward. The problem is that chrome.exe has identical default icon on all channels as observed in Windows Explorer, for example.

Yes, the first icon in the file is the standard Chrome icon. This is something that we will not change, as it would require us to pick a channel at build-time rather than at run-time. We may be able to get the desired behavior by taking care to set the icon on Chrome's top-level HWNDs in whatever particular way the Windows Task Manager wants.

Hmm, technically it's possible to register an icon handler for .exe:
https://msdn.microsoft.com/en-us/library/windows/desktop/cc144122(v=vs.85).aspx
It would dynamically show the correct icon when the file path is that of Chrome app.
But that would be an overkill, I guess.

Agreed.

I've just hammered at this to no avail. The MSDN docs for WM_GETICON hint that ICON_SMALL2 is requested to get the "small icon provided by the application". Indeed, I see that Task Manager sends this message to Chrome. I've tried hacking an implementation to return the mode-specific icon for this message, but it doesn't seem to be respected by TM. I'm fairly sure that there's some caching going on, as I need to reboot in order to see changes I make to the main icon in chrome.exe reflected in TM.

Oddly, TM follows the WM_GETICON request for ICON_SMALL2 with one for ICON_SMALL, for which we already serve the mode-specific icon (e.g., the beta icon for beta channel). I also don't see TM respecting this icon, though the screenshots above lead me to believe that it is for the OP. I've even tried installing 66.0.3350.0 to see if it works with that version, and nothing.

Any ideas, Rob? I think it'd be quite convenient to have the right icon shown in TM.

I suspect Task Manager is pulling the first icon in the EXE and showing that. explorer.exe does this as well. 

The most robust way would likely be to actually change the EXE to use a different icon. Would that be possible?

What I'm especially confused by is that I've confirmed (hi windbg!) that TM actually does send WM_GETICON to Chrome and gets an icon back. The screenshots from the OP also show the proper icon being used. I wonder if MS changed something in TM in recent Win10 builds so that it no longer displays the app's small icon. Or maybe it has some stringent requirements on the icon such that it's ignoring the one we return. Do we have a contact at MS who could let us know what TM expects when it sends WM_GETICON?

It's certainly falling back to pulling the first icon from the .exe. Making that channel-specific would mean making per-channel builds of Chrome, which I don't think we want to do. We sorta do this for standalone and enterprise installers, but I think it's good for the mini_installer itself to be channel-agnostic. I don't expect it could modify chrome.exe at install time without breaking the signature on it. :-)

Adding brucedawson@. Is this something we can use for our support channel?

My reading on WM_ICON suggests that WM_ICON is really for surfaces owned by the app (e.g. the Window caption icon, Alt tab, Taskbar, etc.)

As such Chrome does appear correctly in those areas.

There's also the Task Manager icon selection logic here:
https://blogs.msdn.microsoft.com/oldnewthing/20180301-00/?p=98135

But based off of #19, there seems to be more to the story, but I don't know at the moment where we could take this.

I will say in the grouped case, it's likely it's not possible to update that icon. Since HWNDs can present their own icons, Task Manager needs to choose the icon to represent the set of HWNDs. Given this, it likely uses the EXE to represent the group node and provides an opportunity to use the window icons for each individual entry.

On my version of Windows 10 I see both the main entry and the sub entries in Task Manager using the same icon for canary and stable (Chromium is different, but not relevant). procexp also uses the same icon for all. This is on Windows 10 16299. That is, my results match comment #7 not comment #2. I tested on 17134 and I see the same results (stable icons for all Chrome's at all levels).

It would be nice to fix this and it sounds like the only robust way to do this would be to build the binaries separately. This would require either specifying the channel at build time or doing a post-build icon-injection step just before signing the binary. Or, we could build chrome.exe, chrome_canary.exe, chrome_dev.exe, and chrome_beta.exe, sign them all, and copy the appropriate one to chrome.exe at packaging time or at install time. The chrome.exe binary is small enough and links fast enough that the cost to doing this would be trivial. The debug information would record the difference, but that is fine.

This method would even leave a record in ETW traces of which version was being run (there's an original EXE column in the images table).

So, is linking four copies of chrome.exe a plausible option?

I went down this road in https://chromium-review.googlesource.com/c/chromium/src/+/1183489 to see how bad it would be. It's doable, but there didn't seem to be consensus that it's worth the complexity.