Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsSome links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
If PowerShell says dsregcmd is “not recognized,” first try running the Windows executable by its full path:
& "$env:windirSystem32dsregcmd.exe" /statusdsregcmd is a Windows command-line executable, not a PowerShell cmdlet. A bare-name error often means PowerShell cannot find it through the current PATH; it does not prove the file is missing. Check the file directly before attempting repairs.
First, identify which failure you have
These errors point to different problems:
dsregcmdordsregcmd.exeis not recognized: PowerShell may not be resolving the executable by name. The file can still exist.- The explicit full-path command fails: Check whether the file exists, whether
$env:windiris correct, and whether the script is running in a different environment than expected. - The command runs but reports unexpected values: Command discovery is working. You now need to interpret the device-registration output and the context in which it was collected.
Microsoft documents dsregcmd.exe /status for Windows 10 or later and Windows Server 2016 or later. Its usual location is System32 under the Windows directory. See Microsoft’s dsregcmd troubleshooting guide and device FAQ.
Free tools Windows power users keep installed
One-click scans. No signup required.
Run dsregcmd correctly in PowerShell
Use the call operator (&) with the full path:
& "$env:windirSystem32dsregcmd.exe" /statusThe call operator tells PowerShell to execute a command represented by a quoted path. You can also use a literal path, though building it from $env:windir avoids assuming Windows is installed on C::
#1 Best Overall
& 'C:WindowsSystem32dsregcmd.exe' /statusThis form is also valid, but is more verbose for a simple diagnostic:
Start-Process -FilePath "$env:windirSystem32dsregcmd.exe" -ArgumentList '/status' -WaitPowerShell can run native commands; the executable simply has to be discoverable or specified by path. Microsoft explains command lookup and precedence in about_Command_Precedence.
Check whether PowerShell can find the command
Run these checks in the same PowerShell session where the bare command fails:
Get-Command dsregcmd.exe -ErrorAction SilentlyContinue
where.exe dsregcmd.exe
$env:PATH -split ';' | Where-Object { $_ -match 'System32' }Get-Command checks PowerShell command resolution, while where.exe searches locations in the process’s PATH. If the explicit full-path invocation works but these lookups do not, the issue is command lookup, not a missing Windows file.
Rank #2
- Book - powershell for sysadmins: workflow automation made easy
- Language: english
- Binding: paperback
You can temporarily add the system directory to this PowerShell process’s path to test that diagnosis:
$env:Path += ";$env:windirSystem32"
dsregcmd.exe /statusThis change applies only to the current process. Usually, do not modify the machine-wide PATH just to run this utility. A script that uses an explicit path is clearer and less dependent on the caller’s environment.
Verify the executable exists
Construct the expected path from the Windows directory and test it:
$dsreg = Join-Path $env:windir 'System32dsregcmd.exe'
Write-Host "Windows directory: $env:windir"
Write-Host "Executable path: $dsreg"
if (-not (Test-Path -LiteralPath $dsreg -PathType Leaf)) {
throw "dsregcmd.exe was not found at $dsreg"
}
Get-Item -LiteralPath $dsreg |
Select-Object FullName, Length, LastWriteTime, VersionInfo
& $dsreg /statusIf Test-Path returns True, the file exists; focus on command resolution, invocation syntax, or context. If it returns False, confirm that $env:windir identifies the Windows installation and that the script is running on the expected computer. If where.exe finds a different copy, prefer the intended full path rather than relying on name lookup.
Rank #3
When a script works interactively but fails in a deployment
PowerShell launched by Configuration Manager, Intune, Task Scheduler, or a remote-management agent may run as another account, under a different process architecture, or with a different environment and PATH. A successful test in your signed-in session does not establish that the deployed process can see the same executable or produces the same user-related status.
Log the execution context from the failing process:
[pscustomobject]@{
User = [Security.Principal.WindowsIdentity]::GetCurrent().Name
Is64BitProcess = [Environment]::Is64BitProcess
Is64BitOperatingSystem = [Environment]::Is64BitOperatingSystem
PowerShell = $PSVersionTable.PSVersion.ToString()
WindowsDirectory = $env:windir
CurrentDirectory = (Get-Location).Path
Path = $env:Path
} | Out-File "$env:ProgramDatadsregcmd-context.txt"Then test and invoke the executable from that same process:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →$dsreg = Join-Path $env:windir 'System32dsregcmd.exe'
Test-Path -LiteralPath $dsreg
& $dsreg /statusA 32-bit management agent on 64-bit Windows is an edge case worth checking if the path behaves differently in deployment. Record Is64BitProcess and test from the actual failing process before trying architecture-specific workarounds; an interactive test does not prove that filesystem redirection or the agent’s environment is irrelevant.
There is also an important distinction between launching the executable and getting useful registration data. Microsoft says user-state information should be collected in the user context; elevated execution is relevant to system-context pre-join diagnostics. A run as SYSTEM may therefore show different or incomplete user and SSO information than a run in the signed-in user’s session. See Microsoft’s guidance on dsregcmd output and context.
If dsregcmd.exe is genuinely missing
Do not start with Windows repair tools just because the bare command failed. Use Test-Path first. If the executable is actually absent from the expected Windows directory, confirm the operating-system details:
Get-ComputerInfo |
Select-Object WindowsProductName, WindowsVersion, OsBuildNumberThen, from an elevated Command Prompt or PowerShell, run System File Checker:
sfc /scannowIf SFC reports that it could not repair files, use the supported Windows image-repair process with DISM, then run SFC again:
DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannowThese are recovery steps for a missing or damaged Windows component, not routine fixes for a PATH or script-context problem. A Microsoft Q&A discussion of this error also recommends checking the file and using SFC when it is absent: dsregcmd not running from PowerShell.
Capture output in a script
The call-operator form writes the program’s output into PowerShell’s pipeline, so you can display or save it:
$dsreg = Join-Path $env:windir 'System32dsregcmd.exe'
$statusOutput = & $dsreg /status 2>&1
$statusOutput
$statusOutput | Out-File `
-FilePath "$env:ProgramDatadsregcmd-status.txt" `
-Encoding utf8If you also need the native process exit code, capture it immediately after invocation:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →$statusOutput = & $dsreg /status 2>&1
$exitCode = $LASTEXITCODE
[pscustomobject]@{
ExitCode = $exitCode
Output = $statusOutput -join [Environment]::NewLine
}For human troubleshooting, retain the complete output and note the account, elevation, Windows version, and process architecture. Avoid treating a single text match as a universal join-state test: sections and values depend on device state and execution context.
If dsregcmd runs, interpret the output as a separate problem
dsregcmd /status reports registration and authentication information; successful launch does not mean that a device is correctly joined. Microsoft’s output reference explains the device-state, user-state, tenant, SSO, and diagnostics sections.
AzureAdJoinedis a device-state field for Microsoft Entra join status.AzureAdJoined : NOby itself does not prove the device has no registration of any kind.DomainJoinedandEnterpriseJoineddescribe other device states. Read the relevant fields together rather than inferring a complete registration result from one value.WorkplaceJoinedappears in user-state information and is relevant to a user’s Microsoft Entra registration. It is not interchangeable with a device join.DeviceAuthStatus,WamDefaultSet, and SSO or PRT fields provide additional information whose meaning depends on the section and context in which the command ran.
If the output points to an Entra registration issue, follow the Microsoft troubleshooting guidance for that state. Do not use dsregcmd /leave to fix “not recognized”: /leave changes registration state and is a separate remediation operation, not a command-discovery repair. Microsoft discusses that operation in its Enterprise State Roaming troubleshooting guidance.
Does PowerShell version or an Entra module matter?
No Entra or Active Directory PowerShell module is required just to launch this Windows executable. For the basic command, the key checks are that the supported Windows installation has the file and that the running process can access it. Microsoft documents the utility for Windows 10 or later and Windows Server 2016 or later. Get-ADComputer is not a substitute: it does not report the local device-registration, user-state, PRT, or diagnostic information provided by dsregcmd.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
