Rogue Windows_Temp folder on RAM FS volume

I am seeing a minor oddity with a new install of RAM File System, after previously using RAM Disk: a rogue Windows_Temp folder created and populated with temp files on the new RAM FS volume.

Based on the info below, I wonder if you have suggestions/thoughts regarding what/why is creating this rogue folder and filling it with temp files that should instead be in the designated TEMP or TMP folders?


First, I copied all the relevant settings from RAM Disk to RAM FS (specifically the "Create folders" list). Then reverted the TEMP/TMP directories to Windows defaults, used the Cache Relocator app to set all browser caches to default, deleted the R: volume in the RAM Disk app, and rebooted. All seemed fine.

Then, I used the newly installed RAM FS v26.7.1 to set up a new volume (also R:) with the same folders, same browser redirects and same TEMP/TMP redirects, and rebooted again. Things looked OK. RAM Disk v26.7 is still on my Win10 PC, but it no longer creates any volumes (empty pane) so it shouldn't be in play.

RAM FS "Create folders" list:
Browser_caches\Brave
Browser_caches\Chrome
Browser_caches\Firefox
Browser_caches\Edge
Browser_caches\Opera
Windows\wintemp
Windows\wintmp
Microsoft_search_index
Everything_database
CloneDVDTemp
DVDFab\Temp
DVDFab\Output

In RAM FS, under Tools - Set Windows Temporary Folder..., matching the set environment variable values:
TEMP => R:\Windows\wintemp
TMP => R:\Windows\wintmp

When I look at the new RAM FS-created volume and directories, everything is as expected, but there's an additional "Windows _Temp" directory that appears to contain some temp files from something. I don't recall seeing this when I was using RAM Disk and I don't see it on my second machine now also running RAM FS; RAM FS probably isn't doing this. It seems that something else is creating that R:\Windows_Temp folder for a legitimate temp-file reason, but I can't figure out what & why.

MediaMonkey is installed & running + I just updated it. But I don't see anything configured in that program to use any R: temp area.

R:\>dir
Volume in drive R is RAMDisk

Directory of R:\

07/28/2026 08:50 AM <DIR> Browser_caches
07/28/2026 08:50 AM <DIR> Windows
07/28/2026 08:50 AM <DIR> Microsoft_search_index
07/28/2026 08:50 AM <DIR> Everything_database
07/28/2026 08:50 AM <DIR> CloneDVDTemp
07/28/2026 08:50 AM <DIR> DVDFab
07/28/2026 08:50 AM <DIR> Windows_Temp ==> what is creating this? It has some temp files also.
0 File(s) 0 bytes
7 Dir(s) 14,794,653,696 bytes free

R:\>cd Windows

R:\Windows>dir
Volume in drive R is RAMDisk

Directory of R:\Windows

07/28/2026 08:50 AM <DIR> .
07/28/2026 08:50 AM <DIR> ..
07/28/2026 08:50 AM <DIR> wintemp == this has some Windows-created temp files
07/28/2026 08:50 AM <DIR> wintmp == this has some Windows-created temp files
0 File(s) 0 bytes
4 Dir(s) 14,794,653,696 bytes free

R:\>cd Windows_Temp

R:\Windows_Temp>dir
Volume in drive R is RAMDisk

Directory of R:\Windows_Temp

07/28/2026 08:50 AM <DIR> .
07/28/2026 08:50 AM <DIR> ..
07/28/2026 08:50 AM <DIR> hsperfdata_AW-SUPERPC$
07/28/2026 08:50 AM 0 officeclicktorun.exe_streamserver(202607280850591838).log
07/28/2026 08:50 AM <DIR> MediaMonkey
07/28/2026 08:50 AM 53 bb3a785178f443fda931098a5a9a306b.db.ses
07/28/2026 08:51 AM 0 FXSTIFFDebugLogFile.txt
07/28/2026 08:51 AM 0 FXSAPIDebugLogFile.txt
07/28/2026 10:43 AM 12,654 MpCmdRun.log
07/28/2026 01:47 PM 169,384 AW-SUPERPC-20260728-0851.log
07/28/2026 08:55 AM 135,682 AW-SUPERPC-20260728-0855.log
07/28/2026 09:14 AM 137,146 AW-SUPERPC-20260728-0914.log
07/28/2026 10:38 AM 136,754 AW-SUPERPC-20260728-1038.log
07/28/2026 02:02 PM 137,148 AW-SUPERPC-20260728-1402.log
10 File(s) 728,821 bytes
4 Dir(s) 14,794,653,696 bytes free

Contents of the log file (PC name is 'AW_SUPERPC') : [AW-SUPERPC-20260728-0851.log]
Environment variables on this PC from C:\WINDOWS\system32>set : [env_list.txt]

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.