How to debug a USMT log like a Prohttp://blogs.technet.com/usmt/archive/2008/05/22/how-to-debug-a-usmt-log-like-a-pro.aspxThe Scanstate and Loadstate logs contain a wealth of information on each problem that is encountered, however it does take a little bit of work to root cause a problem. For example, lets take a look at an example. A few weeks ago our team got an emailen-USCommunityServer 2.1 SP1 (Build: 61025.2)re: How to debug a USMT log like a Prohttp://blogs.technet.com/usmt/archive/2008/05/22/how-to-debug-a-usmt-log-like-a-pro.aspx#3153394Fri, 14 Nov 2008 21:36:41 GMTd5e57398-b9ef-4490-9955-07cbb4e4a80d:3153394jcwarren<p>This post stimulated an idea which will hopefully solve a problem we've had on a specific user migration (Vista to Vista). The Loadstate log ended with a &quot;USMT error Code (status) = 41&quot; but unfortunately that number is not included in NET HELPMSG:</p> <p>(&quot;C:\&gt;net helpmsg 41</p> <p>41 is not a valid Windows network message number.&quot;)</p> <p>The Loadstate log showed a warning early on that the NTUSER.DAT file for the specified user was &quot;incomplete&quot; and so it was skipped. I'm wondering if there's some way to verify stuff like this during Scanstate? And would using the /c switch have helped any in this situation?</p>