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

阅读 SettingsPage.xaml.vb，并追踪 SettingsService 如何在 SettingsService.vb 中选择 DataFolder，包括 Application.xaml.vb 中的便携模式。首先比较按钮处理程序的路径与服务当前使用的数据文件夹，然后检查打开文件夹失败时如何处理。完成标准是：在报告的两种情况下，按钮都能打开当前使用的设置目录，并在打开失败时显示已处理的错误。

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

• SettingsPage.xaml.vb passes the process environment value directly to Path.Combine.
• SettingsViewModel.vb sets the user-scoped value, which does not update the already-running process environment.
• Application portable-mode selection and SettingsService data-folder selection select the real data location.

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.