Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Open Settings Folder crashes without the process environment variable and uses the wrong portable path

Open Beginner friendly
#696 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
visualbasic
Domain
desktop

Research direction

Read SettingsPage.xaml.vb and trace how SettingsService selects DataFolder in SettingsService.vb, including portable mode in Application.xaml.vb. Start by comparing the button handler's path with the service's active data folder, then check how failures to open the folder are handled. Done means the button opens the active settings directory in both reported cases and shows a handled error if opening fails.

Written by the indexing model from the issue text.

Description

Tested on official v4.0.0-beta.12, Windows 11 25H2 (26200.9711), ASUS Vivobook S 15 / Snapdragon X Elite X1E-78-100 / 16 GB RAM, .NET 10.0.13. Both the native ARM64 application and the official x64 application were tested directly on this ARM laptop. Additional component checks used unchanged libraries extracted from the x64 release, with the release's embedded manifest. No Intel/AMD PC was tested. Only disposable files were used. Most testing was automated with Codex, with human assistance identified where applicable. Related build request: #556.

The same button has two related problems.

A. Crash when the process has no IridiumIO environment variable

  1. Launch the application from a parent process that lacks IridiumIO.
  2. Open Settings and click Open Settings Folder.

The app exits with:

System.ArgumentNullException: Value cannot be null. (Parameter 'path1')
  at System.IO.Path.Combine(String path1, String path2)
  at CompactGUI.SettingsPage.Button_Click(Object sender, RoutedEventArgs e)

This happened at 01:48:53 and 01:50:27 BST on 21 October 2026. The second reproduction deliberately omitted the variable only from the launched child's environment; no global variable was removed. Application logs and Windows .NET Runtime 1026/Application Error 1000 records corroborate both crashes.

A fresh child given the existing user-scoped value did not crash.

B. Wrong folder in portable mode
With IridiumIO present and the executable in a directory named CompactGUI, active settings are in the adjacent .CompactGUIData directory. The button instead constructs %LOCALAPPDATA%\IridiumIO\CompactGUI. That path did not exist in this setup; Explorer opened Documents instead of the active data folder.

Expected in both cases: open the actual settings directory, with a handled error if opening fails.

Source explanation

Opening ISettingsService.DataFolder.FullName with error handling should address both failures.

x64 component comparison (21 October 2026)

Invoking the actual x64 release's SettingsPage.Button_Click handler with IridiumIO missing only from the test process reproduced the same exception:

System.ArgumentNullException: Value cannot be null. (Parameter 'path1')
  at System.IO.Path.Combine(String path1, String path2)
  at CompactGUI.SettingsPage.Button_Click(Object sender, RoutedEventArgs e)

The harness caught that exception. A subsequent direct GUI test independently confirmed the x64 app crash:

Direct x64 GUI follow-up (21 October 2026, BST)

A fresh official x64 application was launched with IridiumIO omitted only from that child's environment. Clicking Settings -> Open Settings Folder terminated the process at 18:22:52. Windows recorded:

.NET Runtime, event 1026: process terminated due to an unhandled exception
System.ArgumentNullException: Value cannot be null. (Parameter 'path1')
  at System.IO.Path.Combine(String path1, String path2)
  at CompactGUI.SettingsPage.Button_Click(Object sender, RoutedEventArgs e)
Application Error, event 1000: CompactGUI.exe; exception 0xe0434352

The event's executable path matched the isolated official x64 copy, and the process was confirmed exited. This was an actual button click and unhandled application crash, separate from the caught component test.

With the existing environment value present, the portable x64 button opened a new Explorer window titled Documents at about 18:11:38. Its active data directory was the adjacent .CompactGUIData folder, not Documents. Explorer's full address could not be independently read because access to that window was unavailable; the window title, active data directory and handler's constructed path were recorded. The portable misdirection was also directly observed in the earlier ARM64 test.

The existing user-scoped environment variable was left unchanged.

Dominant language
Visual Basic .NET
Stars
8.9k
Forks
343
Avg merge
3d 18h
Merged PRs (30d)
7

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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.

More from IridiumIO/CompactGUI

All issues in IridiumIO/CompactGUI

Similar issues

More Desktop Dev issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.