valinet / valinet/ExplorerPatcher

Windows 10 Start menu is mispositioned across 1080p and 1440p monitors when using fullscreen Start

Open
#5,137 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
33.9k
Forks
1.4k
PR merge metrics
No merged PRs in 30d

Description

Before reporting your issue
  • I have confirmed that this issue does not happen when ExplorerPatcher is not installed
  • I do not have "register as shell extension" enabled
  • I have tried my best to check existing issues
Repro ExplorerPatcher versions

26100.8457.70.3

Repro Windows Versions

Windows 11 25H2 x64

Third-party tweak software installed

TranslucentTB

Describe the bug
Description

I am using a dual-monitor setup with different resolutions:

  • Primary monitor: 2560×1440 (1440p), positioned at the bottom
  • Secondary monitor: 1920×1080 (1080p), positioned above the primary monitor

In ExplorerPatcher, I am using:

Image

There appears to be a monitor positioning/scaling bug when the Windows 10-style Start menu is opened on the secondary 1080p monitor.

Steps to reproduce
  1. Use two monitors with different resolutions:

    • Primary: 2560×1440
    • Secondary: 1920×1080
  2. Position the 1080p secondary monitor above the 1440p primary monitor in Windows display settings.

  3. In ExplorerPatcher, configure:

    • Start menu style: Windows 10
  4. Open Start on the primary 1440p monitor.

  5. Open Start on the secondary 1080p monitor.

  6. Open Start on the primary 1440p monitor again.

ExplorerPatcher configuration
Image

Fullscreen Start is not explicitly forced through ExplorerPatcher.

Screenshots

The attached screenshots show:

  1. The incorrect fullscreen Start menu positioning.
  2. The mixed-resolution dual-monitor arrangement.
  3. ExplorerPatcher's Start menu settings, showing that "Display mode" is set to "Default".
Expected outcome

The Windows 10-style Start menu should calculate its bounds, position, resolution and DPI information independently for the monitor on which it is opened.

For example:

  • Opening Start on the 1080p monitor should fit the 1080p monitor correctly.
  • Opening Start afterwards on the 1440p monitor should fit the 1440p monitor correctly.
  • Opening Start on one monitor should not alter the positioning used when Start is subsequently opened on another monitor.
Actual outcome

When Start is opened on the primary 1440p monitor initially, it is displayed correctly.

When Start is then opened on the secondary 1080p monitor, the fullscreen Start menu is incorrectly positioned. Its bounds/coordinates do not match the secondary monitor correctly.

After opening Start on the secondary monitor, opening Start on the primary 1440p monitor causes the Start menu to be incorrectly positioned there as well.

Opening Start on the primary monitor a second time fixes the primary monitor temporarily.

The issue is consistently reproducible with this sequence:

  1. Open Start on the 1440p primary monitor → correct
  2. Open Start on the 1080p secondary monitor → incorrect / mispositioned
  3. Open Start on the 1440p primary monitor → incorrect / mispositioned
  4. Open Start on the 1440p primary monitor again → correct
  5. Open Start on the 1080p secondary monitor → incorrect again
  6. Open Start on the primary monitor → incorrect again

If I only open Start on the primary 1440p monitor and do not open it on the secondary monitor, the primary monitor continues to work correctly.

The secondary 1080p monitor appears to be consistently affected.

Additional info

I have try disable TranslucentTB, but the problem remain exist

I found similar issue #4959 , but I'm not sure if it's the same bug

FYI, my system language is Chinese

Crash Dumps

No response

Media
Image Image

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the reported sequence with 1440p and 1080p monitors arranged vertically, then trace the Windows 10-style fullscreen Start positioning and monitor/DPI handling entry point. Done means Start independently uses the active monitor’s bounds and DPI, with the sequence working correctly on both displays.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.