Encoding mismatch on Windows Task Scheduler XML file

[guimlherme]

Current Behavior

On the file App.xaml.cs, the RunOnStartup function creates a task in the Windows Task Scheduler via an XML file. The file header suggests that it is encoded in UTF-16.

WinMemoryCleaner/src/App.xaml.cs

Line 641 in a19f257

@"<?xml version=""1.0"" encoding=""UTF-16""?>

But afterwards, the file is created using File.WriteAllText without an encoding specifier, which defaults to UTF-8

WinMemoryCleaner/src/App.xaml.cs

Line 696 in a19f257

File.WriteAllText(tempXmlFile, taskXml);

This is a problem when Path contains a character with different representations in the two encodings, resulting in an invalid task on the scheduler.

Expected Behavior

The task on the Windows Task Scheduler should have the correct path, even if it has special characters.
My guess is that it should be solved when the correct encoding is passed to File.WriteAllText

File.WriteAllText(tempXmlFile, taskXml, Encoding.Unicode);

Steps to Reproduce

1. Install the program in a folder that has a special character in the Path (e.g. "C:\Users\User\Utilitários\WinMemoryCleaner.exe")
2. Activate the Run on Startup function in the program
3. The task on Windows Task Scheduler will have a corrupted path (e.g. "C:\Users\User\Utilitários\WinMemoryCleaner.exe")

App Version

3.0.8

Windows Version

Windows 11

Additional Context

No response

Checklist

• I have searched the existing issues to make sure this bug has not been reported yet.
• I have tested with the latest version of the application.

[IgorMundstein]

Thanks for the detailed investigation and the clear steps to reproduce.

​You hit the nail on the head. The issue is indeed the mismatch between the XML header declaration (UTF-16) and the default encoding of File.WriteAllText (UTF-8). It was a "silent bug" for a while because standard ASCII paths are read identically in both encodings by the Scheduler, but as you noted, it breaks immediately once special characters (like accents) are introduced in the path.

​I will implement the fix by explicitly passing Encoding.Unicode to the file writer to ensure the output matches the XML header. This will be included in the next release.

Tamo junto brazuca! 😆