Windows 用户配置文件入门 - AppData 与 NTUSER.DAT

本文面向管理 Windows 的信息系统人员、终端部署负责人以及 Windows 应用开发者，以一般性论述的方式进行整理。 图为概念图。在支持 Mermaid 的 Markdown 环境中会以图表形式显示。

内容基于截至 2026 年 4 月能够确认到的 Microsoft 官方信息。[1][4][7][10][13][14]

阅读指引

文章较长，先按读者的立场给出各自的入口。

在与 Windows 相关的咨询中，“配置文件（Profile）”这个词的使用范围相当广泛。

• C:\Users\用户名 里面到底是什么
• %AppData% 和 %LocalAppData% 该如何区分使用
• 域环境中的漫游配置文件是什么
• Mandatory 配置文件与 Temporary 配置文件有什么区别
• 共享 PC、RDS、VDI、Azure Virtual Desktop 该选哪种方案
• 配置文件损坏时，应该从哪里开始排查

这一带，账户、文件夹、注册表、同步方式、运维策略一下子混在一起，话题很容易跑偏。

本文首先建立把 Windows 用户配置文件当作一张设计图来看的视角，然后按顺序整理AppData 的区分使用、漫游、Mandatory、Temporary、FSLogix、故障时的排查思路。

1. 先说结论

在深入细节之前，先把实务上的结论列出来。

• Windows 的用户配置文件不是单纯的一个 C:\Users\用户名 文件夹，而是文件组 + 用户注册表配置单元（NTUSER.DAT）的组合。[1]
• 普通的本地 PC 默认会创建本地配置文件。首次登录时，会以 C:\Users\Default 为基础创建新的配置文件。[11][12]
• 应用程序的保存位置不应随意决定，基本原则是：想随用户一起带走的设置放在 %APPDATA%，该电脑专属的缓存或临时状态放在 %LOCALAPPDATA%。[2][3]
• 漫游配置文件（Roaming Profile）是“把整个配置文件都寄放到共享位置”的机制，Folder Redirection 则是“只把 Documents 等已知文件夹寄放到别处”的机制，两者并不相同。[4][5]
• Mandatory 配置文件是一种“让人使用但不保存变更”的只读配置文件。Temporary 配置文件则是出错时的紧急应对，前提是每次都会被删除。[7][8][9]
• 跨 OS 世代的漫游配置文件需要特别留意。Windows 10 / Server 2016 及之后版本与更早版本之间不兼容，应该按配置文件版本分开处理。[6]
• 在 RDS / VDI / Azure Virtual Desktop 中，与单纯依赖传统漫游配置文件相比，很多场景下更应该把FSLogix 配置文件容器当作首选。Microsoft 在 Azure Virtual Desktop 中也推荐使用 FSLogix。[13][14]
• 出现问题时，不要一开始就直接动 C:\Users，先查看Application 日志、User Profile Service 的 Operational / Diagnostic 日志、共享路径、NTUSER.DAT / USRCLASS.DAT 的属性和权限，这样思路更清晰。[10][11][16]

总而言之，Windows 配置文件的话题归结起来就是：“把什么放在哪里、能带多远、失败时如何恢复”。

1.1 本文使用的缩写

开头就密集出现的缩写，在这里先展开说明。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 24 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. Windows 的“用户配置文件”到底是什么

首先，把账户和配置文件分开来看，理解起来会更轻松。

flowchart LR
    A[用户账户<br/>谁在登录] --> B[用户配置文件<br/>该用户的设置与数据]
    C[终端 / OS] --> B
    B --> D[桌面设置]
    B --> E[AppData]
    B --> F[Documents / Desktop 等]
    B --> G[HKCU 中可见的设置]

图1：账户是标识符，配置文件是设置与数据的实体，终端负责加载并使用它。

• 账户用来标识某个人
• 配置文件是该用户工作环境的实体
• 终端是加载并使用该配置文件的场所

Microsoft Learn 中也说明，用户配置文件包含文件系统上的配置文件文件夹组与注册表配置单元 NTUSER.DAT，登录时会加载该配置单元并将其用作 HKEY_CURRENT_USER。[1]

2.1 不只是“文件夹”，还“包含注册表”

这一点很重要。

flowchart TD
    A[登录] --> B[定位配置文件文件夹]
    B --> C[加载 NTUSER.DAT]
    C --> D[作为 HKCU 使用]
    B --> E[准备 Desktop / Documents / AppData]
    D --> F[用户设置生效]
    E --> F

图2：登录时文件夹准备与 NTUSER.DAT 加载同时完成，用户设置才会生效。

也就是说，只看 C:\Users\用户名 还只看到了一半。

Windows 配置文件大致由以下两层构成。

1. 文件层 Desktop、Documents、Downloads、AppData 等
2. 注册表层 加载了 NTUSER.DAT 的 HKCU

配置文件损坏之所以复杂，是因为存在只有文件夹一侧损坏的情况，也存在注册表配置单元一侧出问题的情况。[1][11]

2.2 首次登录时以 Default 为基础

新用户第一次在该电脑上登录时，Windows 会以 C:\Users\Default 为基础创建本地配置文件。[11]

flowchart LR
    A[C:\Users\Default] --> B[首次登录]
    B --> C[生成 C:\Users\用户名]
    C --> D[加载 NTUSER.DAT]
    D --> E[成为该用户专属的环境]

图3：首次登录时以 Default 为基础，创建出该用户专属的配置文件。

在镜像部署或装机场景中，如果在这一点上处理得比较随意，后面会相当痛苦。

Microsoft 说明，关于自定义默认配置文件，受支持的方法是使用 CopyProfile。手动复制或老旧的粗放式复制方式，会带入多余的信息，有时还会给应用程序或系统稳定性带来问题。[12]

3. 如何看待 C:\Users\用户名

从文件夹的角度来看用户配置文件，大致是这样的结构。

flowchart TD
    A["C:\Users\用户名"] --> B[Desktop]
    A --> C[Documents]
    A --> D[Downloads]
    A --> E[Pictures]
    A --> F[AppData]
    A --> G[NTUSER.DAT]
    F --> H[Roaming]
    F --> I[Local]
    F --> J[LocalLow]

图4：配置文件由文件夹组和 NTUSER.DAT 构成，AppData 又进一步分为三部分。

在实务中，最先要看的位置大致就是下面这些。

3.1 把 AppData 分成 3 部分来看

在 Windows 应用开发和故障排查中，最容易混淆的正是这里。

Microsoft 的指南建议，应用专属数据使用 FOLDERID_RoamingAppData（Roaming AppData），临时文件或不在其他计算机上使用的数据则使用 FOLDERID_LocalAppData。[2]

另外，在 Known Folders 的定义中，默认路径整理如下。[3]

• %APPDATA% = %USERPROFILE%\AppData\Roaming
• %LOCALAPPDATA% = %USERPROFILE%\AppData\Local
• LocalLow = %USERPROFILE%\AppData\LocalLow

flowchart LR
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[想要随用户带走的设置]
    B --> B2[较小的用户状态]

    C --> C1[缓存]
    C --> C2[可重新生成的数据]
    C --> C3[该电脑专属的状态]

    D --> D1[低完整性进程可写入的区域]

图5：Roaming 放想带走的设置，Local 放该电脑专属内容，LocalLow 是低完整性进程的存放处。

LocalLow 不是“用不上的地方”，而是“权限低的应用的存放处”

三者之中只有 LocalLow 的说明容易被一笔带过，但它只是用途特殊，存在理由其实非常明确。

Windows 的进程有一种叫做完整性级别（integrity level）的权限划分，以低完整性运行的进程无法写入 AppData\Roaming、AppData\Local 以及 HKCU 的大部分位置。这样一来它就什么都保存不了，因此系统准备了即使是低完整性也能写入的位置。那就是 %USERPROFILE%\AppData\LocalLow，以及注册表一侧的 HKEY_CURRENT_USER\Software\AppDataLow。[19]

整理一下就是这样。

典型例子是浏览器这类应用：它们特意把直接处理互联网内容的部分降到较低权限下运行。其设计思路是“万一该进程被攻陷，也要把影响范围限制在 LocalLow 之内”。

从应用开发一侧来看，结论很简单。

• 如果自己的应用不是以低完整性运行的，就没有理由使用 LocalLow。请使用 Local。
• 反过来，如果发现 LocalLow 下多出了不认识的文件夹，那么往里面写入的就是以低完整性运行的某个程序。这在做容量排查时是一条线索。

实务中的区分可以这样考虑

ProgramData 在 Microsoft 的已知文件夹定义中被定位为面向所有用户的应用程序数据，用于不会漫游的共享数据。[3]

这里最应该避免的，就是把每个用户各自的运行时数据放在 Program Files 中。 这样很容易一下子打乱配置文件的整理结构和权限设计。

3.2 Public 与 Default 的角色不同

这里也容易混淆。

flowchart LR
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[各用户]

    B --> B1[新配置文件的种子]
    C --> C1[所有用户可见的共享内容]
    D --> D1[各个用户的实体]

图6：Default 是新建配置文件的种子，Public 是共享区域，各用户文件夹才是各自的实体。

• Default 是用来创建新配置文件的模板
• Public 是展示给所有用户的共享区域
• 各用户文件夹是该用户专属的实体

这三者看起来相似，但角色完全不同。

4. 梳理配置文件的种类

“配置文件”这个说法虽然简单，但在运维上至少存在以下这些种类。

flowchart TD
    A[Windows 的配置文件] --> B[本地配置文件]
    A --> C[漫游配置文件]
    A --> D[Mandatory 配置文件]
    A --> E[Temporary 配置文件]
    A --> F[FSLogix 配置文件容器]

图7：运维上的配置文件，从本地到 FSLogix 至少可分为 5 种。

4.1 本地配置文件

普通 PC 默认使用的就是这一种。

• 在该 PC 的本地磁盘上创建
• 不会自动带到其他 PC
• 在单机场景下最为简单

Microsoft 也说明，Windows 默认会创建本地用户配置文件。[14]

4.2 漫游配置文件

Microsoft Learn 中说明，漫游用户配置文件保存在服务器共享中，是一种让多台计算机能够获得相同 OS / 应用设置的机制。[4][5]

flowchart LR
    A[共享服务器上的配置文件] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

图8：漫游配置文件是让多台 PC 获取共享服务器上同一份配置文件的机制。

不过，实务中有以下几点需要注意。

• 登录 / 注销时的复制或同步容易变得沉重
• 如果 AppData\Local 中积累了大量数据会很痛苦
• 容易受到 OS 版本差异问题的影响
• 会强烈受到共享路径和网络质量的影响

4.3 Mandatory 配置文件

Mandatory 配置文件是管理员创建的“不会保存变更的漫游配置文件”。[7][8]

根据 Microsoft 的说明，在 Mandatory 配置文件中，即使用户在会话期间做了更改，也不会像普通漫游配置文件那样被保存。[7]

此外，Win32 文档中还说明了以下两点。

• 把 NTUSER.DAT 重命名为 NTUSER.MAN，就会变成 Mandatory
• 把配置文件路径的文件夹名末尾改成 .man，就会变成 Super-mandatory

以上都出自该文档的说明。[8]

flowchart LR
    A[管理员准备好的配置文件] --> B[用户登录]
    B --> C[使用期间可以修改]
    C --> D[注销]
    D --> E[变更不会保存]

图9：Mandatory 是管理员准备的配置文件，注销时不保存使用期间的变更。

例如，这种方式适合以下用途。

• 教学终端
• 前台接待终端
• 自助终端（kiosk）
• 希望每次都恢复到干净状态的共享终端

4.4 Temporary 配置文件

Temporary 配置文件不是设计时可以主动选择的方案，而是在发生错误、无法加载本来的配置文件时启用的应急落脚点。[9]

Microsoft Learn 中说明，当出现错误条件、无法加载本来的配置文件时，会启用 Temporary profile，它会在会话结束时被删除，期间的变更都会丢失。[9]

flowchart TD
    A[开始加载常规配置文件] --> B{能否加载}
    B -->|Yes| C[正常登录]
    B -->|No| D[以 Temporary 配置文件登录]
    D --> E[可以继续工作]
    E --> F[注销后变更消失]

图10：Temporary 是加载失败时的应急落脚点，一注销变更就会消失。

也就是说，正在以 Temporary 配置文件运行这件事本身，就是一种异常信号。

4.5 FSLogix 配置文件容器

关于 FSLogix，Microsoft Learn 中说明它是一种让 Windows 用户配置文件体验在虚拟桌面环境中保持一致的机制。[13]

FSLogix 配置文件容器的方式是，把整个用户配置文件作为 VHD / VHDX 保存，登录时挂载该文件，使其看起来像原生配置文件。[13][14]

flowchart LR
    A[VHD / VHDX 上的配置文件] --> B[登录时挂载]
    B --> C[在会话主机上表现为 C:\Users\用户]
    C --> D[注销时卸载]

图11：FSLogix 在登录时挂载 VHD 上的配置文件，让它看起来像原生配置文件。

在 Azure Virtual Desktop 中，Microsoft 推荐使用 FSLogix profile containers。[14]

5. 漫游配置文件、Folder Redirection、FSLogix 有什么区别

这三者常被放在一起谈论，但角色其实并不相同。

flowchart TD
    A[携带用户状态] --> B[漫游配置文件]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[把整个配置文件寄放到共享位置]
    C --> C1[只把已知文件夹寄放到别处]
    D --> D1[挂载 VHD/VHDX]

图12：三种方式携带的范围不同：整体、只有已知文件夹，还是容器化。

参照 Microsoft Learn 的整理方式，用下面这样的角度来看会更容易理解区别。[4][5][14]

5.1 Folder Redirection 只寄放“已知文件夹”

Microsoft Learn 中说明，Folder Redirection 是一种把 known folder（已知文件夹）的路径指向别处的机制。[4]

例如，把 Documents 寄放到文件共享后，用户看到的样子和本地一样，但实体其实在别的位置。[4]

flowchart LR
    A[Documents] --> B[实体在文件共享中]
    C[Desktop] --> D[需要时另行设置]
    E[AppData] --> F[保持原样或采用其他方式]

图13：Folder Redirection 不是整个配置文件的搬迁，而是按文件夹单位的位置调整。

也就是说，Folder Redirection 并不是整个配置文件的替代方案，而是按文件夹单位的位置调整。

5.2 漫游配置文件不要随意跨 OS 世代混用

Microsoft 说明，Windows 10 / Server 2016 及之后版本的漫游配置文件，与更早期的 Windows 不兼容。[6]

flowchart LR
    A[Windows 7 / 8.1 系列] -.混用需注意.-> B[同一个共享]
    C[Windows 10 / Server 2016 及之后] -.混用需注意.-> B
    B --> D[不一致 / 开始菜单异常 / 任务栏异常的原因]

图14：把不同 OS 世代的漫游配置文件混放在同一个共享中，会成为不一致的根源。

这里重要的是：

• 按 OS 世代区分配置文件版本
• 不要认为“同一个用户，用同一个文件夹就行”
• 在终端部署或更换时，把配置文件的兼容性纳入迁移计划

以上这几点。[6]

6. 开发者与运维人员应优先确定的存储位置

配置文件的话题，最终都会回到这一点上。 就是该把什么放在哪里。

flowchart TD
    A[想保存的数据] --> B{是否是用户创建的产出}
    B -->|Yes| C[Documents 等]
    B -->|No| D{是否该电脑专属}
    D -->|Yes| E[%LOCALAPPDATA%]
    D -->|No| F{是否是用户各自的设置}
    F -->|Yes| G[%APPDATA%]
    F -->|No| H{是否是全用户共享的可变数据}
    H -->|Yes| I[ProgramData + ACL]
    H -->|No| J[重新考虑存放位置]

图15：想保存的数据，按产出、电脑专属、用户设置、共享的顺序依次分流。

6.1 区分用户创建的文件与应用内部状态

如果把这两者混在一起，备份和迁移都会很容易出问题。

• 用户主动处理的产出文件 Documents、Pictures、业务用保存文件夹
• 应用内部的状态 设置、缓存、缩略图、会话信息、工作文件

前者是业务数据，后者是出于应用自身需要。 即使同样是“文件”，也最好分开处理。

flowchart TB
    accTitle: 产出文件与应用内部状态的分离
    accDescr: 用户主动处理的产出文件应作为Documents等业务数据来对待，而设置与缓存等应用内部状态应作为出于应用自身需要的存放处来对待，若不区分处理，备份与迁移都容易出问题。
    sp1["要保存的文件"] --> sp2["用户主动处理的产出文件"]
    sp1 --> sp3["应用内部的状态"]
    sp2 -.-> sp4["Documents等业务数据"]
    sp3 -.-> sp5["设置与缓存出于应用自身需要"]

图16：同样是文件，业务数据与应用自身需要的存放位置和处理方式要分开。

6.2 放在 %APPDATA% 中的内容

这里存放的大致是这样的内容。

• 较小的设置
• 每个用户各自的偏好设置
• 想在多个终端上保持相同外观的状态
• 可以跟随配置文件一起携带的内容

在 Fast User Switching 的文档中，也建议将 FOLDERID_RoamingAppData 作为应用专属数据的存放位置。[2]

6.3 放在 %LOCALAPPDATA% 中的内容

应该放在这里的，是从能否重新生成和是否需要携带的角度来看、应封闭在本地的内容。

• 可以重新生成的缓存
• 只在本地才有意义的状态
• 较大的工作文件
• 出于性能考虑不想让它随用户携带的内容

在 Known Folders 的定义中，LocalAppData 也是 %USERPROFILE%\AppData\Local。[3]

6.4 放在 ProgramData 中的内容

全体用户共用，但在运行期间会变化的数据，可以考虑放在 ProgramData 一侧。[3]

例如：

• 共享字典
• 全体用户共用的定义文件
• 服务与多个用户共享的可变数据

不过，这里需要连同 ACL 设计一起考虑。 不能只是“因为是共享的所以先放 ProgramData”，重要的是决定谁能读、谁能写。

6.5 想要定制默认配置文件时

在镜像部署中，“想让所有新用户都获得相同的初始设置”是很常见的需求。 这种情况下，不要随意改动 Default，而应采用 Microsoft 官方支持的、基于 CopyProfile 的方法来搭建，这样更安全。[12]

flowchart LR
    A[以管理员账户进行初始设置] --> B[Sysprep + CopyProfile]
    B --> C[应用到 Default profile]
    C --> D[应用于此后的新用户]

图17：定制默认配置文件，要走 Sysprep 与 CopyProfile 这条路径。

像“把某台 PC 的 C:\Users\A 手动复制到另一台 PC 的 Default”这样的做法，表面上看起来很快，但之后很容易出问题。[12]

7. 损坏、变成临时配置文件、不同步时的排查思路

这是现场最令人头疼的部分。 而且各种症状看起来很相似，如果排查得不够细致，很容易一路追进死胡同。

7.1 先把症状分成 3 类

flowchart TD
    A[疑似配置文件问题] --> B{能否登录}
    B -->|Yes| C{外观是否被初始化}
    B -->|No| D[加载失败类]
    C -->|Yes| E[Temporary / 损坏 / 其他配置文件]
    C -->|No| F{是否只有部分设置被还原}
    F -->|Yes| G[漫游 / 重定向 / 同步类]
    F -->|No| H[可能是应用个别问题]

图18：按能否登录和外观是否被初始化，可以把配置文件问题分成 3 条线索。

大致可以分成以下 3 大类。

1. 登录时失败
2. 能登录，但看起来像是被初始化了
3. 只有部分内容没有同步

7.2 首先应该查看的日志

Microsoft Learn 建议，在排查配置文件问题时按以下顺序查看。[10]

1. Application 日志
2. User Profile Service 的 Operational 日志
3. 必要时查看 Diagnostic 日志
4. 如仍需要，进一步查看 ETL 跟踪

具体路径如下。[10]

• 事件查看器（Event Viewer） Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• 需要查看更多细节时 ... > User Profile Service > Diagnostic

在中文版 Windows 的事件查看器中，左侧树显示为 应用程序和服务日志 > Microsoft > Windows > User Profile Service > Operational。从提供程序名称往下仍保持英文写法。

flowchart LR
    A[Application 日志] --> B[Operational 日志]
    B --> C[Diagnostic 日志]
    C --> D[ETL 跟踪]

图19：排查要按 Application 日志、Operational、Diagnostic、ETL 跟踪的顺序逐层深入。

在现场，与一开始就直接修复注册表或删除文件夹相比，先通过日志把握“加载失败”“复制失败”“访问被拒绝”“路径过长”“无法写入共享”等方向，会更安全。

这 3 种日志分别在“不同的地方”

这里是最初容易迷路的地方，所以先梳理清楚。[10]

Diagnostic 日志默认不会出现在树中。需要先在事件查看器的操作窗格 > 查看 > 显示分析和调试日志中打开该选项，然后选择 Diagnostic，执行启用日志。排查结束后请务必改回禁用。这是一种过于详细的日志，不适合长期开着。[10]

不打开 GUI 也能看到同样的内容

想提高可重现性，或者要排查远程终端时，用命令获取更可靠。与其口头向别人描述事件查看器的界面，不如做到能直接说请执行这条命令并把结果发过来，这样会更快。

# 1) 只从 Application 日志中按时间倒序查看 User Profile Service 的事件
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

# 2) 直接查看 Operational 日志
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# 3) 只筛选出由路径过长引起的 Event ID 1509
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
    Id           = 1509
} | Format-List TimeCreated, Id, Message

这里有一个陷阱。Application 日志一侧的来源名是 Microsoft-Windows-User Profiles Service（Profiles 为复数），而 Operational 日志的通道名是 Microsoft-Windows-User Profile Service/Operational（Profile 为单数）。复制粘贴后跑不通时，问题多半就出在这里。

Event ID 1509 出现在 Application 日志而不是 Operational 日志中。级别为警告，正文的格式是“Windows 无法将文件 \\服务器\共享\... 复制到 C:\Users\...”这样的消息，随后紧跟着 DETAIL - The filename or extension is too long.。最后这一行正是判定原因为路径长度的决定性依据。[16]

还有一点，知道了能在实务中节省时间。User Profile Service 的事件 1530“注册表文件仍被其他应用程序或服务使用”是可以忽略的，Microsoft 对此有明确说明。[10] 去追它只会白费力气。

flowchart TB
    accTitle: 日志名单复数形式的陷阱
    accDescr: Application日志一侧的来源名是复数形式的Profiles，而Operational日志的通道名是单数形式的Profile，复制粘贴后命令跑不通时，多半就是把这两者弄混了。
    lg1["命令跑不通"] --> lg2{"用的是哪一个日志名"}
    lg2 -->|"Application的来源名"| lg3["Profiles为复数"]
    lg2 -->|"Operational的通道名"| lg4["Profile为单数"]
    lg3 -.-> lg5["混淆是最常见的原因"]
    lg4 -.-> lg5

图20：两个形似而不同的日志名，是复制粘贴失败的常见原因。

7.3 常见原因

NTUSER.DAT / USRCLASS.DAT 的属性或权限

Microsoft 说明，如果 NTUSER.DAT 或 USRCLASS.DAT 变成了 Read-only（只读），或者缺少所需的访问权限，配置文件加载就可能失败。[11]

这个原因看起来不起眼，但一旦被忽略，问题就会拖得很久。

flowchart LR
    A[加载配置文件] --> B{能否访问 DAT 文件}
    B -->|No| C[登录失败 / 初始桌面 / Temporary]
    B -->|Yes| D[正常加载]

图21：无法访问 DAT 文件，就会导致登录失败或转为临时配置文件。

漫游复制时路径过长

Microsoft 的 KB 文章中说明了这样的例子：由于共享路径一侧的服务器名或共享名过长，导致复制目标路径整体过长，从而伴随 Event ID 1509 落到临时配置文件。[16]

看起来只是简单的路径长度限制，但实际上原因有时出在漫游目标本身的设计上。

因删除不完整而残留的注册表 / 文件夹信息

Microsoft 提供了一篇示例脚本文章，介绍如何清理残留在注册表和 C:\Users 中的孤立信息，以防止出现 TEMP 配置文件。[15]

从这一点可以看出，并不是删除文件夹就万事大吉。

flowchart LR
    A[随意删除旧配置文件] --> B[注册表信息残留]
    B --> C[下次登录出现不一致]
    C --> D[成为 TEMP 配置文件或附加文件夹的原因]

图22：随意删除后残留的注册表信息，会在下次登录时造成不一致。

7.4 首先应该确认什么

8. 应该选择哪种方式

这里并不存在“唯一正确答案”。 答案会随使用形态而变化。

flowchart TD
    A[使用形态] --> B[个人专用 PC]
    A --> C[加入域的办公 PC]
    A --> D[共享 PC / 教学终端]
    A --> E[RDS / VDI / AVD]

    B --> B1[以本地为主]
    C --> C1[视需要采用 Folder Redirection / 漫游]
    D --> D1[Mandatory / Shared PC / cleanup]
    E --> E1[优先考虑 FSLogix]

图23：随使用形态不同，首选方案会从以本地为主一直变到 FSLogix。

8.1 个人专用 PC

基本上使用本地配置文件就足够了。

• 用户设置放在 AppData
• 产出文件放在 Documents
• 如有需要，可通过 OneDrive 等其他层面来同步文档

这种结构最为简单。

8.2 加入域的办公 PC

根据需求，可以组合使用以下方式。

• 想要集中管理文档数据 → Folder Redirection
• 想让多台 PC 保持相同设置 → 漫游配置文件
• 存在 OS 混用或超大配置文件的情况 → 需要谨慎设计，或重新审视方式

Microsoft Learn 中也提到，Folder Redirection 和 Roaming User Profiles 有助于实现集中管理、离线使用、简化备份等目标。[4]

8.3 共享 PC / 教学终端 / 自助终端

在这类用途中，比起“保留个性化设置”，更重要的是每次都恢复到干净状态。

可选方案有以下 3 种。

• Mandatory 配置文件
• Shared PC 模式
• 旧配置文件自动删除策略

Microsoft 提供了名为 Delete user profiles older than a specified number of days on system restart 的策略，可以在重启时删除超过指定天数未被使用的配置文件。[17]

另外，在 Shared PC 的指南中也提出了在共享终端上组合使用账户 / 配置文件自动管理与删除的思路。[18]

8.4 RDS / VDI / Azure Virtual Desktop

在这类场景下，很多情况下单靠传统的漫游配置文件已经力不从心。

Microsoft 在 Azure Virtual Desktop 中推荐使用 FSLogix profile containers，并说明会在登录时挂载 VHDX / VHD，把它当作原生用户配置文件来处理。[14]

flowchart LR
    A[多台会话主机] --> B[共享存储]
    B --> C[VHDX 中的用户配置文件]
    C --> D[挂载到所连接的主机]

图24：多台会话主机挂载并使用共享存储上的 VHDX 配置文件。

尤其是在以下这些条件下，优先考虑 FSLogix 更有价值。

• 会话主机每次都会变化
• 使用 Outlook / OneDrive / Microsoft 365 系列产品
• 非持久化 VDI 中必须携带配置文件
• 漫游配置文件的登录延迟成为问题

9. 常见的误解

9.1 “只要创建账户，配置文件也会在任何地方使用同一份”

并非如此。账户只是标识符，配置文件才是终端一侧的实体。 能带到多远，取决于本地、漫游、Folder Redirection、FSLogix 等方式的选择。[4][14]

9.2 “复制 C:\Users\用户名 就能完成迁移”

随意复制是很危险的。

• OS 版本兼容性
• NTUSER.DAT
• 权限
• 应用专属状态
• 与默认配置文件之间的串扰

这些问题都存在。特别是在存在 OS 世代差异的漫游场景中，Microsoft 也是以配置文件版本分离为前提的。[6]

flowchart TB
    accTitle: 随意复制迁移之所以危险的原因
    accDescr: 通过随意复制用户文件夹来迁移，会带来OS版本兼容、NTUSER.DAT、权限、应用专属状态以及与默认配置文件串扰等问题，因此这种做法很危险。
    mv1["整个文件夹复制过去"] --> mv2["看起来像是迁移成功了"]
    mv2 -.-> mv3["OS兼容与NTUSER.DAT的问题仍然存在"]
    mv2 -.-> mv4["权限与默认配置文件的串扰"]
    mv3 --> mv5["成为日后容易出问题的迁移"]
    mv4 --> mv5

图25：配置文件不只是文件夹，所以靠复制搬不走。

9.3 “Mandatory 和 Temporary 是类似的东西”

这两者是完全不同的东西。Mandatory 是管理员有意创建的只读配置文件，Temporary 则是在出错、无法读取本来的配置文件时使用的应急落脚点。[8][9]

9.4 “想同步的话，把所有内容都放进 Roaming 就好”

这样很危险。如果把设置和巨大缓存放进同一个箱子，登录 / 注销以及故障处理都会变得沉重。 把想要漫游的内容和应封闭在本地的内容区分开来，运维起来会更轻松。[2][3]

9.5 “即使变成了临时配置文件，照样用下去也没关系”

最好避免这样做。因为 Temporary profile 本来就是以注销后会被删除为前提的， 如果在这种状态下继续工作，就有可能把重要数据放在了之后会被删除的位置。[9]

10. 总结

Windows 的用户配置文件，并不只是指 C:\Users 下面的某个文件夹。

• 文件组
• 以 NTUSER.DAT 为核心的用户注册表
• 该配置文件存放在哪里、如何同步、如何删除等运维方式

把这些一并纳入考虑、当作一个整体设计来看待，思路就会变得清晰。

在实务中，希望优先掌握以下这 6 点。

• 单机 PC 的话，首先以本地配置文件为基准来考虑
• 应用的存放位置要区分 Roaming / Local / ProgramData
• 在域环境中，不要把漫游配置文件和 Folder Redirection 混为一谈
• 在共享终端上，考虑 Mandatory / cleanup / Shared PC
• 在 RDS / VDI / AVD 中，把 FSLogix 列为首选
• 出现故障时，先查看 User Profile Service 的日志

归根结底，配置文件的设计不在于“保存到哪里”，而在于“把什么当作是谁的东西、能带到多远”。 只要这一点确定下来，无论是终端部署、Windows 应用的设计，还是故障排查，都会变得容易许多。

flowchart TB
    accTitle: 配置文件设计的三个问题
    accDescr: 配置文件的设计归结为把什么放在哪里、能带到多远、失败时如何恢复这三个问题，只要这里确定下来，终端部署、应用设计与故障排查都会变得更容易。
    dq1["把什么放在哪里"] --> dq2["能带到多远"]
    dq2 --> dq3["失败时如何恢复"]
    dq3 -.-> dq4["部署、设计、排查都会变轻松"]

图26：只要能回答这三个问题，配置文件的设计基本就定下来了。

11. 相关文章

• Windows 什么时候需要管理员特权 - UAC、受保护区域与设计上的判断方法
• 用 Windows 沙盒加快 Windows 应用开发验证的方法

12. 与本主题相关的服务

Windows 应用开发

如何划分用户设置、日志、缓存、共享数据的存放位置，会在很大程度上左右 Windows 应用的可运维性与可维护性。 如果想从需求整理一直延伸到设计、实现与长期运维，这是一个和 Windows 应用开发场景很契合的主题。

查看服务 / 联系我们

技术咨询与设计评审

该选择本地、漫游还是 FSLogix，要如何改变现有终端的运维方式，存放位置又该如何划分——这些问题在实现之前是否整理清楚，会带来相当大的差别。 如果想从方式选型和边界设计开始梳理，这是一个很适合作为技术咨询、设计评审来切入的主题。

查看服务 / 联系我们

故障排查与原因分析

转为 Temporary 配置文件、登录失败、注销时保存失败、共享路径相关问题的定位，都与故障排查这项工作非常契合。 如果想从日志、事件、权限、共享结构等角度来彻查难以重现的配置文件问题，这里可以作为咨询的入口。

查看服务 / 联系我们

13. 参考资料

出处较多，先给出一份可以按论点检索的索引。

1. Microsoft Learn, About User Profiles (Windows) 用户配置文件的构成要素、NTUSER.DAT、Temporary profile 的基础知识。

2. Microsoft Learn, Fast User Switching 应用专属数据使用 FOLDERID_RoamingAppData，不在其他计算机上使用的数据使用 FOLDERID_LocalAppData 的整理方式。

3. Microsoft Learn, KNOWNFOLDERID, CSIDL %APPDATA%、%LOCALAPPDATA%、LocalLow、ProgramData 等已知文件夹的定义。

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server Folder Redirection 与 Roaming User Profiles 的区别，以及集中管理的思路。

5. Microsoft Learn, Deploy roaming user profiles 漫游配置文件的部署、共享权限、GPO、版本管理的实务步骤。

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions OS 世代之间的不兼容性与配置文件版本管理。

7. Microsoft Learn, Create mandatory user profiles Mandatory user profile 的用途与创建方法。

8. Microsoft Learn, Mandatory User Profiles NTUSER.MAN、Super-mandatory profile 的定义。

9. Microsoft Learn, Temporary User Profiles Temporary profile 的定义与性质。

10. Microsoft Learn, Troubleshoot user profiles with events 使用 Application / Operational / Diagnostic 日志进行排查的方法。

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time 以 C:\Users\Default 为起点创建新配置文件的过程，以及 NTUSER.DAT / USRCLASS.DAT 的属性、权限问题。

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows 使用 CopyProfile 进行受支持的默认配置文件自定义方法。

13. Microsoft Learn, What is FSLogix, Types of Containers FSLogix 的基础知识，以及 Profile Container 的设计思路。

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix Azure Virtual Desktop 中的推荐做法，以及使用 VHD / VHDX 的配置文件容器方式。

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created 孤立的配置文件信息与 TEMP profile 之间的关系。

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long 漫游配置文件保存时出现的路径过长问题。

17. Microsoft Learn, ADMX_UserProfiles Policy CSP Delete user profiles older than a specified number of days on system restart 等策略的定义。

18. Microsoft Learn, Configure a shared or guest Windows device Shared PC 模式与共享终端的账户 / 配置文件管理。

19. Microsoft Learn, Designing Applications to Run at a Low Integrity Level 作为低完整性进程可写入的位置，系统准备了 %USERPROFILE%\AppData\LocalLow 与 HKEY_CURRENT_USER\Software\AppDataLow。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

NTUSER.DAT 是什么？

NTUSER.DAT 是 Windows 用户配置文件中所包含的用户注册表配置单元（registry hive）的实体文件。它位于 C:\Users\用户名 目录下，登录时会被加载并作为 HKEY_CURRENT_USER（HKCU）使用。也就是说，用户配置文件由 Desktop、AppData 等文件组，以及以 NTUSER.DAT 为核心的注册表层这两层构成。如果 NTUSER.DAT 变成只读属性，或者缺少所需的访问权限，就会导致配置文件加载失败，从而引发登录失败或转为临时配置文件的问题。

Windows 的用户配置文件是什么？和账户不一样吗？

账户用于标识“谁在登录”，而用户配置文件则是这个人工作环境的实体。配置文件不只是一个 C:\Users\用户名 文件夹，而是由 Desktop、Documents、AppData 等文件组，以及名为 NTUSER.DAT 的用户注册表配置单元组合而成。新用户第一次登录该电脑时，Windows 会以 C:\Users\Default 为基础创建新的配置文件。至于设置能被带到多远，则取决于本地、漫游、Folder Redirection、FSLogix 等方式的选择。

%APPDATA% 和 %LOCALAPPDATA% 应该怎么区分使用？

基本原则是，想随用户一起带走的设置放到 %APPDATA%（AppData\Roaming），而该电脑专属的缓存或临时状态则放到 %LOCALAPPDATA%（AppData\Local）。如果把可以重新生成的缓存或较大的工作文件也一起漫游，登录、注销就容易变得缓慢，因此这类数据应偏向放在 Local 一侧。全体用户共用的可变数据可以考虑放在 ProgramData，但需要同时设计好谁能读写的 ACL（访问控制列表）。应避免把用户各自的运行时数据放在 Program Files 中。

以临时配置文件（Temporary profile）登录时该怎么办？

临时配置文件是在发生错误、无法加载原本的配置文件时启用的紧急应对措施，注销时会被删除，期间的所有更改都会丢失。如果就这样继续工作，就有丢失重要数据的风险，因此这是应该避免的状态。排查时不要一开始就直接动 C:\Users，而应先查看 Application 日志和 User Profile Service 的 Operational 日志，必要时再查看 Diagnostic 日志。常见原因包括 NTUSER.DAT / USRCLASS.DAT 的属性或权限问题、漫游目标路径过长的问题，以及因删除不完整而残留的注册表信息等。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。