Last Updated on January 17, 2023 by rudyooms

This blog will be about me troubleshooting the “Something Went Wrong” error you could get during the Account Enrollment Status Page when enrolling your Windows 11 Enterprise devices with Autopilot.

I will divide this blog into multiple parts

1. Introduction
2. The Issue
3. Troubleshooting
4. AppxDeployment
5. The Solution
6. Windows 11/10 Enterprise/Pro
7. Me, earl, and the WindowsUDK
8. What triggered the screen?

1. Introduction

I was asked to take a look at a funny but weird issue by Jose. He reported this issue to Microsoft last year (30-11-2022) but it was never solved. As shown below, he also posted it on Twitter and tagged some people in it.

So guess who spend 2 days taking a look at what was happening? Yep… me! Did I solve it? Let’s find out!

2. The Issue

Before getting to the bottom of this issue, I will start by showing what happens and what exactly breaks. At first, I thought that Jose was talking about the well-known “Identifying issue” during the Account Phase as mentioned here but that really wasn’t the case.

When you have enrolled your device with Autopilot and you completed the Device ESP phase you could run into this nice error screen below

This famous “Something Went Wrong” error screen will be shown after the device completed the device esp phase successfully and needs to switch to the USER ESP after signing in again.

Please note: This issue only occurs on Windows 11 Enterprise! Not on Windows 10 Enterprise or Windows PRO editions! More on this later on in part 6. Besides new devices, you could also run into this error when signing in with a new user on an existing Windows 11 Enterprise devices.

In a normal situation, the User/Account ESP will be shown and you will be asked to configure Windows Hello for Business. Luckily Jose also created this nice corresponding video about what happens to get it more clear.

After some PM’s on Twitter, he mentioned the fact that after assigning the CIS baseline to his devices this error screen showed after the device ESP phase.

Jose provided me with a username and password for a user in his test tenant(and some stupid MFA requirements :P) so I could take a look at it myself. After enrolling the VM, it was indeed showing me the exact same behavior and error. So I asked if it was possible for me to get the JSON for it (No not going to share it…) After uploading the JSON to my own test tenant I also spotted the same behavior.

3. Troubleshooting

After wiping the VM again and enrolling it again with Autopilot, I simply opened the event log and started searching for errors. It’s a good thing Microsoft implemented a “Retry” button (even when it doesn’t fix it, this time..)

When watching all the event logs I noticed that in the Shell-Core event log this message with event id 62403 was shown each time I clicked on “Retry”

It’s mentioning the fact that the CloudExperienceHost was unable to get the property “Credentials” and is pointing to an error on line 580 in the CloudExperienceHost AppManager.js File. I decided to open that appmanager.js file to determine what was mentioned on line 580

As shown above, I noticed 2 things. 1 thing funny and 1 line mentioning something I “thought” I never heard of

The first one was mentioning the “Golden Path Xbox account”… Mmm… there are 4 CIS policies that are also mentioning Xbox

But after ruling them out by configuring them to be enabled in my own tenant, it didn’t solve the Something Went Wrong screen. Let’s move on to the stuff I “thought” never heard off

The second one was mentioning the WindowsUdk.Security.Credentials.UI.CredUICoordinator with some DevicePixelRatio information in it.

4. AppxDeployment

I just couldn’t understand why it was showing us the something went wrong error and pointing us to some stuff with DevicePixelRatio in it. Again I reinstalled the VM but this time I opened Procmon and added the wwahost.exe process to the filter

As shown above, it was showing me the fact it was trying to open some Avalon.graphics keys. Pixelratio and Graphics, look like a match right? Still, I found it weird that everything breaks because of some PixelRatio? That can’t be right!? After again taking a look at the error we noticed in the shell-core event as shown below, I realized something.

I came to the conclusion I totally forgot to take a look at the AppxDeployment-Server event log. APPX: I guess the name says it all. When a new user logs in to the device, Windows will try to register those Appx Packages for the user.

So I opened this event log and started searching for the exact time frame that the error message was also shown in the shell-core event log

Within a few seconds of searching, I stumbled upon this error message above. It mentioned that the Appx Deployment failed for the package MicrosoftWindows.UndockedDevKit . Besides this package name, it was also showing me the well-known access denied error: 0x80070005. Let’s save this error message in our brains and let’s continue.

Just one millisecond before we got the 0x80070005 error, we will notice that the RegisterByPackageFamilyName operation is occurring within my user context.

The package seems to have issues getting installed. To be sure I checked on a working and not working device. On the left is the device that is having issues and on the right, is the working one.

We have an error and now we need to find out why it is giving us the access denied error. It’s always good practice to start looking at your own documentation (in this case call4cloud.nl) when you run into errors

Why reinvent the wheel, when you already build a car?

When reading that blog marked in green, I noticed I indeed stumbled upon that same error when trying to remove the possibility to let users (Non-Admin) install Appx Packages on their own

Before opening the Intune portal, I decided to make sure this policy was indeed configured on the device itself. I opened the registry and opened the PolicyManager key. As shown below, this BlockNonAdminUserInstall key was indeed configured to 1

5. The Solution

I was thinking about disabling the User Status Page as it could be a good option but that solution is just bypassing the real issue. I guess it’s safe to say, that the Something Went Wrong error is being caused by something that blocks the “Microsoft Store Appx Packages”. When scrolling down the CIS JSON baseline I got I noticed the same policy I was referring to in the Me and Earl and the Microsoft Store Apps blog

That can’t be a coincidence! Let’s look it up in the Online CIS Benchmark about this policy. Looking at the CIS Microsoft Windows 11 Enterprise Benchmark v1.0.0 and the CIS Microsoft Intune for Windows 10 Benchmark v1.1.0 they both mention the same.

The CIS Baseline/Benchmark is indeed recommending it to enable this particular setting! So I decided to remove the assignment of the CIS baseline and create a CSP with only this specific setting in it but this time Disabled! Guess what happened after reinstalling and reenrolling the same VM that was previously failing?

Yes, the Account Setup ESP account was shown! The Something Went Wrong error was gone!!! Looking at the AppxDeployment-server event log is also showing us no errors about the UndockedDevKit

When enabling that same CSP with only the BlockNonAdminUserinstall setting in it, the Something went wrong error was back in action! The BlockNonAdminUserInstall is the cause…. 1000% sure!

6. Windows 10 Enterprise vs Windows 11 Pro/Enterprise

Changing or removing that BlockNonAdminUserInstall from the CIS baseline does resolve the problem but why isn’t this issue occurring on Windows 10 or Windows 11 Pro devices?

Let’s start by looking again at the AppManager.js file in the cloudexperiencehost folder and comparing the Windows 10 and 11 versions.

As shown above, Appmanager.js DOES NOT mention anything about the WindowsUDK.Security in it. So if UDK isn’t in it, it can’t break anything I guess. So that solves the Windows 10 question but what about the Windows 11 Pro part? Do you remember the 0x82b00006 error I mentioned in the 65000 days of nights blog?

That error is the corresponding error code for telling us we have a licensing issue! (Policy is rejected by licensing) When looking at the wonderful documentation about this CSP we will notice some funny stuff. As shown below, this policy isn’t available on PRO devices!

Huh … but Windows 11 Business is accepted? Guess at which moment the device will upgrade itself to Business… After logging in with an account that has a Business Premium license, the device would “upgrade” itself to Windows 11 Business. At the moment the BlockNonAdminUserinstall CSP is being deployed (device phase) the device is still Windows PRO.

So to resume, this CSP is only giving issues on Windows 11 Enterprise devices!

We solved the problem, and we solved the mystery about why it was only giving issues on Windows 11 Enterprise devices but still, I wanted to know more about the WindowsUDK

7. Me, earl, and the WindowsUDK

Please note: This part of the blog is just me looking at the 100% NOT documented UDK. Still, wondering why it’s not documented. I am just trying to sum up what I came across, nothing more so if you are not interested in me rambling about UDK, you could skip this part.

The WindowsUDK AKA the Windows Undocked Dev Kit AKA. I started my UDK journey by looking at the MicrosoftWindows.UndockedDevKit Appx package itself and the corresponding DLL files with the IDA Tool and the Dotnet Peek tool

When first opening the Appx Package, we will notice the “getcurrentview” and the mention of HelloEnrollment… I wasn’t expecting the mention of Windows Hello but then again after the Something Went Wrong error, the Windows Hello screen wasn’t shown!

Let’s move on and let’s take a look at the DLL file if we could spot something else. As shown below, again looking at the “GetCurrentView” function inside this DLL is mentioning the QueryWindowService

Looking at the services, we will find the corresponding UDK-UserService (Shell-Components). Again the mention of the “Shell”. I guess it must be very important because when searching for WindowsUDK in the registry, showed me a lot of entries in the WindowsRuntime key

Shell, Shell, Shell, and again Shell! I guess when removing the Dev Kit from Undocked and adding Shell to it we will get some more information. Thanks to Albacore we get some more information about the Undocked Dev Kit

The Undocked Dev Kit (UDK) is just a Windows Runtime API that allows Microsoft to add features on the fly to the “Shell” (for example Startmenu, Taskbar, and File Explorer) but looking further and trying to find out more information about it let me to the wonderful mention of the WindowsInternal.ComposableShell AKA “CShell”

Microsoft’s Windows 10 ‘CShell’ adaptable UI in images and video (exclusive) | Windows Central

Looking at the MicrosoftWindows.Client.CBS appx package it is also mentioning the Composable Shell and the Undocked part.

Undocked Shell / Decoupled Shell as in “You get the same experience across PC and phone.”

So I guess it’s safe to say that the “Shell” can be packaged inside a nice Appx Package that doesn’t depend on a specific OS as it is “Undocked/Decoupled”. This Windows Shell is able to scale in real-time between all types of devices… all types in devices as in different DevicePixelRatio. I guess that explains why I noticed it in the Procmon session.

It is still fun the notice that the old version of it (UX.Client.ST), is still available in the Microsoft Store (searching for it doesn’t work..)

8. What triggered the screen?

Now we know what caused it and have some more information about the WindowsUDK itself, I was wondering what could trigger that “something went wrong” screen when the BlockNonAdminInstall CSP was configured. Something should be the root cause for showing that screen, right? We know for sure that It’s happening at each new user login.

In my opinion, only 2 settings could trigger that screen that could end up with the funny “something went wrong” window.

1. The Account ESP.

As this one is pretty obvious because after you sign in with the username and password, the Account Status Page will be shown. It’s enabled by default but of course, you can disable it by configuring the SkipUserStatusPage ESP and setting it to false.

2. Windows Hello

As shown below and probably you have noticed it earlier, when looking at the WindowsUDK file you could notice the mention of HelloEnrollment. Thinking about it, it could be a possible trigger, right? As the “Something went wrong” screen surely looks like the Windows Hello prompt.

If you have enabled Windows Hello for business in the tenant-wide Intune settings, the user will be prompted to configure Windows Hello

So I decided to reinstall the VM over and over and over again and change 1 setting each time. (tested each setting multiple times to be sure) As shown below these are the results of my many attempts to fix/break it.

When you have disabled Windows Hello tenant wide and made sure the SkipUserStatusPage is set to true you are good to go! No Something Went Wrong error Windows will be shown when you have deployed that CIS Baseline!

Conclusion

Having a device that hangs at the Account Phase during ESP or giving you the “Something went Wrong” error has a 99,9% chance of being caused by Store Apps/Appx Packages. As mentioned before blocking/removing/disabling the Microsoft Store or restricting the possibility to install Store Apps as a regular user isn’t a good thing