[Installer Bug] Ryzen AI 1.8.0 installer fails on non-English Windows with `UnicodeEncodeError: 'gbk' codec can't encode character '\ufffd'` in `conda run` (SYSTEM context), causing MSI rollback

[big-stone-p]

Description

The Ryzen AI 1.8.0 installer (ryzen-ai-1.8.0.exe) consistently fails on Chinese Windows (and likely any non-English / non-UTF-8 Windows locale) at the step conda run -n ryzen-ai-1.8.0 set. The command exits with code 1, the installer reports Failed to retrieve conda environment variables., and triggers an MSI rollback — showing "RyzenAI Setup Wizard ended prematurely" and "Your system has not been modified."

This is a 100% reproducible blocker for all Chinese Windows users. The error message gives no hint about the actual encoding problem, making it extremely difficult to diagnose without deep investigation.

Environment

Item	Value
Ryzen AI Software version	1.8.0
Installer	ryzen-ai-1.8.0.exe (MSI-based)
CPU / APU	AMD Ryzen AI 7 350 (Kracken Point / KRK)
NPU driver	kipudrv.inf, installed and working
Operating System	Windows 11 25H2, build 26200.9168
System locale	Chinese (Simplified), console codepage GBK / cp936
Conda distribution	Miniforge3 (clean install, only conda in PATH)
Conda version	26.7.2 (also reproduced on 26.1.1 before upgrade)
Python (inside env)	3.12.11
Install path	C:\Program Files\RyzenAI\1.8.0
Conda env path	C:\ProgramData\miniforge3\envs\ryzen-ai-1.8.0

Steps to Reproduce

Prerequisites

1. Windows 11 with Chinese (Simplified) system locale (GBK console codepage)
2. Miniforge3 installed, with C:\ProgramData\miniforge3\Scripts in system PATH
3. No existing ryzen-ai-1.8.0 conda environment

Reproduction

1. Download ryzen-ai-1.8.0.exe from AMD account portal
2. Right-click → Run as administrator
3. Follow the wizard, accept EULA, keep default env name ryzen-ai-1.8.0
4. Wait for installation to proceed

Expected Result

Installer completes successfully, conda environment is created, all packages are installed, and "Display Conda Info" dialog appears.

Actual Result

Installer proceeds through:

• ✅ APU detection (APU Device: kracken, exit code 0)
• ✅ File deployment (FanOutSharedDlls copying DLLs)
• ✅ Conda env creation (conda env create --file=env.yaml, exit code 0, takes ~4 min)
• ❌ conda run -n ryzen-ai-1.8.0 set → exit code 1
• ❌ Installer reports Failed to retrieve conda environment variables.
• ❌ MSI rollback triggered → "Setup Wizard ended prematurely"

All subsequent steps (pip install RAI wheels, onnxruntime_vitisai wheel, env var config) are never executed.

Key Observation: Manual Run Succeeds, SYSTEM Account Fails

Running the exact same command in a user-level terminal succeeds (exit code 0):

conda run -n ryzen-ai-1.8.0 set

But the MSI installer runs this command as a deferred CustomAction in the SYSTEM account context. Reproducing the SYSTEM account context via a scheduled task reliably crashes:

:: Create a one-time task running as SYSTEM
schtasks /create /tn "CondRunRepro" /tr "cmd /c conda run -n ryzen-ai-1.8.0 set > C:\Temp\system_conda_repro.txt 2>&1" /sc once /st 23:59 /ru SYSTEM /f

:: Run it immediately
schtasks /run /tn "CondRunRepro"

:: Wait ~10 seconds, then inspect the output
type C:\Temp\system_conda_repro.txt

:: Cleanup
schtasks /delete /tn "CondRunRepro" /f

This confirms the failure is specific to the SYSTEM account context, not to conda itself or the environment.

Error Logs

From SYSTEM account reproduction (C:\Temp\system_conda_repro.txt)

# >>>>>>>>>>>>>>>>>>>>>> ERROR REPORT <<<<<<<<<<<<<<<<<<<<<<

    Traceback (most recent call last):
      File "C:\ProgramData\miniforge3\Lib\site-packages\conda\exception_handler.py", line 30, in __call__
        return func(*args, **kwargs)
      File "C:\ProgramData\miniforge3\Lib\site-packages\conda\cli\main.py", line 53, in main_subshell
        exit_code = do_call(args, parser)
      File "C:\ProgramData\miniforge3\Lib\site-packages\conda\cli\conda_argparse.py", line 207, in do_call
        result = getattr(module, func_name)(args, parser)
      File "C:\ProgramData\miniforge3\Lib\site-packages\conda\cli\main_run.py", line 141, in execute
        print(response.stdout, file=sys.stdout, end="")
        ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    UnicodeEncodeError: 'gbk' codec can't encode character '\ufffd' in position 428: illegal multibyte sequence

From installer log (C:\Temp\ryzen_ai_installer_*.log)

[17:41:19.960] Running command: cmd.exe /c cd C:\Program Files\RyzenAI\1.8.0\ & conda env create --file=env.yaml -n ryzen-ai-1.8.0
[17:47:00.263] Command exited with code 0
[17:47:00.266] Running command: cmd.exe /c conda run -n ryzen-ai-1.8.0 set
[17:47:02.332] Command exited with code 1
[17:47:02.332] Failed to retrieve conda environment variables.

(Note: the conda env create takes ~6 minutes and succeeds; the conda run set crashes in ~2 seconds.)

Root Cause Analysis

The crash point

In conda/cli/main_run.py, line 141:

print(response.stdout, file=sys.stdout, end="")

response.stdout is a string containing the full output of the set command (all environment variables dumped). This string contains the Unicode replacement character \ufffd (U+FFFD) at position 428.

Why \ufffd appears in the output

The \ufffd character likely originates from an environment variable whose value contains bytes that were decoded with errors='replace' (or similar) at some earlier stage — for example, a path containing non-ASCII characters (Chinese username, system paths) that got mangled during conda's internal processing. The SYSTEM account has its own set of environment variables (e.g., APPDATA=C:\Windows\system32\config\systemprofile\AppData\Roaming) which may differ from the user account and trigger this mangling.

Why it crashes only on SYSTEM / Chinese Windows

• sys.stdout.encoding on Chinese Windows is GBK (cp936) — both for user terminals and SYSTEM context
• The GBK codec cannot encode \ufffd (U+FFFD is not representable in GBK)
• When print() tries to write the string to a GBK-encoded stdout, it raises UnicodeEncodeError
• This exception is unhandled in conda's main_run.execute(), causing conda to exit with code 1
• The installer interprets non-zero exit as fatal failure and triggers MSI rollback

Why manual user run sometimes succeeds

The user account's terminal may have:

• Windows Terminal with UTF-8 codepage (chcp 65001)
• Different environment variables that don't trigger the \ufffd mangling
• A PYTHONUTF8 or PYTHONIOENCODING setting in the user environment

The SYSTEM account has none of these — it has a fixed GBK console and a fixed environment, making the crash deterministic.

Solutions Already Tried (None Fixed It)

Attempt	Result
Enable LongPathsEnabled=1 in registry	❌ Did not fix (this was a red herring from issue #273)
Remove Anaconda from PATH, keep only Miniforge3	❌ Did not fix (dual-conda was an early issue but not the root cause)
Upgrade conda from 26.1.1 to 26.7.2	❌ Did not fix (bug present in both versions)
Restart Windows	❌ Did not fix
Re-download installer	❌ Did not fix
Run installer as administrator (not SYSTEM)	❌ MSI CustomAction still runs as SYSTEM regardless
Manually run conda run -n ryzen-ai-1.8.0 set in user terminal	✅ Succeeds, but doesn't help because installer runs it as SYSTEM

Confirmed Workaround

Setting the system-level (Machine) environment variable PYTHONUTF8=1 forces Python (and conda) to use UTF-8 for all IO operations, including stdout encoding. This completely resolves the crash.

# Run as Administrator
[Environment]::SetEnvironmentVariable("PYTHONUTF8", "1", "Machine")

Then restart Windows (or at least ensure the installer process inherits the new environment variable), and re-run the installer.

Verification after workaround

With PYTHONUTF8=1 set at Machine level:

1. conda run -n ryzen-ai-1.8.0 set in SYSTEM context exits with code 0 (verified via schtasks reproduction)
2. Installer proceeds past the conda run set step
3. pip install -r requirements.txt succeeds
4. onnxruntime_vitisai and onnxruntime_genai_directml_ryzenai wheels install successfully
5. RYZEN_AI_INSTALLATION_PATH conda env var is set
6. Installer completes with "Display Conda Info" dialog
7. quicktest.py outputs Test Finished — NPU inference works

Important: Must be Machine-level (system environment variable), NOT User-level. The installer runs conda as SYSTEM, which does not read user environment variables.

---

Suggested Fixes

Option 1 (Recommended): Set PYTHONUTF8=1 internally in the installer

The MSI CustomAction that invokes conda commands should set PYTHONUTF8=1 in the child process environment before executing conda run. This is the simplest, most robust fix and requires no changes to conda or user system configuration.

Implementation options:

• Set it as an environment variable in the CustomAction execution context
• Prepend set PYTHONUTF8=1 && to the conda command (cmd.exe)
• Use Environment.SetEnvironmentVariable("PYTHONUTF8", "1", EnvironmentVariableTarget.Process) in the installer code before spawning conda

Option 2: Use conda run --no-capture-output or redirect to file

Instead of relying on conda's print() to write to the console (which inherits the system codepage), redirect output to a file with explicit UTF-8 encoding and parse it:

conda run -n ryzen-ai-1.8.0 set > "%TEMP%\conda_env_vars.txt" 2>&1

Then read the file with UTF-8 encoding in the installer. This avoids the console codepage entirely.

Option 3: Wrap conda calls with encoding-safe error handling

Catch UnicodeEncodeError around conda output handling and fall back to errors='replace' or errors='ignore' when writing to stdout.

Option 4 (Minimum): Document the requirement

At minimum, add a prominent note in the installation guide (https://ryzenai.docs.amd.com/en/latest/inst.html) that non-English Windows users must set PYTHONUTF8=1 before installation. Currently there is no mention of this requirement anywhere.

Related Issue: quicktest.py Has the Same Encoding Bug

After working around the installer issue and completing installation, running the official quicktest.py on Chinese Windows also crashes:

File "C:\Program Files\RyzenAI\1.8.0\quicktest\quicktest.py", line 21, in get_npu_info
    if "PCI\\VEN_1022&DEV_1502&REV_00" in stdout.decode():
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbf in position 158: invalid start byte

Root cause: quicktest.py runs pnputil /enum-devices /bus PCI via subprocess.Popen and calls stdout.decode() with default UTF-8 encoding. On Chinese Windows, pnputil outputs GBK-encoded text containing bytes like 0xbf that are invalid UTF-8.

Affected lines: 21, 23, 25, 27, 29 (all 5 occurrences of stdout.decode() in get_npu_info()).

Fix: Replace stdout.decode() with stdout.decode('utf-8', errors='ignore'). The PCI hardware IDs being matched (VEN_1022&DEV_XXXX) are pure ASCII, so ignoring undecodable bytes does not affect NPU detection at all.

This should be a trivial one-line fix (×5) in the next release.

Additional Note: pip Download Timeout in China

Not strictly an encoding bug, but related to the SYSTEM context issue: the installer runs pip install -r requirements.txt which downloads from files.pythonhosted.org. In China this frequently times out with ReadTimeoutError. Since the installer runs pip as SYSTEM, user-level pip.ini mirror configuration is not picked up.

Workaround: set system-level environment variables:

[Environment]::SetEnvironmentVariable("PIP_INDEX_URL", "https://pypi.tuna.tsinghua.edu.cn/simple", "Machine")
[Environment]::SetEnvironmentVariable("PIP_DEFAULT_TIMEOUT", "120", "Machine")

It would be helpful if the installer either:

• Allowed users to configure a pip mirror URL during installation
• Automatically detected slow PyPI connections and suggested a mirror
• Documented this requirement for users in regions with poor PyPI connectivity