USMT 4.0: Cryptic Messages with Easy Fixes
Published Apr 04 2019 03:30 PM 831 Views
First published on TechNet on Mar 01, 2010
Ned here again. As you begin the process of moving off your older operating systems to Windows 7 you may end up using USMT 4.0 . With its powerful capabilities and intended audience of IT professionals, the tool can be unforgiving and often gives inscrutable messages. Today I’ll cover a few of the most common but unclear errors people see when they first run the tool.

Return code 27: Invalid store path

You ran a scanstate and now you’re trying to restore the data to a new target computer. You run:
Loadstate.exe c:storeusmt /auto

And…you get a store error. Examining the loadstate log shows:
[0x000000] USMT Started at 2010/01/31:15:53:58.796
[0x000000] Command line: loadstate c:storeusmt /auto
[0x000000] Failed.[gle=0x00000002]
[0x000000]   An error occurred processing the command line.
Invalid store path; check the store parameter and/or file system permissions [gle=0x00000002]
[0x000000] USMT Completed at 2010/01/31:15:53:58.812[gle=0x00000002]
[0x000000] Entering MigShutdown method
[0x000000] Leaving MigShutdown method

But you look and that path definitely exists with a valid store MIG file inside it.

This is an easy mistake to make; when you specify a store path during scanstate, USMT automatically makes a sub-folder called “USMT” that contains your data. Admins often assume they need to specify the full path - you don’t. Just provide a path to the same folder level that was used in the scanstate. So in the above case:
Loadstate.exe c:store /auto

Return code 28: Unable to find a script file specified by /i

You are running a scan or load with a perfectly valid command-line, but every time you start it:

You get error 28. You examine the directory where scanstate.exe is located and the XML files are definitely there. You examine the scanstate.log and see:
[0x000000] USMT Started at 2010/01/31:15:59:28.118
[0x000000] Command line: c:tempusmtscanstate.exe c:store /v:5 /i:migdocs.xml /i:migapp.xml /o
[0x000000] Script file is not present: 'C:usersstdmigdocs.xml'[gle=0x00000002]
[0x000000] Failed.[gle=0x00000002]
[0x000000]   An error occurred processing the command line.
Unable to find a script file specified by /i[gle=0x00000002]
[0x000000] USMT Completed at 2010/01/31:15:59:28.149[gle=0x00000002]
[0x000000] Entering MigShutdown method
[0x000000] Leaving MigShutdown method

This error is returned because both scanstate.exe and loadstate.exe assume that the working folder is the current directory -- where the command is execute -- and not the directory wherein the executable is located. Since the XML files do not exist in my profile -- the current directory -- the command fails. To fix the issue, first switch to the directory containing your USMT files using the CD command, or specify full paths to the XML files with each /i .

Return code 26: Software malfunction or Unknown exception

Hooboy, that is a really helpful error. You examine the scanstate log and see:
[0x000000] USMT Started at 2010/01/31:16:11:54.383
[0x000000] Command line: scanstate c:store /o /i:miguser.xml /i:migapp.xml /v:5
[0x000000] Entering MigStartupOnline method
[0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
[0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
[0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
[0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
[0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
[0x0803ac] Initializing online WinNT platform (Read/Write)
[0x080000] Platform is not using admin privileges

Aha! As you hopefully know from your reading, USMT requires you to be an Administrator to run the scanstate with full functionality or to run loadstate at all. The problem here is that while you are logged on with an account that is a member of the Administrators group, User Account Control is turned on and this CMD prompt is not elevated . That means that your user account shows up as an Administrator but can’t do anything. If you were to lookup that 0x514 error you’d see it means “Not all privileges or groups referenced are assigned to the caller”. Indeed, they are not.

Elevate your CMD prompt, use an account that bypasses UAC, or turn off UAC – the issue will go away.

User running the scanstate is the only profile ever migrated

Why. Do. You. Ignore. My. Command. Line?!? ARRRRGGGHHHH!!!

This one is just unfair. As I mentioned above, you must be an administrator to run loadstate – it gives you a very specific error otherwise:

But if you run scanstate as a user that is not a member of the Administrators group, you get no errors. Goo gets gathered up; everything seems fine.

Except that nothing you put on the command-line for /ui is considered at all, and if you were to closely examine the store data, you’d find tons of operating system settings missing. I have two different accounts on this computer that contain “ned” in some way, that examination should have gotten them both.

Yes, this is by design -- more information is tucked away here . There is almost no good reason to run any USMT command as a standard user; just get into the habit of using an (elevated) administrator.
Migrating your computers to Windows 7 can be a very interesting exercise. Hopefully this blog post makes things a bit easier.

Oh - and why did I only say “may end up using USMT 4.0” at the start of this post? Because you have other options:

Until next time.

- Ned “T he Riddler ” Pyle
Version history
Last update:
‎Apr 04 2019 03:30 PM
Updated by: