AcquireTokenInteractive crashes on UWP app for ARM64

[cghersi]

Version of Nuget Microsoft.Identity.Client 4.19.0

Platform: UWP on ARM64

In a UWP Desktop App, running on ARM64, we want to authenticate for OneDrive, using the method IPublicClientApplication.AcquireTokenInteractive(...).ExecuteAsync();

Repro

private readonly string[] m_scopes = new[] { "Files.ReadWrite" };

IPublicClientApplication s_publicClientApp = PublicClientApplicationBuilder.Create("MyAppKeyForOneDrive")
					.WithRedirectUri("https://login.microsoftonline.com/common/oauth2/nativeclient")
					.Build();
IEnumerable<IAccount> accounts = await s_publicClientApp.GetAccountsAsync();
IAccount firstAccount = accounts?.FirstOrDefault();
AuthenticationResult authResult;
if (firstAccount != null)
{
	authResult = await s_publicClientApp.AcquireTokenSilent(m_scopes, firstAccount).ExecuteAsync();
}
else
{
	authResult = await s_publicClientApp.AcquireTokenInteractive(m_scopes).ExecuteAsync();
}

Expected behavior User is shown the login popup to enter credentials, and after successful login, the code receives a valid authResult.

Actual behavior On ARM64, the app crashes with an unrecoverable exception in SharedLibrary.dll.

Additional context/ Logs / Screenshots Please note that the very same code works perfectly in x64.

[bgavrilMS]

Do you have an exception trace or some logs?

[bgavrilMS]

I wonder if WAM will fare better here. If you have the time, could you try to the WAM broker instead of the browser control ? This is described here https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/wam

It's a different experience that's more integrated with Windows and which we will probably enable by default at some point. From your point of view you just have to register another redirect URI and add .WithBroker(true). The link has more details.

[cghersi]

Do you have an exception trace or some logs?

I don't, because when I step into that line s_publicClientApp.AcquireTokenXXX(), the app crashes miserably. The only thing we have is an event on the Windows Event Logs, stating there has been a crash of the app involving SharedLibrary.dll:

Faulting application name: MyApp.exe, version: 0.0.0.0, time stamp: 0x5fadfb37 Faulting module name: SharedLibrary.dll, version: 0.0.0.0, time stamp: 0x5d27c898 Exception code: 0x00001007 Fault offset: 0x00000000000ed608 Faulting process id: 0x34c4 Faulting application start time: 0x01d6b96f57b6f6d4 Faulting application path: C:\Program Files\WindowsApps\MyApp_1.4.2.0_arm64__xxx3536\MyApp.exe Faulting module path: C:\Program Files\WindowsApps\Microsoft.NET.Native.Framework.2.2_2.2.27912.0_arm64__8wekyb3d8bbwe\SharedLibrary.dll Report Id: 192f4c21-646f-441b-9913-0c45bdb4cb5b Faulting package full name: MyAppxxx Faulting package-relative application ID: App

[cghersi]

I wonder if WAM will fare better here. If you have the time, could you try to the WAM broker instead of the browser control ? This is described here https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/wam

It's a different experience that's more integrated with Windows and which we will probably enable by default at some point. From your point of view you just have to register another redirect URI and add .WithBroker(true). The link has more details.

We will try this approach, but I also believe that it is worth fixing the methods s_publicClientApp.AcquireTokenXXX() for ARM64. By the way, are you able to reproduce the problem?

[jmprieur]

@bgavrilMS would it be due to the reference assemblies?

[bgavrilMS]

I don't know, did not have time to repro this.

[cghersi]

@bgavrilMS Are you going to consider a fix for this issue? If yes, do you have a timeline (at least general, like 1 week, 1 month, 1 year...)?

[vfailla]

@bgavrilMS it seems the "WithBroker()" method is not available in UWP.

So I cannot do: var pca = PublicClientApplicationBuilder.Create("client_id").WithBroker(true);

Am I missing something?

[bgavrilMS]

@vfailla - are you using the latest MSAL ? We've only enabled this in MSAL 4.22 ... I can see the API:

[bgavrilMS]

@cghersi - how can I repro this? Is there an ARM emulator I can use? I don't have an ARM device.

[cghersi]

@bgavrilMS unfortunately the only way I can see to reproduce the issue is by deploying the app on an actual ARM64 machine, e.g. a Microsoft Surface Pro X.

[bgavrilMS]

@henrik-me - can you help here? Is there any ARM Windows device that someone in our team can get to?

@cghersi - the reason why I'm recommending WAM is that on UWP we actually rely on a an old Windows component called WAB (Windows Auth Broker) to pop up the browser. We've had a lot of problems with it in the past. If the root cause of this bug in is WAB, I doubt we will be able to fix it. But I cannot say for sure as I don't have an ARM device. Trying WAM would be an alternative.

[cghersi]

@bgavrilMS thanks for the explanation. While trying to integrate WAM, it seems there are some limitations, and you have to choose between personal / work account, AzureChina, etc. which is very inconvenient for us. Moreover, the documentation refers to methods that are not available. The ideal solution is to fix the bug in the library for ARM64. If this is not possible, maybe you can point us out to an alternative implementation that keeps the same features and same results.

[bgavrilMS]

@cghersi - I'd like to understand more about the inconvenience. There is no distinction between personal / work account exposed to developers. Sovereign clouds (such as AzureChina) are supported both by WAM and by MSAL and the API is the same. WAM is the best alternative I can think of.

The only inconvenience I see is:

• figuring out and registering a new redirect URI
• making sure you are on the UI thread before calling AcquireTokenInteractive

We'll try to find an ARM device, repro the issue and fix MSAL, but currently we are all working from home and getting hold of hardware is not as easy as it used to be.

[cghersi]

@bgavrilMS we are using this library to connect to OneDrive from our UWP app on behalf of the user, so that the user is able to:

1. browse her content on OneDrive (navigate thru folders, etc.)
2. download some files from her OneDrive account
3. upload some files into her OneDrive account. For this to happen we need the AccessToken that we retrieve from the AuthenticationResult object, the result of the s_publicClientApp.AcquireTokenXXX() method. We use this AccessToken to perform direct HTTP requests to endpoints like:

• https://graph.microsoft.com/v1.0/me/drive/items/{ITEM_ID}/content
• https://graph.microsoft.com/v1.0/me/drive/items/{FOLDER_ID}:/{FILENAME}:/createUploadSession
• etc...

Let me know if you have a code snippet for WAM that allows us to perform the same operation (with all the possible OneDrive accounts that a user can have) and get a valid AccessToken that we can use in the subsequent HTTP calls.

Thank you very much!

[bgavrilMS]

We will update the UWP sample with WAM and get back to you. Probably in line with our next release, around end of next week CC @jmprieur

[jmprieur]

@bgavrilMS : we have updated it for 4.22.0 : https://github.com/Azure-Samples/active-directory-xamarin-native-v2/tree/master/2-With-broker The only missing thing is the new static property

[bgavrilMS]

I just tried this out on a Surface Pro X and the code above works for me. I have to say that the remote debugging experience was horrible, I spent about 2h getting everything to work, but that's besides the point.

I tried your code and I also tried WAM in debug mode and things seem to work fine.

I am using Windows 10 20H2 version.

[cghersi]

@bgavrilMS we repro the issue on multiple ARM64 machines with winver 1909 (build 18363.1198). Do you have the chance to try on that configuration? Moreover, could you share the PoC project that you set up to try this behavior?

[bgavrilMS]

@cghersi - I will try with the version you mentioned, I think I have to reset my machine to rollback. I might not be able to do until January.

I tried with your code (but updated with my own client ID and scope). I also tried with our UWP sample https://github.com/Azure-Samples/active-directory-xamarin-native-v2/tree/master/2-With-broker which is preconfigured - could you try it please? I'm curious if at least the "Sign in with Broker" experience works for you.

I managed to get it all working both in debug mode and on the machine.

[bgavrilMS]

@cghersi - we have an internal thread on this as well. One of our engineers noticed that disabling the "optimize code flag" makes a difference.

There should also be possible to not optimize individual methods using an attribute

[MethodImpl(MethodImplOptions.NoOptimization)]

but I couldn't get this to work.

[cghersi]

Hi @bgavrilMS , sorry for the latency. I have a few problems:

1. we cannot ship an app without the Optimization flag off, and we need to understand which methods we should flag wit the attribute [MethodImpl(MethodImplOptions.NoOptimization)].
2. the sample you shared is for Xamarin, and it specifically mentions it is not working with UWP! Our app is in UWP, not Xamarin, so what should we do? Please let me know your status and if you can provide us a new NuGet package with the fix. Thank you very much

[bgavrilMS]

We are working on https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/2343 - maybe this will help with this scenario as well. Optimizers and linkers typically don't play well with reflection.

It should be very simple to change your app to use Windows Auth Manager controls instead of a simple browser. The Xamarin sample shows you the experience and works with UWP. Or just try directly yourself:

• add .WithExperimentalFeatures(true).WithBroker(true) to the PublicClientApp builder
• register a new redirect uri (https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/wam#uwp)
• make sure to call AcquireTokenInteractive from UI thread

[true-hamid]

We are facing the same issue. I'm trying to run it on the sample provided here https://github.com/azure-samples/active-directory-dotnet-native-uwp-v2 Version of Nuget Microsoft.Identity.Client 4.27.0

[bgavrilMS]

Hi folks, we made some changes to the json serializer to not use reflection. Not sure if it will help, could you try with this package please (just remove the zip extension, GitHub does not allow nupkg uploads, although a nupkg is a zip )

Microsoft.Identity.Client.4.27.0-json.1.nupkg.zip

Instructions on how to consume local nuget packages: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Installing-a-nuget-package-from-a-source-other-than-NuGet.org

[true-hamid]

@bgavrilMS Still the same issue is occurring, even with the this prerelease package it is basically the same error mentioned here: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/2187#issuecomment-730628075

[bgavrilMS]

Thanks for confirming @true-hamid . CC @pmaytak

[bgavrilMS]

The other workaround would be to use WAM directly https://docs.microsoft.com/en-us/windows/uwp/security/web-account-manager

[true-hamid]

Hi @bgavrilMS I don't think I can use WAM since I'm building a native module for a react native for windows app. And I have no experience in build a native UI component with this level of complexity. Hence I have to rely on MSAL for this one. Were you able to reproduce this issue? if yes do we have timelines for a fix?

You can check what I'm trying to do here https://github.com/true-hamid/react-native-windows-msal

Your help is much appreciated. Thanks

[bgavrilMS]

We're not doing any work on this, as it is not an MSAL problem. Keeping the issue open so that people can see the workarounds (i.e. don't check the optimization checkbox or possibly use WAM directly).

If you can raise a support issue with Microsoft related to UWP on ARM64, this would speed things up.