0X00000945: NERR_ProfileUnknownCmd Parsing Error Fix

What triggers this error

You'll see 0X00000945 — or the friendlier NERR_ProfileUnknownCmd — right after a user logs into a domain-joined Windows machine (Windows 10, 11, Server 2016/2019/2022). The event log shows it under User Profiles Service or Netlogon. The login completes, but the error appears either as a pop-up or buried in the event logs. It almost always happens when you're using a mandatory profile, a logon script (`.bat`, `.cmd`, `.vbs`, or PowerShell), or a Group Policy Preference that runs a command at login.

Root cause

Plain and simple: the command line in your logon script or profile file contains something Windows doesn't recognize. Could be a typo in the executable path, a missing quote, an unescaped special character, or a command that doesn't exist on that OS version. The parser hits that line and throws its hands up — 0X00000945.

I've seen this most often when someone copies a logon script from an old Windows 7 domain to a modern Windows 10/11 environment without checking for deprecated commands (like net use syntax changes, or trying to run wmic which is gone in newer builds).

Step-by-step fix

Step 1: Identify the offending file

Check these locations in order:

• Active Directory Users and Computers — user Properties > Profile tab > Logon script field.
• Group Policy Management — look for Logon Scripts under User Configuration > Policies > Windows Settings > Scripts.
• Group Policy Preferences — User Configuration > Preferences > Control Panel Settings > Scheduled Tasks (if a task runs a command at logon).
• Mandatory profile path — if you use a `.man` profile, it might have a NTUSER.DAT that runs a startup command.

Make a note of the exact file name and path.

Step 2: Locate and open the script file

The script lives on the NETLOGON share of your domain controller (usually \\domain\sysvol\domain\scripts) or in the Group Policy folder (\\domain\sysvol\domain\Policies\{GUID}\User\Scripts\Logon). Open it in Notepad or VS Code. Do not use Word — it will add invisible formatting characters that break things.

Step 3: Find the bad line

Look for these common culprits:

• Missing closing quotes around a path with spaces. Example: "C:\Program Files\MyApp\app.exe (missing the final ").
• Commands that don't exist on Windows 10/11 — wmic, nslookup with deprecated switches, net config.
• Unescaped special characters like %, ^, & inside batch scripts. In batch files, % needs to be doubled (%%) in some contexts.
• Calling an executable that's no longer installed or the path is wrong.

Test each suspicious line by running it manually in a Command Prompt as the affected user. If it fails there, you found it.

Step 4: Fix the command

Edit the script file. Fix the syntax, remove the broken command, or replace it with the correct modern equivalent. For example, replace wmic calls with powershell Get-WmiObject or powershell Get-CimInstance.

Here's a before/after example:

Before (broken):
net use Z: \\server\share /persistent:yes

After (fixed — note quotes if the share path has spaces):
net use Z: "\\server\share" /persistent:yes

Step 5: Replicate and test

Copy the fixed file back to the NETLOGON share or Group Policy folder. For Group Policy, run gpupdate /force on the DC and the client. Log off and log back in as the affected user.

Check the Event Viewer on the client under Applications and Services Logs > Microsoft > Windows > User Profiles Service > Operational. Look for error ID 0X00000945 again. If it's gone, you're done.

If it still fails

Three things to check next:

1. Permission problems — The user account that runs the logon script (usually SYSTEM or Domain Users) needs read access to the script file. Check NTFS permissions on the NETLOGON share.
2. Script encoding — Save the script as ANSI or UTF-8 without BOM. A UTF-8 BOM (byte order mark) at the start of a batch file can cause parsing errors. Use Notepad's "Save As" and pick "ANSI" for `.bat` files.
3. Group Policy loop — If the script is assigned via multiple GPOs, you might have a conflict. Run gpresult /H report.html on the client and see which GPOs are applying logon scripts. Disable one at a time to isolate the culprit.

If none of that works, enable verbose logging for the User Profiles Service. Set this registry key on the client (reboot required):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Value: EnableVerboseLogging
Type: DWORD
Data: 1

Then reproduce the error and check %windir%\debug\usermode\userenv.log for the exact line that choked. That log is your best friend for this error.