Repository navigation
RangeSelector: Making the maximum and minimum values the same crashes the system #867
Description
Describe the bug
The system crashes when the maximum and minimum values are set to the same value
In some cases, Ctrl+Alt+Del may be delayed before the security options appear
Steps to reproduce
1. Go to the RangeSelector page
2. Make the maximum and minimum values the same via slider (like max=0, min=0)
It may take 0-5 seconds for the system to crash
Expected behavior
The app handles it correctly and does not crash
Screenshots
Code Platform
- UWP
- WinAppSDK / WinUI 3
- Web Assembly (WASM)
- Android
- iOS
- MacOS
- Linux / GTK
Windows Build Number
- Windows 10 1809 (Build 17763)
- Windows 10 1903 (Build 18362)
- Windows 10 1909 (Build 18363)
- Windows 10 2004 (Build 19041)
- Windows 10 20H2 (Build 19042)
- Windows 10 21H1 (Build 19043)
- Windows 10 21H2 (Build 19044)
- Windows 10 22H2 (Build 19045)
- Windows 11 21H2 (Build 22000)
- Windows 11 22H2 (Build 22621)
- Windows 11 23H2 (Build 22631)
- Windows 11 24H2 (Build 26100)
- Windows 11 25H2 (Build 26200)
- Windows 11 26H1 (Build 28000)
- Other (specify)
Other Windows Build number
No response
App minimum and target SDK version
- Windows 10, version 1809 (Build 17763)
- Windows 10, version 1903 (Build 18362)
- Windows 10, version 1909 (Build 18363)
- Windows 10, version 2004 (Build 19041)
- Windows 10, version 2104 (Build 20348)
- Windows 11, version 22H2 (Build 22000)
- Windows 11, version 24H2 (Build 26100)
- Windows 11, version 25H2 (Build 26200)
- Windows 11, version 26H1 (Build 28000)
- Other (specify)
Other SDK version
No response
Visual Studio Version
2026
Visual Studio Build Number
No response
Device form factor
No response
Additional context
Surface Pro 11 (ARM64)
Help us help you
No, I'm unable to contribute a solution.
Activity
Illustar0 commentedon Jul 31, 2026
Looks like a duplicate of #366?
Ix3WUhpgTPE commentedon Aug 25, 2026
Forcing the minimum and maximum to identical values through the slider, as in max=0 and min=0, causes the reported crash after a variable delay. The problem is likely exposed when the control recalculates its visual elements or selection bounds based on those properties. Implementing a check to treat equal min/max as a special case, such as hiding the range indicator, would align with the expected behavior of not crashing. Could the issue be reproduced more reliably by setting the values directly in code instead of via the UI?
brokendenim commentedon Sep 23, 2026
This is likely a division-by-zero error in the thumb position calculation where it divides by `max - min
tediousservi commentedon Sep 28, 2026
The 0–5 second delay strongly suggests the crash occurs during an asynchronous layout or render pass when recalculating track
tanaysiabobette26 commentedon Oct 11, 2026
To prevent the floating-point exception during the layout pass, we should also verify if the RangeSelector's internal normalization logic handles a zero-width range before it reaches the UI thread. Does the current implementation enforce a minimum delta between thumbs, or does it attempt to calculate a relative percentage that results in
NaNwhenmax - minis zero?rickiajordyan26 commentedon Oct 15, 2026
If this is indeed a divide-by-zero error, check if the RangeSelector layout pass is also failing to handle the resulting NaN propagate to the dependency properties during the measure/arrange cycle.