A colleague of mine contacted me about slow logon times for Windows 365 Cloud Pc’s. Every next day he reported that the logon took about 3 – 5 minutes. I also asked around in the community and this is not normal behaviour. It should be like 30 seconds to logon. So, we got ourselves something fun to troubleshoot. Spoiler Alert. We also use WDAC. Coincidence?
Troubleshooting
My colleague also noticed that a particular agent couldn’t run a dll. That helps a lot! Let’s dive in!
This is the Microsoft.Management.Services.CloudManagedDesktop.Agent.Exe. The event viewer shows an “Event ID 1000” as an “Application Error” with the message that agent couldn’t run with error code 0xe0434352.
In event viewer it looks like this:
After that, we checked the code integrity log. Yes, again WDAC that blocks a Microsoft service while “All Microsoft Apps” allowed. Yet another code signing certificate?!
So, I grabbed the file from: “C:\Program Files\Microsoft Cloud Managed Desktop Extension\CMDExtension\Microsoft.Managed.Services.CloudManagedDesktop.exe” and checked if the file had a valid signature:
The file has a valid signature. So, that’s good news. I also checked whether my WDAC base policy already whitelists the signature and it does!
Now the DLL:
“C:\Program Files\Microsoft Cloud Managed Desktop Extension\CMDExtension\Autofac.dll”
The DDL does not have a valid signature:
That means we have to collect the hash from the file and add that as an allowed app.
As I looked further in the event I also noticed this event:
C:\Packages\Plugins\Microsoft.CPlat.Core.WindowsHibernateExtension\1.0.3\bin\AzureHibernateExtension.exe
Couldn’t load:
C:\Packages\Plugins\Microsoft.CPlat.Core.WindowsHibernateExtension\1.0.3\bin\Newtonsoft.Json.dll
Hmmm, I have slow logon times on Windows 365 Cloud Pc after a day or so and the AzureHibernateExtension.exe isn’t allowed to run a certain dll. That couldn’t be a coincidence, right?
Let’s check out the signatures for the files:
AzureHibernateExtension.exe
It’s signed, it looks good and the signature is also the same as in my base policy.
Now the dll:
Newtonsoft.json.dll
It is signed but with a different certificate. It’s called the “Microsoft Azure 3rd Party Code Sign”:
I first created a WDAC policy to whitelist the files above. After that I ran into another file that is blocked:
This file has yet another code signing certificate:
After I whitelisted the files above another dll showed up in the event log:
Again, we take a look at the certificate:
This looks like the same certificate as the DeviceDataContract.dll. When I whitelisted that publisher in WDAC it didn’t work to run the dll. So, I whitelisted the hash. I guess I need to do the same for these files.
So, we now have to whitelist these files to get the hibernation and the cloud agent communication to work properly.
Fixing Windows 365 slow logon times
So, we should have all the information we need to create new WDAC rules to let these files and dll’s run on our Windows 365 machines. We need to create rules for these files:
Autofac.dll
Newtonsoft.json.dll
Microsoft.Management.Services.CloudManagement.DeviceDataContract.dll
Microsoft.Management.Services.CloudManagement.SDK.AgentClient.dll
I use the WDAC Wizard to create these rules. If you are new to this application please visit this Microsoft Learn page.
Create a file hash rule for autofac.dll:
After that, you create a file hash rule for Newtonsoft.json.dll:
And another publisher rule for this dll: Microsoft.Management.Services.CloudManagement.DeviceDataContract.dll
And lastly, another file hash rule for:
Microsoft.Management.Services.CloudManagement.SDK.AgentClient.dll
I also added the supplemental policy on Github (it also includes the publisher rules). You can find it here.
Windows 365 hibernation
After I allowed these files. The errors were gone in the eventlog but slow logon times were not completely gone! It was better though! That leads us to the next chapter.
So, when I whitelisted all the dll’s I expected much faster login times. It was faster but I was still greeted by this window:
Turns out, frontline Windows 365 CloudPc’s are shutdown after being idle for X hours. The eventlog shows that the machine is powered down and prepared for a start up:
Again, this is only for frontline CloudPc’s and not for enterprise CloudPc’s.
The documentation also reflects this:
So all the dll stuff didn’t matter. The primary cause of slowness was the VM booting up.
Hi Jon,
It was both, it is a bit faster but still the VM needs to boot indeed.
Thanks,
Niels