[Bug/Feature Request] Portable versions share Taskbar grouping and icons with other Chromium forks (AUMID / VERSIONINFO conflict on Windows)

[universish]

Preliminary checklist

• I have read the README.
• I have searched the existing issues for my problem. This is a new ticket, NOT a duplicate or related to another open issue.
• I have read the FAQs.
• I have updated Cromite to the latest version. The bug is reproducible on this latest version.
• This is a bug report about the Cromite browser; not the website nor F-Droid nor anything else.

Can the bug be reproduced with corresponding Chromium version?

Yes

Are you sure?

Yes

Cromite version

Version 145.0.7632.120 (Official Build) (64-bit)

Device architecture

x64

Platform version

Windows 11

Android Device model

Is the device rooted?

No

Changed flags

#extensions-menu-access-control Enabled.
#enable-web-app-predictable-app-updating Enabled.
#enable-extension-autoupdate Enabled.
#enable-desktop-pwas-tab-strip-settings Enabled.
#enable-desktop-pwas-sub-apps Enabled.
#enable-desktop-pwas-borderless Enabled.
#enable-desktop-pwas-additional-windowing-controls Enabled.
#use-angle D3D11

Is this bug happening ONLY in an incognito tab?

No

Is this bug caused by the adblocker?

No

Is this bug a crash?

1. No.

Describe the bug

Environment:

OS: Windows 11 Pro (x64) 25H2 26200.8039 Atlas PlayBook v0.5.0
Browsers: Cromite (Portable) and Ungoogled Chromium (Portable)
Installation Type: Standalone/Portable (Unpacked zip, running directly from folder, no standard system installation).
Ungoogled Chromium version: Version 145.0.7632.116 (Official Build, ungoogled-chromium) (64 bit)
Cromite version: Version 145.0.7632.120 (Official Build) (64-bit)

Description:

When using portable versions of different Chromium forks (specifically Cromite and Ungoogled Chromium) on the same Windows machine, Windows treats them as the exact same application. This causes severe taskbar pinning and grouping issues.

Even if they are pinned separately, launching one might cause it to group under the other's taskbar icon, or it spawns a completely new, unpinned icon on the far right of the taskbar. In some cases, Windows cache gets confused and assigns Cromite's green logo and name to Ungoogled Chromium's executable, despite them being in entirely different directories.

Hypotheses for the Root Cause:

Based on extensive troubleshooting, the issue seems to stem from how Chromium forks are compiled and how Windows interprets their identity:

Shared VERSIONINFO Metadata: Both forks likely retain the original Chromium metadata (Company Name, Product Name, etc.) in their compiled chrome.exe. Windows reads the binary metadata and overrides folder paths.

Hardcoded AUMID / Window Class: Both forks likely broadcast the same AppUserModelID or Window Class (e.g., Chrome_WidgetWin_1) to the Windows Desktop Window Manager (DWM).

Portable Mode Limitations: Because they are not formally installed via Registry, Windows relies heavily on the executable's internal metadata, which overlaps between forks.

Steps to reproduce the bug

Troubleshooting Methods Attempted (and why they failed):

I have tried every known Windows workaround to force the system to separate these applications, but all have failed. Here is the list of attempts and the rationale behind them:

Attempt 1: Using --app-user-model-id="CustomID" in shortcuts

Rationale: To force a unique AUMID for each shortcut so Windows taskbar separates them.
Result: Failed. The Chromium engine seems to override the shortcut parameter with its internal hardcoded ID once the Browser Process starts.

Attempt 2: Using --user-data-dir="CustomProfilePath"

Rationale: To ensure the browsers aren't sharing the default AppData\Local\Chromium profile, which would cause them to merge.
Result: Verified they are using completely separate profiles (different folder paths, different theme colors), yet Windows still groups their taskbar icons.

Attempt 3: Renaming chrome.exe to cromite.exe and ungoogled.exe

Rationale: To break the Windows executable-name grouping logic.
Result: Failed. Windows still groups them, proving the grouping relies on binary metadata, not the file name.

Attempt 4: Creating Hardlinks (mklink /H)

Rationale: To create completely isolated executable names without breaking internal relative paths or Chromium's portable integrity.
Result: Failed. Windows still recognizes the underlying binary signature.

Attempt 5: Windows 8 Compatibility Mode

Rationale: A well-known Windows hack; the OS never groups applications running in different compatibility modes.
Result: Failed.

Attempt 6: Launching via chrome_proxy.exe

Rationale: To use a different entry point/binary signature to trick the taskbar.
Result: Failed. The main chrome.exe process still takes over the window grouping.

Attempt 7: Purging IconCache.db, MuiCache in Registry, and Renaming Root Folders

Rationale: Windows started assigning Cromite's name and green logo to Ungoogled Chromium's .exe. Purging the cache and renaming folders fixed the wrong icon display, but the core window grouping issue persists.

Expected behavior

Each portable fork should have a unique internal identifier so Windows taskbar treats them as completely separate applications, keeping their pins, icons, and window groups isolated.

Proposed Solution / Request:

Could the build process be modified to ensure a truly unique AppUserModelID, Window Class, and unique VERSIONINFO metadata for the executable? Alternatively, is there a reliable command-line flag or compiler flag for portable users to explicitly define a unique application identity that Windows will respect?

Screenshots

[cosmobooker]

I had a similar issue with v145 of Cromite. It was not producing a taskbar icon at all when launched. I tried a clean install and even deleted the C:\Users\%USERNAME%\AppData\Local\Cromite folder, but that didn't work. After a reinstall, I did notice that Cromite was hijacking my Ubisoft Connect taskbar icon. When I clicked on the Ubisoft icon, Cromite would open / close. I resolved my issue by going into the registry and deleting this key: HKEY_CURRENT_USER\SOFTWARE\Cromite, however this may result in undesirable data loss. I'm moving from a different browser, so I wasn't worried about losing anything important.

For some background info, I had a copy of Cromite from a year or so ago that I recently did a clean install of for v145 and that's when I noticed the icon issues. Perhaps the issue is related to new files clashing with legacy files / configurations. Good luck!

[universish]

I resolved my issue by going into the registry and deleting this key: HKEY_CURRENT_USER\SOFTWARE\Cromite, however this may result in undesirable data loss. I'm moving from a different browser, so I wasn't worried about losing anything important.

I tried a lot of things in the registry. It didn't work.
I mentioned it here:

Attempt 7: Purging IconCache.db, MuiCache in Registry, and Renaming Root Folders

I tried your method too. It didn’t work. I think the reason it didn’t work is that the executable (exe) file for both is chrome.exe.