“Stay signed in to all your apps” Pop-up Window Showed as Blank
This blog will share some insights from my recent troubleshooting experiences related to post-authentication issues with Microsoft first party services.
Overview
Users encountered an issue where the “Stay signed in to all your apps” window, which is typically presented after authentication to facilitate device registration with Azure AD and management through Intune.
Popup Window: Stay signed in to all your apps – Microsoft Community Hub
This deficiency hindered users from performing further actions.
Workflow
The above window is triggered by the WAM (Web Account Manager) and calls upon the CXH (Cloud Experience Host) which in turn uses edgehtml to render the authentication page (e.g., https://login.microsoftonline.com/common/login?cxhflow=TB&cxhplatformversion=10.0.19041).
This process also involves loading various web statics such as JavaScript and CSS (e.g., aadcdn.msftauth.net/ests/2.1/content/cdnbundles/ui-light.min_y6kevniabpxvxhzk1csrqa2.css) to display the content correctly.
Troubleshooting Script
We can utilize the following CXH etl script to capture the CXH etl for narrowing down the issue:
Start the capture:
logman create trace "shell_CloudExperienceHost" -ow -o c:\shell_CloudExperienceHost.etl -p {99EB7B56-F3C6-558C-B9F6-09A33ABB4C83} 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 2048 -ets
logman update trace "shell_CloudExperienceHost" -p {d0034f5e-3686-5a74-dc48-5a22dd4f3d5b} 0xffffffffffffffff 0xff -ets
logman update trace "shell_CloudExperienceHost" -p {AA02D1A4-72D8-5F50-D425-7402EA09253A} 0xffffffffffffffff 0xff -ets
logman update trace "shell_CloudExperienceHost" -p {4E749B6A-667D-4C72-80EF-373EE3246B08} 0xffffffffffffffff 0xff -ets
logman update trace "shell_CloudExperienceHost" -p {43D1A55C-76D6-4F7E-995C-64C711E5CAFE} 0xffffffffffffffff 0xff -ets
logman update trace "shell_CloudExperienceHost" -p {A70FF94F-570B-4979-BA5C-E59C9FEAB61B} 0xffffffffffffffff 0xff -ets
logman update trace "shell_CloudExperienceHost" -p {7ACF487E-104B-533E-F68A-A7E9B0431EDB} 0xffffffffffffffff 0xff -ets
logman update trace "shell_CloudExperienceHost" -p {4de9bc9c-b27a-43c9-8994-0915f1a5e24f} 0xffffffffffffffff 0xff -ets
logman update trace "shell_CloudExperienceHost" -p {EC3CA551-21E9-47D0-9742-1195429831BB} 0xffffffffffffffff 0xff -ets
End the capture:
logman stop "shell_CloudExperienceHost" -ets
Log Analysis
Upon examining the ETL logs, we could filter specific elements and assess the actual HTTP responses.
For instance, isolating the term “ui-light.min” allowed us to scrutinize the response in detail.
Please be aware that the filenames for web static resources may change due to updates or modifications made by the Microsoft product group.
For one issue I dealt with, we directly obeservd numerous 504 HTTP errors, indicating potential access issues to certain AAD CDN.
In contrast, there’s another similar issue presented a more challenging scenario with no specific error codes returned, necessitating a comparison of HTTP response frames from different AAD CDNs.
https://aadcdn.msauth.net/ests/2.1/content/cdnbundles/ui-light.min_y6kevniabpxvxhzk1csrqa2.css
Interestingly, queries to the following url yielded no response headers or information.
https://aadcdn.msftauth.net/ests/2.1/content/cdnbundles/ui-light.min_y6kevniabpxvxhzk1csrqa2.css
Additionally, “ERROR_FILE_NOT_FOUND” messages were prevalent in the logs.
Practical Resolution Steps
After conducting further tests within the customer’s environment using the PsExec tool to gain system context:
This discovery allows us to involve the effect user further involve the network team for a deeper investigation.
Conclusion
When facing similar issues, we could consider if there’s potential network issue affecting connectivity to AAD CDNs. Tools like CXH or Fiddler can be used in identifying and resolving these network-related problems.