The "Same PC" Is Not the Same Execution Environment — The User Boundary That Separates AppData, HKCU, DPAPI, and Credentials

The app reads its configuration file when launched from File Explorer, but Task Scheduler reports it “not found.” Turn it into a service and it can no longer decrypt the saved password. The browser on your desk is signed in, but in CI it lands back on the login screen.

With this kind of problem, check who the program is running as, and how before you look at the code. Files and settings that exist on the same PC cannot necessarily be used in the same way from a different execution user.

The question this article answers is why an app breaks when nothing in the code changed and it was merely turned into a scheduled task, a service, or a CI job. If you want to start from the symptom, go to the section that matches in the following table.

Assumptions of This Article

1. The Bottom Line First

The basic unit that partitions a Windows execution environment is not the PC but the access token and the SID, that is, “who the process is running as.” AppData, HKCU, DPAPI keys, browser profiles, and credentials belong to that user’s environment.

The settings and sign-in state you prepared under your own interactive logon are not carried over automatically to SYSTEM or to another service account. The areas for machine-wide data are ProgramData and HKLM, and sharing through them still requires you to design the access rights.

flowchart TB
    accTitle: Two worlds inside the same PC
    accDescr: The same PC shares only HKLM and ProgramData, while the world of your SID and the world of another SID each have their own AppData, registry hive, and DPAPI keys, invisible to each other across the user boundary
    pc["Same PC"] --> shared["Shared: HKLM and ProgramData"]
    pc --> wa["The world of your SID"]
    pc --> wb["The world of another SID (SYSTEM etc.)"]
    wa --> ra["AppData, HKCU, DPAPI keys"]
    wb --> rb["Other AppData, other hive, other keys"]
    ra -.-|"User boundary: invisible to each other"| rb

Figure 1: On the same PC, a different execution user means different AppData, a different registry, and different keys.

That said, the same SID does not guarantee the same environment either. Also check the task’s logon type, IIS profile loading, and the difference in logon session that UAC elevation creates. Elevating within the same account does not turn HKCU or the vault into another user’s; what matters is to think separately about which boundaries change.

The rest of the article proceeds in this order: the execution user as the premise (Chapter 2), the five boundaries (Chapters 3 to 7), the check per execution form (Chapter 8), and design and investigation (Chapter 9).

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (33 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Premise: “Who It Runs As” Decides Everything

2.1 Check the SID and the Token, Not the User Name

The ID that Windows uses to identify a user is not the user name but the SID (security identifier). A process holds an access token, and the token contains the SID of the execution user. This execution principal is the starting point whenever you reason about file ACL checks, the physical registry behind an alias, or encryption keys.

Use whoami /user for the first check. Confirm the result in the execution environment where the problem occurs, not in your own terminal.

> whoami /user

USER INFORMATION
----------------

User Name       SID
=============== =============================================
desktop\you     S-1-5-21-3623811015-3361044348-30300820-1001

C:\Users\you is the on-disk form of the user profile tied to that SID. A profile consists of a set of folders such as AppData and the user registry hive NTUSER.DAT. Because it is copied from the default profile at first logon, another user’s profile starts from an initial state that is separate from the environment you configured.¹

flowchart TB
    accTitle: From launch path to profile
    accDescr: Whether launched by double-click, Task Scheduler, or a service or IIS, the process holds the SID in its access token, and the set of user profile data tied to that SID becomes its execution environment
    e1["Double-click"] --> tok["Process token (SID)"]
    e2["Task Scheduler"] --> tok
    e3["Service or IIS"] --> tok
    tok --> prof["Profile set tied to the SID"]
    prof -.-> note["A different SID means a different, initial-state profile"]

Figure 2: The path by which a process is launched decides which SID’s profile it carries while it runs.

2.2 Service Accounts Each Have an Environment of Their Own

Windows has built-in accounts that run without a human logging on. Each of them has an independent execution environment.²

The difference between the launch paths of a double-click, Task Scheduler, a service, and IIS becomes a difference in whose environment is used. Do not assume that the settings, keys, and credentials you prepared under your interactive logon exist at that execution destination as well.

2.3 Three Conditions to Check After “the Same User”

Do not stop at checking the SID; use these three to sort out what differs even with the same account. Tasks are covered in detail in Chapter 8, IIS in Chapters 4 and 5, and elevation in Chapter 7.

3. Boundary 1: AppData — The Same Environment Variable Points to a Different Place

The typical symptom is that the configuration file stops being found the moment the app becomes a scheduled task. Path resolution has not failed; the path may have resolved correctly to another user’s location, where the file does not exist.

3.1 The Divisions of AppData and How the Execution User Changes Them

AppData is a folder under the user profile. Its purposes are divided as follows.¹⁰

Even when the same code opens %APPDATA%, the location it refers to changes with the execution user.

The file that user A saved does not exist on the SYSTEM side. An error that only says the configuration file is missing does not make this obvious, so during the investigation look at the actual path that was opened, not the name of the environment variable.

flowchart TB
    accTitle: How %APPDATA% resolves depends on the user
    accDescr: Even when the same code opens %APPDATA%, it resolves to a path under C:\Users if the execution user is you and under systemprofile if it is SYSTEM, and your configuration file does not exist in the latter
    code["Same code: open %APPDATA%"] --> q{"Execution user?"}
    q -->|"You"| a["C:\Users\you\AppData\Roaming"]
    q -->|"SYSTEM"| b["AppData under systemprofile"]
    b -.-> miss["The file you put there is missing"]

Figure 3: Environment variables do not lie, but where they resolve depends on the token.

3.2 PATH Also Differs per User

System environment variables are shared by the whole machine, but user environment variables are per user. When a command you added to your own PATH cannot be found from a service, check this difference too.

Decide the storage location by who reads the data. Settings for that user alone go under AppData; data shared by all users or by services goes under %ProgramData%, and for the latter you design the ACLs. For a detailed way to choose, see “How to Choose Where a Windows App Stores Local Data”.

flowchart TB
    accTitle: Choose the storage location by its readers
    accDescr: Data that only that user reads goes in AppData or HKCU, data shared with all users or services goes in ProgramData or HKLM, and the latter comes with ACL design
    q{"Who reads this data?"} -->|"Only that user"| f1["AppData, HKCU"]
    q -->|"All users, services"| f2["ProgramData, HKLM"]
    f1 -.-> w1["Reconsider if it may become a service"]
    f2 -.-> w2["Design write permissions and ACLs"]

Figure 4: “It cannot read it once it became a service” is the result of skipping this branch at design time.

4. Boundary 2: HKCU — “Current User” Changes with the Caller

The typical symptom is that a service cannot find the license information an installer wrote. Even when both the write and the read went to something named HKCU, they are not necessarily the same physical hive.

4.1 HKCU Is an Alias for the User’s Hive

HKEY_CURRENT_USER (HKCU) is not an independent hive; it is an alias that is redirected to a physical location according to the calling user. In an ordinary user process it points to that SID’s key under HKEY_USERS. Its contents are the NTUSER.DAT loaded at logon.¹

The exception is HKCU\Software\Classes, whose physical location is a separate hive file, UsrClass.dat. That file lives under %LOCALAPPDATA%\Microsoft\Windows.¹¹

The HKCU of LocalSystem is associated with the default user (HKEY_USERS\.DEFAULT). When an installer running under an administrator account writes to HKCU and a SYSTEM service reads from HKCU, the two refer to different places.³

flowchart TB
    accTitle: What the HKCU alias really is
    accDescr: When an app opens HKCU, it is redirected to your SID key under HKEY_USERS in your process and to the default user's key in a LocalSystem process, so the value the installer wrote is no longer visible
    app["App code: open HKCU"] --> alias["HKCU is an alias for the real key"]
    alias -->|"Your process"| ha["Your SID under HKEY_USERS"]
    alias -->|"SYSTEM process"| hd["HKEY_USERS\.DEFAULT"]
    hd -.-> gone["The value you wrote does not exist"]

Figure 5: Even under the same name HKCU, a different user means a different hive is read and written.

Put machine-wide settings in HKLM. Microsoft does not recommend accessing HKCU from a service. If you need to read a user’s settings, impersonate that user and then use RegOpenCurrentUser.¹²

4.2 Also Check Whether the Profile Is Loaded

Beyond the execution account, whether the profile is loaded can also be the problem.

IIS application pools run without loading a user profile by default. Enabling loadUserProfile makes AppData and the hive under the profile available.⁷ This setting also affects where the DPAPI and ASP.NET Core Data Protection keys of the next chapter are stored.

The task setting “Do not store password” is checked separately, as a logon-type constraint. Even with the same user specified, an S4U logon cannot use the network or EFS. The concrete differences between configurations are summarized in Chapter 8.⁶

5. Boundary 3: DPAPI — The Encryption Is Locked with “the User’s Key”

Whereas AppData and HKCU are problems of looking in a different place, DPAPI produces a problem where the file can be read but its contents cannot be decrypted. Turning an app that uses a saved password into a service and getting a CryptographicException is one example.

5.1 A Different Master Key Owner Means No Decryption

DPAPI (Data Protection API) is the encryption facility that Windows provides to applications. Calling CryptProtectData or .NET’s ProtectedData.Protect lets an app protect data without carrying an encryption key around in its own code.¹³

That does not make the key unnecessary, though. DPAPI uses a master key managed by the OS. In the CurrentUser scope, a randomly generated per-user master key is protected with a key derived from the logon credentials and stored under the profile.¹⁴

flowchart TB
    accTitle: The DPAPI key chain
    accDescr: The randomly generated user master key is protected by a key derived from the logon credentials, that master key encrypts the app's secrets, and another user's master key cannot decrypt the same ciphertext
    pwd["Logon credentials"] -->|"Protects via derived key"| mk["Your master key"]
    mk -->|"Encrypts"| sec["App secret (saved password etc.)"]
    mk2["Another user's master key"] -.->|"Cannot decrypt"| sec
    mk -.-> loc["Stored under the profile"]

Figure 6: Data is not encrypted directly from the credentials; a key derived from the credentials protects the master key.

Next is a minimal example in which user A encrypts data, places it in a shared location, and a different user tries to decrypt it. Sharing the storage location does not change who can decrypt under CurrentUser.

# In user A's session: encrypt in the CurrentUser scope and save to a shared location
Add-Type -AssemblyName System.Security
$bytes = [Text.Encoding]::UTF8.GetBytes("secret")
$enc = [Security.Cryptography.ProtectedData]::Protect($bytes, $null, "CurrentUser")
[Convert]::ToBase64String($enc) | Set-Content C:\ProgramData\demo.bin

# As a different user (for example, after becoming SYSTEM with PsExec), try to decrypt
$enc = [Convert]::FromBase64String((Get-Content C:\ProgramData\demo.bin))
[Security.Cryptography.ProtectedData]::Unprotect($enc, $null, "CurrentUser")
# → CryptographicException: Key not valid for use in specified state.

5.2 Choose the Scope from Who Should Be Able to Decrypt

A secret that both a service and the interactive user read should be designed from the start as LocalMachine combined with a file ACL, or the process should run under the account of the person who encrypted it. Do not change the scope merely to make the decryption error go away; decide who is allowed to decrypt. On shared machines, also be aware of the risk that machine-level protection is too broad.¹⁵

flowchart TB
    accTitle: How to choose the DPAPI scope
    accDescr: Choose the CurrentUser scope if only that user should be able to decrypt and the LocalMachine scope if several principals on the same PC should, and restrict readers of the latter with a file ACL
    q{"Who should be able to decrypt?"} -->|"Only that user"| cu["CurrentUser scope"]
    q -->|"Several principals on the same PC"| lm["LocalMachine scope"]
    cu -.-> r1["Decryption fails when run as another user"]
    lm -.-> r2["Restrict readers with a file ACL"]

Figure 7: Choose the scope as a design decision about who decrypts, not as “whichever happened to work.”

5.3 A Password “Change” and a “Reset” Are Different

The key that guards the master key depends on the logon credentials. When users change their own password, the master key is re-protected with a key derived from the new password, and the ability to decrypt carries over.

By contrast, when an administrator resets the password of a local account, past ciphertext may no longer be decryptable. Even with the same account, you need to check how the credentials were changed.¹⁴

5.4 Check Where the Keys Are Stored in ASP.NET Core Too

Even code that never calls DPAPI directly can depend on this boundary. ASP.NET Core Data Protection stores the key ring used to protect cookie authentication and the like in a location that depends on the environment.¹⁶

Check loadUserProfile, setProfileEnvironment, and the hosting model as a set, and understand which configuration decides where the keys are placed. What matters is not just that the app starts, but whether it can use the same keys after a restart.

Scope selection and when to use Credential Manager instead are covered in detail in “Storing Secrets in Windows Apps - Avoiding Plaintext Configuration with DPAPI”.

6. Boundary 4: Browser Profiles — “Signed In” Belongs to the User

Signed in on your desk, yet when CI launches the browser it is back at the login screen. This problem becomes tractable once you separate where the profile is stored from the encryption key.

6.1 There Are Two Boundaries: Storage Location and Key

The profile of a Chromium-based browser such as Chrome or Edge lives by default in the User Data folder under %LOCALAPPDATA%. History, cookies, extensions, saved passwords, and so on belong to that Windows user’s environment.¹⁷

Cookies and saved passwords are encrypted with an encryption key inside the profile, and that key itself is protected by DPAPI. Copying the folder to another user or another machine therefore fails to decrypt because the key does not match.

Recent Chrome layers App-Bound Encryption on top of this. Key decryption goes through a service running with SYSTEM privileges, which verifies not only the user but also the identity of the requesting app.¹⁸ This applies to Chromium-based browsers; the situation differs for browsers such as Firefox that have their own profile protection.

flowchart TB
    accTitle: The two boundaries behind a browser's sign-in state
    accDescr: The browser profile lives under LOCALAPPDATA and belongs to boundary 1, and the cookie encryption key is protected by DPAPI and belongs to boundary 3, so neither the profile nor the key carries over to another user
    prof["Browser profile"] --> loc["Stored under LOCALAPPDATA"]
    prof --> key["Cookie encryption key protected by DPAPI"]
    loc -.-> ci["CI's execution user gets an empty, separate profile"]
    key -.-> copy["Cannot be carried out by copying the folder"]

Figure 8: “Taking the signed-in state with you” is blocked by both boundary 1 and boundary 3.

6.2 In Automation, Make the Way Sign-In State Is Created Explicit

Selenium and Playwright launch with a throwaway temporary profile by default. So even under the same user, the sign-in state of your everyday browser is not used automatically.

Even if you specify a persistent profile directory, the storage-location and key problems of the previous section remain the moment you move to a CI job or a service under a different user. The remedy is not to copy a signed-in profile but one of the following.

• Code the sign-in steps for a test account.
• Use the automation tool’s storage-state mechanism to save and restore cookies and the like explicitly.

That another user cannot use the cookies with a mere copy is not an inconvenience; it is also a security boundary. Design the automation on the premise that this boundary exists.

7. Boundary 5: Credentials and Certificates — Each User Has a Separate Vault

Credentials saved with cmdkey are not used when the task runs, and authentication fails. Here too, check not “it was saved on the PC” but “which user it was saved as.”

7.1 Credential Manager Is a Vault per Execution User

Credential Manager, which you can inspect with cmdkey /list, is a per-user vault.¹⁹ Saved credentials are on disk, but they are protected by DPAPI and used by programs running as that user.²⁰

The vault holds saved credentials for file servers and network drives, Git tokens saved by git-credential-manager, saved passwords for RDP connections, secrets of apps that use the Credential API, and so on.

Being in the vault of your interactive logon does not put them in the vault of the account that runs the service or task. Prepare a setup step that enters the required credentials in the context of the execution account itself. When only the git pull on your own desk succeeds, check the difference in vaults as well.

However, a task configured with S4U is not fixed by merely entering credentials. First check the logon type, and consider a configuration that stores the password or a switch to a service account. The order of steps is laid out in Chapter 8.

flowchart TB
    accTitle: The credential vault is per user
    accDescr: Your vault holds Git credentials, saved credentials for file servers, and RDP passwords, but the vault of the service execution user is empty unless credentials are entered, and that is what the authentication error really is
    you["Your vault"] --> g["Git credentials"]
    you --> n["Saved credentials for file servers"]
    you --> r["Saved RDP passwords"]
    svc["Service execution user's vault"] -.-> empty["Empty unless entered = the real authentication error"]

Figure 9: “Authentication works on my machine” is only shorthand for “my vault is available.”

7.2 For Certificates, Check the Store and the Private-Key Permissions Separately

For a certificate used by a service, the basic design is the LocalMachine store together with the ACL on the private key.²¹ The user store physically lives under HKCU\Software\Microsoft\SystemCertificates, so it sits inside the HKCU boundary.²²

For details, see “The Windows Certificate Store in Practice — User or Computer, Which Should You Use?”.

7.3 With UAC Elevation, Separate “the Same Account” from “a Different Account”

When an administrator user logs on with UAC enabled, two linked tokens are created: a standard token with restricted privileges and a full administrator token.⁸

Network drive mappings are per logon session. Z: may be visible in File Explorer yet invisible to a tool run as administrator.⁹

Do not assume that every “it stops working when elevated” is a change of user; first check whether it is the same account.

flowchart TB
    accTitle: The split within one user created by UAC elevation
    accDescr: A UAC-enabled administrator logon creates two tokens, a standard token and an elevated token, and a network drive mapped on the standard token side is not visible to a process running with the elevated token
    logon["Administrator user logon"] --> t1["Standard token"]
    logon --> t2["Elevated token"]
    t1 --> d1["Z: drive mapped here"]
    t2 -.->|"Separate logon session"| d2["Elevated tool cannot see Z:"]

Figure 10: Elevation creates “another world for the same user.” The boundary is not only about the SID.

8. Checklist by Execution Form

8.1 For Tasks, Look at the Logon Type After the Execution Account

In Task Scheduler, what is available changes with the logon type even when the same user is specified.⁶

When a task cannot use saved credentials, first check the S4U constraint. Do not make adding credentials to the vault while staying on S4U your fix. Consider a configuration that stores the password or a switch to a service account, and only then, if still needed, enter credentials into the execution account’s vault.

The details of the settings are covered in “When Task Scheduler Tasks Don’t Run or Exit with 0x1”.

flowchart TB
    accTitle: The task logon type as a second axis
    accDescr: A Task Scheduler execution configuration has a logon type of interactive token, stored password, or S4U, and with S4U the password is not stored and the network and EFS cannot be accessed
    task["Task execution configuration"] --> lt{"Logon type"}
    lt -->|"Interactive token"| it["Runs in the logged-on session"]
    lt -->|"Stored password"| pw["Credentials usable even non-interactively"]
    lt -->|"S4U (password not stored)"| s4u["Cannot reach the network or EFS"]

Figure 11: Even with the same execution user, how it was logged on changes what is available.

8.2 The Inspection Table Before Changing the Execution Destination

The last row is a caution in the opposite direction. Multiple RDP sessions of the same user do not give each session its own independent AppData and HKCU. Here the problem is not that something is invisible, but that the same thing is shared and written to.

9. Guidelines for Design and Troubleshooting

9.1 Decide Storage Locations and Setup from the Principal That Uses Them

If you plan to turn the app into a service later, include that execution principal among the readers at the stage when you decide where to store things. The principle is not to carry a dependency on “whatever happened to exist in the developer’s environment” into operations.

9.2 Investigate from the Execution Principal to the Actual Referenced Location

flowchart TB
    accTitle: Investigation procedure for user-boundary trouble
    accDescr: Confirm the execution user with whoami, look at the token in Process Explorer, identify the paths and registry keys actually read with Process Monitor, and if needed reproduce from the other side's world with psexec
    s1["Confirm the execution user with whoami /all"] --> s2["Check the token in Process Explorer"]
    s2 --> s3["Identify the actual paths and keys with ProcMon"]
    s3 --> s4["Reproduce from the other side's world with psexec"]
    s3 -.-> hint["An unexpected profile path is the clue"]

Figure 12: Confirm the execution user, look at the actual paths and registry keys, then reproduce as the target execution principal.

When settings are missing, go back to AppData and HKCU; when the file can be read but not decrypted, to DPAPI; when only authentication fails, to the vault, certificates, and logon type. Do not judge from the error message alone; the shortcut is to line up “who used which location, with which key or credentials.”

10. Summary

“It works on my machine” means “it works as that user, with that profile, with those keys and that vault.” Even when the same .exe is launched on the same PC, turning it into a task, a service, or a CI job has to be treated as a migration of the execution environment.

AppData and user environment variables refer to the execution user’s profile, and HKCU likewise points to that user’s hive. The DPAPI CurrentUser scope depends on the user’s master key, and browser sign-in state and Credential Manager are also affected by that boundary.

Furthermore, even with the same SID, the differences in logon type, profile loading, and the session created by UAC elevation remain. Conversely, when multiple sessions of the same user share AppData and HKCU, think about write conflicts.

In design reviews, ask the following question.

Is this code correct no matter which user it runs as?

Provide the required storage locations, keys, and credentials explicitly for the actual execution principal. Confirm this principle before the migration, and you can reduce, at the design stage, the breakage where “the code did not change, yet it broke.”

Related Articles

• Storing Secrets in Windows Apps - Avoiding Plaintext Configuration with DPAPI
• How to Choose Where a Windows App Stores Local Data — A Decision Table for SQLite / JSON / Registry / Access
• When Task Scheduler Tasks Don’t Run or Exit with 0x1 — Isolating the Cause and Designing for Reliable Operation
• Choosing a Windows Service Account — LocalSystem, Virtual Accounts, and gMSA
• The Windows Certificate Store in Practice — User or Computer, Which Should You Use?

Related Consulting Areas

KomuraSoft LLC handles the design of execution environments when business apps are turned into services or scheduled tasks, the investigation of “it works on my machine” failures, and the design of secret management for Windows apps.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Legacy Asset Migration
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

An app that works when launched from File Explorer cannot find its configuration file when launched from Task Scheduler. Why?

Because environment variables such as %APPDATA% resolve to the profile of the user who is running the program. When the task runs as SYSTEM or as another account, the environment variables point to a different profile (under systemprofile in the case of SYSTEM), and the configuration file you saved does not exist there. Check the account the task runs as, and put data that should be shared under ProgramData as the permanent fix.

A password saved with ProtectedData.Protect can no longer be decrypted once the app became a service.

DPAPI in the CurrentUser scope depends on the master key of the user who encrypted the data. If the service runs as a different account, the master key is a different one, so decryption fails with a CryptographicException. Redesign a secret that both the service and the interactive user read to use the LocalMachine scope plus a file ACL, or run the service under the account of the person who encrypted it.

What happens when a process running as SYSTEM reads HKCU?

In a LocalSystem process, HKEY_CURRENT_USER is associated with the default user (HKEY_USERS\.DEFAULT), so the values the interactive user wrote to HKCU are not visible. Put machine-wide settings in HKLM, and if you absolutely must read a user's settings, impersonate that user and then use RegOpenCurrentUser.

Can I copy a signed-in Chrome/Edge profile to a CI machine and use it?

Generally, no. The profile of a Chromium-based browser such as Chrome or Edge lives under the user's %LOCALAPPDATA%, and the encryption key for cookies and saved passwords is protected by that user's DPAPI. Copying the folder to another user or another machine fails to decrypt because the key does not match (browsers such as Firefox, which have their own profile protection, are a different story). For automation, code the sign-in steps for a test account, or use the storage-state mechanism of your automation tool.

Credentials saved with cmdkey are not used when the task runs from Task Scheduler.

Because the Credential Manager vault is separate for each user, and what you saved went into the vault of your own interactive logon. In addition, a task configured with "Do not store password" (S4U) runs without network credentials, so entering credentials into the vault does not help while it stays on S4U. First consider a configuration that stores the password or a switch to a service account, and only then, if still needed, enter the credentials into the vault of the execution account itself.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.