Windows Powershell $profile does not show a real path

Question

I launch Windows Powershell (by hitting the windows key, typing "powershell" and pressing enter which launches C:\Windows\System32\WindowsPowerShell\v1.0) and type $profile and press enter and see WindowsPowerShell\Microsoft.PowerShell_profile.ps1

As far as I know, this is not a valid path. I was hoping for something like C:\Windows\...

When I type $profile | Format-List * -Force, however, there is some progress and I get

AllUsersAllHosts       : C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
AllUsersCurrentHost    : C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
CurrentUserAllHosts    : WindowsPowerShell\profile.ps1
CurrentUserCurrentHost : WindowsPowerShell\Microsoft.PowerShell_profile.ps1
Length                 : 50

However the CurrentUserAllHosts and CurrentUserCurrentHosts are still non-paths. What do these non-paths mean? Do they refer to some hidden values or do I need to set some system values somewhere?

Here is my $PsVersionTable.PsVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      14393  206

Here are the results of Get-Host

Name             : ConsoleHost
Version          : 5.1.14393.206
InstanceId       : a2a61a42-f2ee-46b9-b67a-ef441301bdb8
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

Interpretive

Are you using some custom host? What output of this command [Environment]::GetFolderPath([Environment+SpecialFolder]::Personal)? – Ravenous

Wouldn't PowerShell refuse to even start if that definition were missing? – Jock

It gives an empty response – Interpretive

For me, in a Win 10 machine, the value for $profile is C:\Users\userNamexxx\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 However there is no such folder nor the file ! – Divisor

There isn't by default, you have to create it. @Mark, what happens if you run [Environment]::GetFolderPath("MyDocuments") and open CMD and run echo %USERPROFILE%? – Gonsalves

Could WindowsPowerShell probably refers to the installation location of powershell, based on 32 or 64 process being used ? From C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1, it looks more like it! – Kastner

On Server-2016, $Profile.CurrentUserAllHosts => C:\Users\ebelew\Documents\WindowsPowerShell\profile.ps1, so this is likely a local thing. – Reasoned

@Mark: Thanks for accepting; can you tell us what the cause of the problem was in the end, perhaps as an addendum to your question? – Bricky

Sorry I was not able to access my Windows computer for some time. However, when I tried it just now... the path was fine! I feel like the problem may have been that I changed my home folder from C:\Users\marki to C:\Users\mark and then Windows got confused somehow. Now that I have it back to the default marki maybe it got fixed. – Interpretive

Answer 1

^{Note: This question is not about the $PROFILE file simply not existing, possibly along with its directory. If $PROFILE shows the expected path and you simply want to ensure that the file exists, use
if (-not (Test-Path $PROFILE)) { $null = New-Item -Force $PROFILE }}

tl;dr:

The problem may not be PowerShell-related, but may be due to a missing special-folder path definition in the registry.

Verify that registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders contains a REG_EXPAND_SZ value named Personal with data %USERPROFILE%\Documents - see diagnostic commands below.

If you find that you must (re)create it, use:

New-ItemProperty `
  'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' `
  Personal -Value '%USERPROFILE%\Documents' -Type ExpandString -Force

and then log off and back on (or reboot) to see if that fixed the problem.

---

Eris's helpful answer tells us that the user-specific PS profile paths are derived from what Environment.GetFolderPath(Environment.SpecialFolder.Personal) returns.

.NET gets this value, presumably via the SHGetKnownFolderPath Shell API function, from registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders, value Personal, where it is normally defined as a REG_EXPAND_SZ value containing (expandable) string %USERPROFILE%\Documents.
(There's also a legacy fallback location - see here.)

Profiles CurrentUserAllHosts and CurrentUserCurrentHost containing just relative paths, namely:

• WindowsPowerShell\profile.ps1
• WindowsPowerShell\Microsoft.PowerShell_profile.ps1

suggests that the Environment.GetFolderPath(Environment.SpecialFolder.Personal) call, whose result is used as the path prefix, unexpectedly returned an empty string, which in turn suggests a registry problem.

---

Here are some diagnostic commands and their expected outputs (jdoe represents your username):

# Verify that %USERPROFILE% is defined.
> $env:USERPROFILE
C:\Users\jdoe

# Verify that %USERPROFILE% is defined in the registry.
> Get-ItemPropertyValue 'HKCU:\Volatile Environment' USERPROFILE
C:\Users\jdoe

# Verify that the API call to retrieve the known folder
# "Personal" (Documents) returns the expected value.
> [Environment]::GetFolderPath('Personal')
C:\Users\jdoe\Documents

# See if the registry contains the expected definition.
> Get-ItemPropertyValue 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' Personal
C:\Users\jdoe\Documents

Bricky

Answer 2

According to the powershell source code on github, they look for Environment.SpecialFolder.Personal

It starts in ConsoleHost.cs and you can track this down to utils.cs where they call Environment.GetFolderPath(Environment.SpecialFolder.Personal);

Reasoned

Answer 3

I had the same issue today and I was able to create the profile with the following PowerShell command:

New-Item -path $PROFILE -type File -force

I hope this helps!

Rigobertorigor

Note that yours was a different issue: The value of your $PROFILE variable was correct (unlike in the OP's case), but the file pointed to - possibly along with its parent directory - simply didn't exist yet. This is what New-Item -Force addresses: it creates the file, including its directory, if needed. Note, however, that if the file already exists, you'll wipe out its contents. GitHub issue #11677 asks for a new switch to be added to New-Item to allow preserving a preexisting file. – Bricky