How do I get the path to the default user’s profile?

A customer wanted to know how to get the path to the default user's profile. On older versions of Windows, the default location of the default user's profile was C:\WINNT\Profiles\Default. Then it moved to C:\Documents and Settings\Default User. Now it's in C:\Users\Default. And the location may have been customized, so in principle it could be anywhere.

The function to get the default user profile's directory is is the deviously-named Get­Default­User­Profile­Directory.

But the reason I'm writing this article is not to call your attention to the Get­Default­User­Profile­Directory function, but rather to something in the function documentation.

The documentation for the Get­Default­User­Profile­Directory function includes the strings C:\Documents and Settings\Default User and C:\Users\Default, so all somebody had to do was type either of those paths into a search engine scoped to MSDN, and it would have found the function to use.

This sort of counts as a counterexample to the suggestion that in order to help people find the correct function to use (instead of whacking an undocumented registry key), MSDN should include the path to the registry key so that a search for the undocumented registry key will kick up a page that says, "Do not use this registry key. Call this other function instead." That experiment was attempted (inadvertently) with the Get­Default­User­Profile­Directory function, and it didn't work.

Comments (22)
  1. Brian_EE says:

    "That experiment was attempted (inadvertently) with the Get­Default­User­Profile­Directory function, and it didn't work."

    Trying to remember back to my statistics classes 20 years ago, but I'm pretty sure that a sample size of 1 is too small to make any reasonable conclusions about.

  2. alegr1 says:

    You can try to write idiot-proof documentation. But then, a bigger idiot comes.

  3. Mark says:

    Brian: and that's why it's merely a counterexample, and not a study.

  4. Antonio 'Grijan' says:

    You can't write (or make) anything idiot-proof. Idiots don't use to read (or think), and if the user doesn't read your copy, you have lost before starting. There is no point trying to keep those people. Instead, make messages short, concise and actionable, and documentation clear, and many users will take the time to read it. Alerts (message boxes, task dialogs and the like) are critical.

  5. Karellen says:

    Why store the skel^Wdefault user profile in the same place as the actual user profiles? Surely that's asking for trouble. What if you has a user whose username according to your normal username-assignment policies would be "Default"?

    (You might think that's never going to happen, but I'm sure the company who ended up employing someone with the surname "null"[0] thought something very similar…)

    It would be better to put the default profile in the Windows directory, or somewhere like that, wouldn't it?


  6. ErikF says:

    @Karellen: You would use common sense, just like what you would do if a Mr. Allan Dministrator came to your organization, or Richard Oot.

  7. Henke says:

    Doesn't the manual list the usual locations for ALL the movable shell folders?

  8. Joshua says:


    The default profile is for a user with no name. If you create the name default, the profile directory will be Default.DOMAIN or Default.COMPUTER.

  9. Anonymous Coward says:

    For all we know countless developers have found the function, but you never hear from those again.

  10. AndyCadley says:

    @Karellen: As others said, Windows copes gracefully with that and always has. Early versions of OS X on the other hand used to blow up spectacularly if you attempted to name your first account the same as a one of the system accounts (such as root). It was "fixed" around 10.2, IIRC, by simply prohibiting those names.

  11. Nick says:


    As Joshua points out, the system doesn't just explode if there's a folder already in the Profiles directory with the name it would normally use.  You see this all the time on domains "Administrator" and "Administrator.DOMAIN".  You can even get "Administrator.DOMAIN.001" and so on (corrupted profiles… :/).

    The SO question about Mr. Null is funny (and insightful) though.  When I worked at a large university I remember we tried to name our primary backup server "null" since we thought it would be very funny to "backup to (/dev/) null).  Unfortunately while the VitalQIP DNS system the university used would accept DNS registration for "", any attempts to resolve the name would time out (actually, as I later learned from the OIT group, it would actually *crash* the process doing the name lookup on the server!).  So I can empathize somewhat with Mr. Null :)

  12. asdbsd says:

    @alegr1, Antonio 'Grijan': You're calling them an idiot, but they at least seemed to realize the default profile path could change and cared to investigate.

  13. Neil says:

    @Karellen: No, that's where the Local System profile lives. That's because it's not a user.

  14. Marc K says:

    End users may not read your well thought out documentation, but it's a lot easier to respond to the support request with a link to said documentation than writing a custom response for each end user.

  15. 640k says:

    @AndyCadley: As others said, Windows copes gracefully with that and always has.

    No. Windows has never coped gracefully with that. That's why you sometimes see Username.DOMAIN.001 -> Username.DOMAIN.999 or more.

  16. Karellen says:

    Hang on – I'm a bit confused by people making the analogy to the "Administrator" and "root" accounts. Obviously those account names can't be used for a new user, because there is already an account called "Administrator" or "root" on the system, and you can't have two accounts with the same name. Same as if there's already a "jsmith" account, and you get a second "jsmith". You have to do something else.

    But the difference here – surely – is that there isn't a user called "Default" on the system. I thought that the "Default" profile was just a directory to be used as a template for new users, and wasn't an acutal user. But am I wrong here? Is "Default" an actual user account? Can the user "Default" log in (assuming the account is given a password)? Can the Administrator change the ownership of a file to user "Default"?

    (The obvious implication being, that if "Default" is not already an actual account, then you *should* be able to create one.)

  17. Klimax says:


    Funny, you both interpret same fact completely differently.

    Directory name != user name and thus he is right and Windows cope with it gracefully. They let you to use name, while ensuring no conflict.

    Or what other way would you do it?

  18. Question: Why people keep calling a folder a "directory"?

  19. cheong00 says:

    @Fleet Command: Because it's called "directory" for ages (looking at DOS commands "mkdir" and "rmdir"), and "folder" is the new word for this introduced around the time of Win95.

    And "Directory" is something you use to locate something.

  20. Anonymous Coward says:

    My Computer is a folder. My Computer is not a directory.

  21. Gabe says:

    A filesystem directory is shown as a folder in Explorer, but not all folders are directories. For example, Fonts and the Control Panel are folders that do not represent a directory.

  22. Wladimir Palant says:

    To be fair, finding that function by the paths you mention is still non-trivial. These paths are listed on tons of websites, many of which rank better than MSDN (at least on Google). When I searched "C:Documents and SettingsDefault User" the first MSDN result I got was on page 5 – and it was this very blog post. Searching for '"C:Documents and SettingsDefault User" msdn' is slightly better, that way you at least get this blog post as the first result – but the official documentation is still not in sight. I have to search for '"C:Documents and SettingsDefault User" msdn api' to get function documentation as the second result in the search. In other words: only now that this blog post is online people have a realistic chance to find function documentation if they search by the paths.

Comments are closed.

Skip to main content