mirror of
https://github.com/1Remote/1Remote.git
synced 2026-04-25 13:36:03 +03:00
[GH-ISSUE #1037] Crash report #2741
Labels
No labels
area-configuration
area-ct-app
area-ct-rdp
area-ct-remoteapp
area-ct-ssh
area-ct-vnc
area-launcher
area-list
area-tags
area-teamwork
bug
chore
dependencies
general-build/ci
general-performance
general-refactor
general-security
general-supportive
general-ux
meta-documentation
meta-enhancement
meta-enhancement
meta-feature
meta-help-wanted
meta-unknown-error
priority-hi
priority-low
pull-request
question
resolution-duplicate
resolution-invalid
resolution-wontfix
stale
task-put-off
task-still-considering
task-working-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/1Remote#2741
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @itagagaki on GitHub (Nov 22, 2025).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/1037
Originally assigned to: @VShawn on GitHub.
Unfortunately, the crush at startup still occurs.
Environment
1.3.0-alpha(Built at: 2025-11-21T22:59:34.355+09:00)(EXE Release).NET 9.09.0.11Windows 10 Pro 64-bits 10.0.26200.0 (2009) build 26200Error Info
Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
Stack Trace
Recent Log
@itagagaki commented on GitHub (Nov 24, 2025):
This crash occurs when the program is set to "Run automatically at OS startup (user sign-in, to be precise)".
@itagagaki commented on GitHub (Nov 24, 2025):
This seems to happen in Card View, but not in List View.
@itagagaki commented on GitHub (Nov 24, 2025):
I noticed that the 1Remote is not minimized when its automatic startup.
@VShawn commented on GitHub (Nov 25, 2025):
I haven't used CardView in a long time; let me take a look.
@VShawn commented on GitHub (Nov 25, 2025):
I tried using CardView, and everything worked fine. I still haven't figured out what triggers the bug.
From the logs, it seems that the data source changed during the UI rendering, causing
Index was out of rangeerror. But if that's the case, I should be able to reproduce the bug, which I haven't managed to do yet. The solutions suggested by Copilot AI are getting more and more ridiculous—I’m hope AI will work this time.@itagagaki commented on GitHub (Nov 26, 2025):
Resolved.
I'm not sure of the exact reason, but it seems that an older store version was lingering somewhere and causing some kind of issue.
After uninstalling it and running the latest revision build in portable mode, everything started working fine.
@VShawn commented on GitHub (Nov 26, 2025):
Ah? May I ask if you have set the portable version to read the configuration files or database of the store version located in AppData? As far as I remember, these two versions shouldn’t overlap by default.
By the way, the copilot AI has failed once again.
@itagagaki commented on GitHub (Nov 26, 2025):
No, I don't recall ever sharing a database.
I'm not sure exactly what happened, but the sequence of my experiences was roughly as follows:
I always use in portable mode with the latest build.
I unchecked “Run automatically at OS startup” and tried signing out/signing in.
However, I noticed that 1Remote was still launching.
Checking Task Manager revealed that the binary was from the build folder of the store version within the tree that I had cloned directly from the 1Remote repository, rather than from my own fork.
However, when I launch it directly and looked into the options, the 'Run automatically at OS startup' checkbox was unchecked.
Looking in Windows “Settings > Apps”, I found 1Remote listed (I don't recall installing it, but I must have done so at some point). So I uninstalled it.
Just to be safe, I rebuilt the latest 1Remote code.
Portable mode now works correctly.
@VShawn commented on GitHub (Nov 26, 2025):
okey, based on your helpful info, it seems that the auto-start feature of the store version has been applied to the portable version (since the logs show that the crash occurred on portable version, while the startup information in your Task Manager shows the store version).
And This is strange, as the auto-start mechanisms of the two versions are different, I even think it's impossible. This requires further investigation.
BTW There are many problems with the current store version, especially #937, for which I still haven't found the cause, which is very frustrating.