UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

Steps to reproduce the problem:
Start Chrome via pinned taskbar entries, or Start Menu app-shortcuts ("Add to desktop…")

What is the expected behavior?
The correct profile or app opens.

What went wrong?
The most recently opened profile opens. This is because all shortcuts point to "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" without arguments to specify which profile or app to open.
(I determined this by shift-right-clicking the taskbar entry created by pinning.)

Did this work before? N/A 

Chrome version: 63.0.3239.132  Channel: stable
OS Version: 10.0
Flash Version: 

This bug first occurred on 2017-11-29 (possibly 1 day earlier, I don't think so). I did some debugging on 2017-11-29 (shortcut creation date), then manually renamed my profile folders and "Local State" keys, fixing this issue.

- Note that the "Downloads Router" addon stopped functioning at the same time. Uninstalling and reinstalling the addon fixed it.

It recurred on 2017-‎12-‎22 (shortcut modification date) and I did not fix it immediately.

All subsequent debugging happened on 2018-01-31, over a month later. I closed all chrome.exe processes whenever editing "Local State", but did not log out.

Note that I determined all paths by pinning a profile's Chrome window to taskbar, closing Chrome, and shift+RightClick taskbar icon / Properties. The desktop icons are created on profile creation and don't reflect my renaming shenanigans.

Skip down for the root cause.
------------------

- I created some new app shortcuts from affected profiles. They work normally. Then I unpinned and repinned the entire profile from my taskbar. Taskbar's still broken.

- Unpinning and pinning an "affected" profile produces a broken pin without profile arguments.
- If I create a new profile, pinning works normally.
- I renamed the profile folder ("Profile jimbo1qaz" to "Profile jimbo1qaz~"), then used the titlebar profile switcher to recreate "Profile jimbo1qaz" folder. Opening "Profile jimbo1qaz" and pinning to taskbar produced a broken pin. (I think this bug is independent of profile folder contents.)

- I created a new profile "jimbo3edc" and deleted "Profile jimbo1qaz". Then I changed the key from "Profile 10" to "Profile jimbo1qaz" and deleted the corresponding folder. Pinning this profile is broken. (I think this bug affects specific folder names, not Local State "name" or "shortcut_name")

- I opened "Local State" and reformatted the JSON. In "profile":{"info_cache":, I copied "Profile jimbo1qaz":{...} and pasted it, renaming the key to "shortcut test":{...}. Then I used "mklink /d" to create a symlink alias of "Profile jimbo1qaz" named "shortcut test". Loading and pinning this profile worked normally.
- In "Local State", Ctrl+F searching for Borkeley or Berkeley (a broken profile) generated no results outside of the "Profile Borkeley":{..."name": "Berkeley","shortcut_name": "Berkeley",...} key-value pair. A similar thing happened with a newly created Profile 8 named test2.
- (I think this bug is independent of "Local State" contents.)

- I moved one of my profile folders to "Profile Borkeley". In WSL Bash (zsh), I entered "AppData\Local\Google\Chrome\User Data" and ran "grep -r Borkeley > foo".
- In "Local State", it found "Profile Borkeley":{...}, and "last_used":"Profile Borkeley".
- All other matches occurred within the Profile Borkeley folder, which probably isn't at fault.
- (I think knowledge of which profiles are affected is not stored within Chrome's "User Data" folder.)

- AppData\LocalLow\Google does not exist. AppData\Roaming\Google\Chrome\ contains an empty "User Data" folder only.
- (I cannot think of anything that can reproduce these symptoms.)

Right now, "Profile 8" folder is unaffected. I'm not sure if I magically fixed it during my debugging procedure.

- The shortcut's "Compatibility" tab shows nothing enabled, regardless if it's a broken shortcut.

- <s>I searched HKCU for Profile 5 string. I found nothing but "Computer\HKEY_CURRENT_USER\Software\Google\Chrome\PreferenceMACs\Profile 5" in HKCU and HKLM combined.</s> (barking up the wrong tree)

I repointed my taskbar pinned shortcut at "Profile 5" which hasn't existed in over a month. Right-clicking the taskbar calls it "jimbo1qaz" even though Chrome doesn't call it that.

------------------

I navigated to %AppData%\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\ImplicitAppShortcuts. Running `grep -r "Profile 5"` shows that `Binary file ff13ca23fee04978/jimbo1qaz - Chrome.lnk matches`.

Opening the file in 010 Editor Trial, I found that the icon (and nothing else) points to Profile 5, and the file name (and nothing else) references jimbo1qaz.

.lnk files are stored under ImplicitAppShortcuts\hexadecimal subfolders. Deleting all subfolders fixes this bug.

------------------

Which leaves the question, why did this happen? Is this one of my strange Windows issues that only I seem to get, or a Chrome bug? *Some* program was iterating through my desktop and ImplicitAppShortcuts, and breaking the command-lines of my shortcuts. I haven't found any viruses in the last few months, running Malwarebytes.

(For example, programs take a long time to open, except in Safe Mode. Git Bash takes 10 seconds when I press Enter. Android Studio Installer spawns hundreds of processes looking at HAXM configuration before the installer dialog opens; I had to kill the HAXM configurator to bypass it.