Regression: GetTempDir fails under SYSTEM when C:\Windows\SystemTemp is missing (6.5 change to GetTempPath2)

[Gerhard Herbert]

Environment

• Inno Setup 6.5 / 6.5.1

• Windows 10 / 11 and Server 2019 / 2022

• Installer launched from a Windows service (running as SYSTEM)

---

Summary

Since Inno Setup 6.5, GetTempDir internally uses GetTempPath2() (or GetTempPath) instead of reading environment variables manually.
This causes a regression when running under the SYSTEM account on machines where
C:\Windows\SystemTemp does not exist.

In these cases, GetTempPath2() returns "C:\Windows\SystemTemp", and because the new implementation no longer checks for directory existence, Setup attempts to extract itself there and fails immediately with

“Unable to create temporary file”
or similar.

Previous versions (≤ 6.4) performed DirExists checks and fell back to other variables or default paths (e.g. C:\Windows), so the same installers worked correctly.

---

Steps to reproduce

1. Run a SYSTEM shell:

   psexec -i -s cmd.exe

2. Remove the default system temp folder:

   rmdir C:\Windows\SystemTemp /s /q

3. Launch a setup built with Inno Setup 6.5.
   → Setup fails before extraction.

4. Rebuild the same script with 6.4.
   → Setup succeeds.

---

Expected behavior

If the path returned by GetTempPath2()/GetTempPath does not exist or is not writable,
GetTempDir should fall back to the next available temp location (as earlier versions did) or at least attempt to create the directory.

---

Suggested fix

Reintroduce the existence and fallback logic, e.g.:

1. Call GetTempPath2()/GetTempPath().

2. If the directory doesn’t exist, try to create it.

3. If creation fails, fall back to the legacy environment variable search (TEMP, TMP, USERPROFILE, Windows).

That would restore compatibility and reliability when running under non-interactive or restricted accounts.

---

Impact

Installations invoked by system services (e.g. managed software deployment) can no longer start on machines missing C:\Windows\SystemTemp.
This behavior is incompatible with all previous Inno Setup versions.

---

Workaround

Manually create C:\Windows\SystemTemp with SYSTEM permissions, or override the TEMP variable in the service environment.

[Martijn Laan]

Hi,

According to the documentation, C:\Windows\SystemTemp is the correct location. It also notes that the SystemTemp environment variable, if set, takes priority. So if the directory has been deleted but SystemTemp isn’t defined, the resulting error seems like the correct behavior.

Greetings,

Martijn 

-------- Original Message --------

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/12997333-479d-468d-8fd7-b6a44708c1a8n%40googlegroups.com.

[Jordan Russell]

On 10/15/2025 12:22 PM, 'Gerhard Herbert' via innosetup wrote:
> Installations invoked by system services (e.g. managed software deployment)
> can no longer start on machines missing C:\Windows\SystemTemp.

In what real-world scenario is C:\Windows\SystemTemp missing?

If the scenario is just "a crazy person might decide to go out and
delete it" then... I'm not sure that's something we need to be concerned
with. There are 1000 things a user *could* do to their system which
might break Inno Setup installers -- and other apps as well -- but we
don't put in workarounds and fallbacks for each one.

The previous behavior of reading the environment variables manually was
pretty non-standard, and the directory existence checks were
non-standard as well -- only Windows 95/98/Me's GetTempPath had them.

Use of GetTempPath2 is widespread now, and I haven't heard of any
recommendation/necessity to use a combination of GetTempPath2 and
GetTempPath, or GetTempPath2 and environment variables. Path.GetTempPath
in recent .NET versions only uses GetTempPath2 when it is available --
there is no fallback. So presumably any .NET programs that run as SYSTEM
and use Path.GetTempPath will likewise fail with a missing
C:\Windows\SystemTemp. Do we expect every program to include its own
workaround for that?

Note also that the point of using GetTempPath2 and C:\Windows\SystemTemp
over GetTempPath and C:\Windows\Temp is security. C:\Windows\Temp is
world-writable, so unprivileged users can possibly DoS installers or
other programs by creating files/directories with conflicting names, and
more importantly, they can potentially escalate their privileges through
creation of junctions there. Falling back to C:\Windows\Temp when it
might open up a security hole is ultimately not a good thing.

-JR

[Gerhard Herbert]

I agree that the behavior is ok. If some crazy person or application has removed SystemTemp then it should be fixed before running the installer.
However in my testing scenario I used  /SUPPRESSMSGBOXES but the setup was still displaying the message box. If it is executed in session 0 (default for system account) then the installer hangs.

Gerhard.