Last Updated on August 16, 2022 by rudyooms

This blog will be about the 0x800705b4 (Time-Out) error I got during the Autopilot “Preparing your device for mobile management” step. Please note that this is still a blog in progress so I need to update it after getting some response back from Microsoft

I will divide this blog into multiple parts

1. Introduction
2. The Issue
3. Troubleshooting part 1
4. Troubleshooting part 2
5. Troubleshooting part 3
6. Microsoft Ticket IT408981

1. Introduction

When looking at the New! Highlights of this wonderful KB5015858 we will notice that this update would also restore the functionality of Windows Autopilot deployment scenarios that are affected by the security mitigation for hardware reuse

If we didn’t remove that Intune Object we would be stuck with the 0x80180014 error

But that’s not all because even while the Microsoft Store Apps fix was not mentioned in the Highlights… some little bird told me it was fixed. If you are interested to know what I am talking about please read this blog first.

I made sure I installed a nice new shiny VM and made sure I installed the 2022-07 preview update KB5015858

2. The Issue

After my device was updated with the 2022-07 preview update, I performed a remote wipe. After the remote wipe was done successfully I ended up at the login screen to start the Autopilot enrollment

After entering my username and password and of course, approving and putting in the sms response for MFA Approving the MFA challenge the device started enrolling into Azure Ad And Intune. After a few seconds, it completed the first step of “registering your device for mobile management” and started the “preparing your device for mobile management step”.

I waited and I waited…it was still mentioning that it was “working on it“. After a lot of time waiting, the famous time-out error 0x800705b4 popped up.

I was like what the? I wanted to test if the Microsoft Store apps were working again after a wipe. I totally wasn’t expecting this error. This error almost looks like what the 2022-07 preview update was meant to fix! Of course, the same goes for Windows 11 when we have the installed 2022-07 preview update: KB5015882

Please Note: I also tested the same flow with the monthly 2022-07 update and that isn’t giving us this time-out issue !!! So it’s definitely due to the “Preview Update” version!

Some time ago, I also wrote some stuff about this error but at this time that error ISN’T due to the lack of enough CPU power in my VM.

Autopilot and the 0x800705b4 error while Preparing the MDM (call4cloud.nl)

Please read this blog first as it also contains the flow the device goes through at the first ESP phase. I guess it could be useful ?

3. Troubleshooting part 1

Even while I wasn’t expecting this error, it looked like a fun error to troubleshoot. So let’s go! In the Certificate Zombies blog from last week, I showed you how you could start troubleshooting device sync errors.

I decided to just use this PowerShell command to troubleshoot this error as well

wget https://aka.ms/intuneps1 -outfile IntuneODCStandAlone.ps1

powerShell -ExecutionPolicy Bypass -File .\IntuneODCStandAlone.ps1

Hopefully, it would show me some logs. After taking a better look at all the logs it produced my eye caught something

As shown above, I noticed some nice DeviceEnrollment and DeviceProvisioning Event Trace Logs inside the files/general folder. I opened the WPA Tool and opened the DiagnosticsLogCSP event trace log to begin with.

At first, I stumbled upon some weird behavior mentioning some node was not found and the corresponding error 0x86000002

Unfolding the Provider Name: Microsoft.Windows.EnterpriseDesktopAppManagement showed me some more information

That information led me further down the rabbit hole. As shown below it mentioned that it couldn’t find the SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\S-0-0-00-0000000000-0000000000-000000000-000\MSI\{{972db620-469f-489a-addb-d421dce15e48}} registry key

I guess we all know what this MSI 972db620-469f-489a-addb-d421dce15e48 translates to, right?

As shown above, that GUID corresponds to the Intune Windows Agent.msi AKA Intune Management Extension. Please note that this screenshot was taken from a working device! When taking a look at the broken device we will notice that the whole EnterpriseDesktopAppManagement key Is missing.

I guess we don’t need that :)? Luckily there is also a SideCar log file in the log files folder, so I decided to also take a look at that one

As shown above, the IME service was not installed! I decided to check if I could install it manually. I used the DownloadUrlList link from a still working device and downloaded the MSI file. As shown below, it was installed successfully.

After the Intune Management Extension was installed I retried the ESP and immediately it completed the “Preparing your device for mobile management” step.

I hoped I was done troubleshooting! But unfortunately, now the device setup was hanging on identifying even while the Win32apps were installing in the background. So the missing Intune Windows Agent was not the root cause. Let’s find out what else we could do

4. Troubleshooting Part 2

After looking at the ETL files again, I noticed that the Windows Intune Agent wasn’t the only one that was giving me those stupid enrollment issues.

As shown above, all of the MSI files aren’t working! So we could skip the idea that it was due to the Intune agent that our Autopilot enrollment was failing.

Do you know what process is responsible for downloading the Intune Windows Agent by the use of a CSP? That’s right the OMA DM Client (OMADMCLIENT.EXE).

The OMA-DM client can be used to enable an MDM server to initiate an MSI install (Windows Installer) on a device. I guess because all of our MSI’s are failing I guess we need to take a look at what’s happening with the omadmclient.exe

As always I downloaded Procmon and changed some filters to make sure I only got details about the omadmclient.exe

As shown above, it couldn’t find the tmp file it should have created to install the Intune Windows Agent. It looks like the OMADMCLIENT.exe just crashed. To be sure if there was an application error I opened the application event log (duh…)

As shown above, it shows us the 1000 application error mentioning the omadmclient.exe and the module ntdll.dll. I guess… it’s good old nirsoft to the rescue

AppCrashView – View application crashes (.wer files) in Windows 7/Vista (nirsoft.net)

After opening the App Crash View tool I immediately noticed that the omadmclient.exe stopped working a lot of times with the error code 0xc0000374 (a Heap has been Corrupted)

“Heap corruption occurs when a program damages the allocator’s view of the heap. The outcome can be relatively benign and cause a memory leak”

5. Troubleshooting part 3

Okay, it looks like Heap Corruption but I was still wondering if maybe the omadmclient.exe was updated after installing the 2022-07 preview update. Comparing this executable on a working 2022-07 device and the not working installed 2022-07 preview device led me to the conclusion that there was no difference…

But I was still not convinced, so I opened Procmon again to determine which Modules (DLL files) it loaded and which versions they were.

Please note: This test was performed on a failing Windows 11 device.

Just before the omadmclient.exe crashed and WerFault.exe was launched I noticed a “process create” occurring

When taking a better look at this process, I noticed some nice modules.

As shown above, these are the modules loaded with the 10.0.22000.832 version. I am not saying it is because of these DLL’s but for now… it’s good to know the Appxalluserstore.dll was also updated :)… Do you remember why I started to write this blog? Correct! to determine if the bug with the Store Apps was fixed. So I am pretty hopeful right now… But for now, I guess I need to stick with the “heap corruption”

I am not an application debugger but what the heck, let’s fire up ProcDump and enable it to be a Just-In-Time debugger

As shown above, with the -i -ma parameters I am making sure that it will dump out the process when it runs into heap corruptions/exceptions. After the debugger was enabled I again logged in to start the Autopilot enrollment and within a minute it started the dump!

Now we have our dump file, we could open it in the wonderfully WinDbg Preview tool. As shown below, it was mentioned the fact the dump file has an exception and we could run !analyze -v to start the analyze.

After pressing the nice button to start the analyze, it showed me again the same c00000374 error

So there is something definitely going wrong with the OMADMCLIENT.exe but unfortunately, I guess it’s not my job to solve this issue this time. I emailed all my findings to Microsoft Support.

It very much looks like the 2022-07 preview update changed some stuff and because of that, the omadmclient.exe crashes after the device was wiped and starts the autopilot enrollment again. So for now we are still stuck with this issue. Hopefully, the omadmclient crash will be fixed with the 2022-08 update!

Of course, it’s obvious when I have some more information about why the omadmclient.exe stopped working or when I have some feedback from Microsoft, I will update my blog!

6. Microsoft Ticket IT408981

After putting in a support ticket: 32209671, and sending some emails back and forth finally the Issue was acknowledged by Microsoft

This incident mentions the exact same behavior as I noticed and the funny thing is… they are also mentioning that the update contained a code defect that was causing the issue!

“Current status: We’ve reviewed the recent changes made to the service and determined that the July feature update (KB5015878 and KB5015882) contains a code defect that is causing the issue. We’ve developed a fix to address the code defect and we’re in the initial stages of deploying it to production. “

It’s obvious that I want to know more and if I was on the right track looking at the changed files etc. So hopefully Microsoft will give me some more insight about what was causing it exactly!

Of course, I also made sure I tested if the same VM with the 2022-07 preview update was now working. I enabled the same VM again and watched the Autopilot process checking for (Zero Day Patches) update

After it was done checking for Updates, it arrived at the Azure Ad login screen. At the looks of it, the “fix” for the broking code WAS NOT delivered with ZDP but with something “new” and shiny called Autopilot Agility

But… wait … it isn’t available yet for Windows 11?. I guess Microsoft needs some changes to their Docs? But I guess “Autopilot Agility” is something for a different blog 🙂

After entering the credentials the “preparing your device for mobile management “step begins…. but this time it was completed within a minute or 2!

Conclusion

When encountering a time out during preparing your device for mobile management it will probably be because the Intune management extension failed to install! Hopefully, this blog showed you how you could start troubleshooting this issue!