"defaultuser0" created on clean install of Anniversary Update

 

Hello community,

Yesterday I performed a clean install of my Windows 10 laptop (64-bit, Pro version) to get the Anniversary Update (#1607). I reformatted the partitions and everything, and went through the OOBE without any problems. But when I logged in with my local user account I noticed something very strange: Under C:/ Users/ there is now an additional user profile called "defaultuser0." I tried doing another format followed by a clean install, and again it was there.

Now here is where it gets really weird. I decided to go back to the previous version of Windows 10 (#1511) and again did a full format with clean install, using the Windows Media Creation tool I made a few months ago. It installs fine, but when I log in, guess what I see? This darn "defaultuser0" account! This was never here before. And yet, it somehow survives the whole process. Now today I have gone back and once again formatted the partitions of my laptop and have clean installed the Anniversary Update (#1607). STILL THERE...

What causes this? I am completely at a loss. I have spent well over a dozen hours trying to figure this out, and I have even called Microsoft's Tech Support, but so far I haven't found a satisfactory answer. I can still log in and use my laptop, but the rights and permissions on some folders belongs to this "defaultuser0" which is why I want to eliminate it. The whole purpose of a clean install is to avoid issues such as these. I did some research on Google, and have only found one or two results in German written by the user "M.Ziegler" but even these don't really solve the problem. A few users give some tips on how to delete the account through editing the registries and whatnot, but that's not really what I want. I know that one cannot simply erase every single trace of an account once it is created, and so I am trying instead to find a way to prevent it in the first place. How and why is it created? Am I just stuck with it?

Please, can somebody help me? I thank you in advance!

UPDATE on August 5th, 2016: This appears to be a bug which is only affecting some users. I spent more time testing it today, and even after deleting the account keys from the registry (as someone had suggested below) and completely removing "defaultuser0", it comes back is you ever run the DISM command string "Dism /Online /Cleanup-Image /RestoreHealth". What this seems to imply that this is actually a problem with the ESD/ISO, where it treats this as necessary even though it obviously isn't. Hopefully somebody will have a REAL answer for me soon.

UPDATE on August 6th, 2016: Microsoft's Level Two Technical Support called me back today. But even the elevated tech support staff has no clue on what causes this issue. The man I spoke to told me that because build 1607 is brand new, their manual doesn't have any details on this issue yet. Apparently they're researching the problem, but it could be weeks before a solution is found and put into their manual. I'll continue to post updates here when I have them.

UPDATE on August 27th, 2016: A quick shout out to the user "ChristopherButterfield", who in the comments below posted this link: https://social.technet.microsoft.com/Forums/en-US/3e7d85e3-d0e1-4e79-8141-0bbf8faf3644/windows-10-anniversary-update-the-case-of-the-mysterious-account-sid-causing-the-flood-of-dcom?forum=win10itprosetup While the link unfortunately does not contain a fix for the issue, it does highlight some aspects that I had previously missed, and thus confirms my suspicions that this "defaultuser0" negatively impacts system performance. Of particular note is an invalid SID that seems to be linked to defaultuser0: "...almost all the core components, have an Unknown Account with SID S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681" and, "All the core system COM objects seem to have this Unknown SID. And it seems that's the source of all the DCOM errors in the event logs." which is referring to Event ID 10016. More updates to come.

UPDATE on August 29th, 2016: I spoke to a man named Jeffrey today, who is another one of Microsoft's Level Two Technical Support staff.  Unfortunately, there are still no known resolutions for this issue. I allowed him to remote access my laptop so I could show him exactly what I'm dealing with, and he made detailed notes which he promised would be passed along to Microsoft's technical engineers. He scheduled me for a callback on September 7th, and hopefully their team will have discovered a resolution for this error by that time. That's all for now. And please, if you have this same issue, click the "Me too" button, so they can see that it's affecting a lot of us and that it's worth their time to fix!

UPDATE on September 9th, 2016: Microsoft's Level Two Tech Support staff called me back on the 7th, as promised. However, the woman I spoke to was very dismissive and seemed to not know what I was talking about. As far as I can tell, nothing had been done. She told me to go see a specialist at the local Microsoft store, so I made an appointment for the following day so I could physically meet with one of their staff. So yesterday (the 8th) I went in and explained everything to "Andy B." and showed him exactly what was going on. He did a clean install with their own ISO, and surprise surprise, there was the dreaded defaultuser0. On a hunch, he went to go check something in the back. As it turns out, they have it on their OWN computers also; they just didn't realize it! With this knowledge in hand, he promised he would submit a full bug report using their own Microsoft Insights forum. Apparently, this is how they are able to communicate directly with Microsoft's software developers. Hopefully a patch will come from this, but who knows. The fact that Microsoft's own staff have this on their computers might encourage them to fix it sooner. More updates when I have them.

UPDATE on March 29th, 2017: My apologies for the long absence. To those of you who asked, yes, I eventually did just give up. I've had personal concerns to deal with, such as having to relocate to a new city and the death of a family member, and those things took priority. And honestly, I became so invested in trying to solve this issue, that it made me miserable and I had to stop for my own sanity. On the positive side, I've read that this issue should be resolved in the next major update, which is coming on April 11th, 2017. However, I haven't seen or heard official confirmation of this, so I would appreciate it if anybody could confirm this information from an official source. Additionally, I would love to know if this fix will be applied regardless of whether we upgrade to the Creator's Update from within the Windows Activation menu (that is, if we choose to keep all our files and programs), or if we will be forced to once again perform a complete clean install in order for the fix to really take effect. Thanks.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

Here is what I was told by Microsoft support re: defaultuser0 on a 1607 Win 10 Enterprise sys prepped image... Also on mine it is showing in the Administrators group..but I haven't seen anyone else mention that in the thread.

I haven't had a chance to verify this 'workaround' though. I will in the next few days...

Abstract

Defaultuser0 account profile is created to support OOBE. The account is supposed to be deleted after reaching the desktop or upon the next logon of any admin user. We are seeing instances where this is not deleted.

Cause

This is a known issue. The API calls from RemoveTempOOBEWork fails because ElevationBrokerManager returns Access is denied - 0x80070005 (2147942405).

Resolution

This issue is fixed in the newer builds of Windows 10.

Workaround: 

Change the following regkey to be deleted by the system:

HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows\ CurrentVersion\ CloudExperienceHost\ Broker\ ElevatedClsids\ {2b2cad40-19c1 - 

AutoElevationAllowed=1

1 person found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

I am going to test this.

What "Newer builds"? 1607 is the latest build. They are perhaps referring to insider builds..

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Not sure...I've been too busy with other stuff to really followup with them..and we rolled back to 1511 until I have more time.

Heres a screenshot w/ reg path because msft is not allowing it to post properly...

Also here is the netuser. Just to be clear I installed this from the 1607 ISO, booted to Audit Mode...installed like Office...copied over cmtrace...downloaded patches and updated..and rebooted...and sysprepped w/ oobe. Grabbed the WIM and deployed via SCCM w/ our normal task sequence..and logged in and this is what I see..and is why we rolled back 1607.

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Hi RCRay C_87,

Thank you for the input.

I tried myself to add the 32bit REG_WORD "AutoElevationAllowed" mentionned above.

I found that, the key : "HKLM\Software\Microsoft\Windows\CurrentVersion\CloudExperienceHost\Broker\ElevatedClsids\" contains many (11 in fact) subkeys among which the one asked for {2b2cad40-19c1-4794-b32d-397e41d5e8a7}.

So, I went on this one and had to appropriate right and permissions as administrator before being able to change anything inside. Then, I added "AutoElevationAllowed" with value "1" as you said.

The machine was restarted... and nothing special seems to appear.

Even the "AutoElevationAllowed" is still here with value "1" although, according to your Microsoft contact, I would have thought it to disappear (or switch to "0" value).

I must also say that among the 11 existing CLSID_subkeys, 7 already include the "AutoElevationAllowed=1" value.

And I guess the Microsoft automated process to remove these "AutoElevationAllowed" doesn't work for some unknwon reason.

Also :

.my defaultuser0 account and folder had previously been removed manually. So, I can't check if anything has changed there
.The junk and annoying SID S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681 is still present in right and permissions of all HKCR\CLSID and HKCR\AppID subkeys (Dcom components).

Any idea ? What about your experience ?

Regards,

Gabuzomeuh

 

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Hello everyone,

I've been following this thread since the beginning and maybe (I hope) I found a workaround that should make defaultuser0 disappear as it should do during the installation of Windows.

Like you said, if you add that regkey on an already installed Windows nothing happens, I guessed that's because defaultuser0 should be deleted during OOBE.

So I tried to add inside \sources\$oem$\$$\Setup\scripts of the iso of Windows 10 the file OOBE.cmd, which automatically runs in the middle of the installation.

Inside that file runs this command:

regedit /s "%windir%\Setup\scripts\defaultuser0fix.reg"

where defaultuser0fix.reg is this reg key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CloudExperienceHost\Broker\ElevatedClsids\{2b2cad40-19c1-4794-b32d-397e41d5e8a7}]
"AutoElevationAllowed"=dword:00000001

Then I installed that iso on VMware virtual machine to test it.

That command runs just fine and after the first reboot of the system, when the setup is done, the defaultuser0 is automatically gone, both inside the Users folder and on net user.

If someone else could test this solution (and confirm that there's no junk left since I think this is what it is supposed to happen by Microsoft) maybe we got it!

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Thank you Klomar,

Your process and script seems to be the best solution for defaultuser0 bug until now, waiting for microsoft nativ fix. I'll try it next time I have to fully reinstall.

By the way, if your VMware virtual machine is still on, would you please be able to check a few CLSID and/or AppID keys right and permissions properties in HKCR ? The point is to verify if the junk unknown-account SID  S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681 continues to appear in the registry and Dcom components.

Nice job, regards,

Gabuzomeuh

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Hi,

unfortunately that SID still appears in the permissions properties in HKCR, but I can't find any Dcom error related to that CLSID in the event viewer

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

**  UPDATED INFO **

Earlier, when Defaultuser() was removed from the USERS folder in File Manager, Windows update failed (twice) to install the latest cumulative update.  It succeeded after the Defaultuser() account was restored from the recycle bin.

Related?  Perhaps...

However, weeks later - after creating an image of the partition, a restore point, and a recovery drive - Defaultuser() was again deleted from the USERS folder and from the Profile list in the registry.  A subsequent update (10/11) succeeded.

-0-0- original info, below -0-0-

A cautionary note...

 Defaultuser() was deleted from the USERS folder here shortly before the 8/29 cumulative update, which failed to install (twice).  It succeeded after restoring Defaultuser0 from the recycle bin.  Unrelated?  Perhaps.

Don't recall an anomaly during the fresh install in mid-Sept, though it's possible.  

The HOME version I3 Laptop seems as responsive as the I7 Desktop PC Pro installation that never listed a Defaultuser() or Defaultuser0.

In the final analysis, it may be wise to cast OCD tendencies aside and simply ignore this apparently benign 'user.'

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Hi guys, I have been away from this thread for a while. Are we any closer to MS to resolving this? Thanks to everyone contributing. One question though, is this really affecting system performance and if so, in what way?

I have a high end gaming rig and I wouldn't mind knowing if I am being affected with regards to the gaming side.

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

I have this same issue.  I'm not sure that it presents any inherent security risk, but it's odd.  Let me list the issue that I'm having however.

I created a fresh image using the 1607 build ISO from a thumb drive.  I loaded my apps and a few misc settings, prepped McAfee Agent for imaging, sysprepped, and captured my image to my WDS server.  I should probably note that I can't seem to add the driver for my NIC (a Dell E7470) into the capture image, so I need to load the NIC driver manually in order to capture and upload the image).

Once I reimage the machine, it begins the OOBE process including setting the setting for privacy, location, smart screen and the like.  I set my time zone, etc (don't recall the order).  I get an error that says it can't install windows.  I've found that if I open a cmd prompt (Shift + F10) and open the local security policy editor (secpol.msc) and set the password policy to a min password length of 0 and disable the requirement of a complex password, I can then issue a shutdown command, restart, and then I will move forward to a Please Wait (sometimes it sits here for a LONG time and restarting will get me through it) and then I'm finally prompted to create an initial user account.

I have no idea why this is happening.  I'm assuming that I can create a complex long password for some account on the machine so that I don't have to work through this hokey pokey every time I image a machine, but I haven't yet figured out and was researching this when I came across this thread.

Anyone have any thoughts?  It seems like sysprep isn't completing it's task properly so it can't log into the machine for setup and based off of what others have said, it appears that it's not cleaning up after itself as well.

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

 
 

Question Info


Last updated March 15, 2024 Views 73,419 Applies to: