Rogue Windows_Temp folder created on new RAM FS volume

Thanks for the thorough report - your log excerpts and environment dump helped to pin down this issue.

Short answer: RAM FS isn't creating that folder, and neither is MediaMonkey. Your R:\Windows_Temp is the temp directory used by your Windows service accounts, and it's being pointed at your RAM volume by a system-wide environment variable that is separate from the per-user TEMP/TMP you already reverted.

How we ruled out RAM FS:

We reproduced your exact setup here - same "Create folders" list, fresh volume - and got precisely the twelve folders you configured and nothing else. That matches the code: the driver creates the entries in your list verbatim, character for character (the only thing it changes is accepting a forward slash as well as a backslash as a separator). It has no mechanism to invent a folder, and it never rewrites or substitutes characters in a name - an invalid character produces an error, not a renamed folder.

We also confirmed that the Tools - Set Windows Temporary Folder feature in RAM FS (and its equivalent in RAM Disk) only ever writes the current user's TEMP and TMP. Neither product can set a machine-wide value, so neither could have created this.

Every item in that folder is produced by a process running in session 0 (services), not by your interactive desktop session:

• hsperfdata_AW-SUPERPC$ - a Java process running as LOCAL SYSTEM. The trailing dollar sign is your computer account, which is how a SYSTEM process reports its user name. Java always creates this inside its temp directory, so this alone tells us SYSTEM's TEMP is on R:.
• AW-SUPERPC-*.log and officeclicktorun.exe_streamserver(...).log - the Office ClickToRun service. Your own log excerpt confirms it, showing CommandLine: /service and SecuritySessionId: 0.
• MpCmdRun.log - Windows Defender, running as SYSTEM.
• FXSAPIDebugLogFile.txt and FXSTIFFDebugLogFile.txt - the Windows Fax service, running as NETWORK SERVICE.
• MediaMonkey - MediaMonkey's helper or updater running elevated. It is inheriting the setting, not causing it.

All of these normally live in C:\Windows\Temp. The timestamps fit too: created at 08:50-08:51 (boot, as services start) with later appends through the day from long-running services - not the pattern an interactive application produces.

The output of "set" from your command prompt is the merged result for your logon session, and per-user values override machine-wide ones. Your user TEMP and TMP are correctly R:\Windows\wintemp and R:\Windows\wintmp - which is exactly why the machine-wide value stays hidden from that view. When you reverted TEMP/TMP to the Windows defaults earlier, that was almost certainly the User variables pane; the System variables pane below it still holds the redirection.

To confirm, open an elevated Command Prompt and run:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v TEMP
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v TMP
reg query "HKU\S-1-5-18\Environment" /v TEMP
reg query "HKU\S-1-5-19\Environment" /v TEMP
reg query "HKU\S-1-5-20\Environment" /v TEMP

The defaults are %SystemRoot%\TEMP for the first two, and %USERPROFILE%\AppData\Local\Temp for the last three (SYSTEM, LOCAL SERVICE and NETWORK SERVICE respectively). Whichever one reads R:\Windows_Temp is your culprit. The equivalent in the GUI is System Properties / Advanced / Environment Variables, then the System variables pane at the bottom.

The underscore is most likely just how it was typed when the value was first set - many "move Windows temp to a RAM disk" guides flatten Windows\Temp into a single folder name so it can be created in one step. That would also explain why your second machine doesn't show it: the tweak was only ever applied to this PC. The folder itself then gets created automatically by the first service that needs it, as ClickToRun and Defender both create their temp directory if it is missing.

What you can do:

• Revert it, which is what we'd suggest. Set the system TEMP and TMP back to %SystemRoot%\TEMP - make sure the value type stays REG_EXPAND_SZ - and reboot. The folder will stop reappearing.
• Keep it deliberately. Putting service temp files in RAM is a legitimate tweak. If you go this way, add Windows_Temp to the RAM FS "Create folders" list so the folder reliably exists at mount time. Two things to be aware of: services can start before the volume is mounted, and if the volume ever fails to mount, every service loses its temp directory. It works, but it's worth doing knowingly rather than by accident.

Either way, there is nothing wrong with your RAM FS volume - it is doing exactly what you configured.