Windows 10 Update 1903 renames User fiolder

im having this same problems with march 2020 update kb4551762 as I did with febuary update kb4532693 with a temporary account with no data and desktop configurations uninstall and everything is back to normal why

It seems that both the 1809 and the 1909 updates had a problem where an incomplete transfer of the users directory left the update as apparently having worked but the user was left with a broken world where there was a jamie.000   and a jamie directory.  (where jamie was my users home directory).  In my case most of my files where in the .000 directory but there were still some left in the jamie directory.  Because there were file(s) left behind it failed to fully transfer the user which ended up with a broken world. In my case Outlook files were in the .000 version but pointed to the old jamie version. 

SO

1. I made a ghost image of my system disk for backup (I used Samsung SSDs and they provide an app for System migration) 3hrs
2. I started the update to 1909 - it took around 5hrs
3. I logged on and ignored problems with Dropbox and Email checked what was left in the original directory /users/jamie

My thought being that whatever was left would presumably be the legacy files that had somehow got stuck and caused an incomplete transfer of data to the new user directory (which then left the transfer incomplete and so cause the issues.  I would then be able to check via google on anything left behind.

In my case there was \users\Jamie\AppData\Local|NPE\NPETraceSessionBoot.etl  (around 50Mb)

4. I used Recovery to go back to the previous version of WIndows 10  - around 10minutes.  There is a time limit for how long this recovery is possible - 10 days I think, so don't hang around too long.
5. Using the info in the reply I deleted the NPE directory, after noting that the etl file had grown to 80Mb.  So although I had long ago removed the Norton Power Eraser (NPE) one if its actions was to turn on a logging action and that was still active.  Then I edited the Registry and removed the NPETraceSessionBoot key and subkeys. Which was presumably logging to and locking the file during the update/restart.
6. Then I reloaded and started the update (5hrs) and it all worked.  

What surprises me is that Microsoft do not seem to have picked up on this as a class of problem and dealt with it promptly. I imagine there might be several different legacy apps/files that could cause this type of failure but all the misdirection in the forum about  a corrupt account or reboot the machine several times has led to a whole bunch of problems for a number of users including loss of data.  At the very least the update programs should have issued a warning about the incomplete user transfer.

For me the reason was having remains of a previous installation of Norton Power Eraser (NPE) ...

This debug was enabled by NPE though a registry key. I disabled the debug output by deleting the "NPETraceSession" registry key and all sub keys at:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\NPETraceSession]

Thank you for posting this additional info. If I had known about the reg key location last year, I could have deleted the WMZuneComm ETL process holding my user directory hostage. I eventually resigned and let Windows create the user.000 folder however, even after the upgrade WMZuneComm was still creating the logs in the old user directory. After your ppost I was able to find an entry in the registry location you provided and delete it permanently. Good riddance.

For me the reason was having remains of a previous installation of Norton Power Eraser (NPE) already uninstalled years ago. In the newly created user.000 folder, I found a folder with a file "NPETraceSessionBoot.etl" which pointed me in the right direction.

This file is a debug output written by Windows WMI at each startup, blocking the proper profile usage. This debug was enabled by NPE though a registry key. I disabled the debug output by deleting the "NPETraceSession" registry key and all sub keys at:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\NPETraceSession]

and also the NPE folder present at: [userdir]\AppDataLocal\NPE

After this, the update worked seamless.

Thank you! This process worked for me, since NPETraceSessionBoot.etl was the one file that was left in my original username folder after the 1909 upgrade attempt on Jan 17, 2020 created a username.000 profile.

I called and reported this to Microsoft Support. The tech seemed very knowledgeable, and I was assured that a ticket was being created to release a patch for this problem as soon as possible. It seems like most other debug trace loggers that cause the username.000 problem have been dealt with, but they hadn't yet included the Norton Power Eraser one in their patches.

Note that I left the detritus of my old Zune installation, files and registry keys, on my machine before upgrading to 1909. I used the latest version of the Windows 10 Update Assistant from the Microsoft Website, Windows10Upgrade9252.exe, on Jan 18, 2020. It was able to automatically delete the offending Zune files and trace logger registry keys, so the Zune .etl files did not cause a problem during upgrade. Microsoft has apparently dealt with the Zune issue.

For me the reason was having remains of a previous installation of Norton Power Eraser (NPE) already uninstalled years ago. In the newly created user.000 folder, I found a folder with a file "NPETraceSessionBoot.etl" which pointed me in the right direction.

This file is a debug output written by Windows WMI at each startup, blocking the proper profile usage. This debug was enabled by NPE though a registry key. I disabled the debug output by deleting the "NPETraceSession" registry key and all sub keys at:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\NPETraceSession]

and also the NPE folder present at: [userdir]\AppDataLocal\NPE

After this, the update worked seamless.