AccessViolationException during LoginAsync

[dspear]

I am just getting started with Auth0, and I can't get past the initial login call. I create the Auth0Client and then do a LoginAsync, but that throws an AccessViolationException from Auth0.Windows.WebBrowserHelpers.DeleteUrlCacheEntry(). I just got the latest stable release via NuGet yesterday. Any idea what can be going on or what I can do about it? Thank you.

[jerriep]

I will look into this for you

[jerriep]

Fixed with 88818d37b6a2ba210e806de4acd8470129517a0c

[jerriep]

@dspear I pushed 0.7.4 to NuGet (https://www.nuget.org/packages/Auth0.WinformsOrWPF/0.7.4)

Please let me know if it fixes your issue

[dspear]

It does not. I got the update with NuGet, and I'm getting the exact same error.

System.AccessViolationException occurred HResult=-2147467261 Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Source=Auth0.Windows StackTrace: at Auth0.Windows.WebBrowserHelpers.DeleteUrlCacheEntry(IntPtr lpszUrlName) at Auth0.Windows.WebBrowserHelpers.ClearCache() at Auth0.Windows.BrowserAuthenticationForm.ShowUI(IWin32Window owner) at Auth0.Windows.Auth0Client.LoginAsync(IWin32Window owner, String connection, String scope) at Tracker1.Tracker.DoAuth0() in C:\Users\spear\Documents\Infratab\Dev\Freshtime\TrackerSource\Tracker.cs:line 1658 InnerException:

[jerriep]

Are you sure you are using version 0.7.4 of the NuGet package?

[jerriep]

I am suppressing any exceptions from the ClearCache method, so I cannot see how this exception can ripple up into your code...

https://github.com/auth0/Auth0.WinformsWPF/blob/master/src/Auth0.Windows/BrowserAuthenticationForm.cs#L133-L142

[dspear]

I saw the exception catcher code. I installed the 0.7.4 version from NuGet. If I look at the Properties of my reference, it's in the Auth0.WinformsOrWPF.0.7.4 folder, but the "Version" is 0.7.2.0. Possibly an error in your build process?

[jerriep]

Yeah, it is just the dll which is not versioned correctly - manual process :(

I am still at a loss though about how code which swallows an exception can allow an exception to slip through...

Can you please remove the nuget package completely and clean all your build output files and then add the package and try again. It sounds like an old version of the DLL may be cached somewhere

[jerriep]

I changed the code now to manually throw a fake exception from the ClearCache method, and it certainly gets swallowed by they try-catch, so I can only come to the conclusion that some wrong DLL may still be referenced somewhere.

I also installed version 0.7.4 of the NuGet package locally and decompiled the source code and it certainly contains the correct code which swallows the exception, so it is not a case of me accidently deploying the incorrect version

Are you sure you are still getting the same exception with the same stack trace?

[dspear]

I have confirmed that my ShowUI also has the new code that swallows the exception. However, I'm noticing that the exception stack trace this time only shows 2 entries, ClearCache calling DeleteUrlCache. I don't know where ClearCache is being called from, but perhaps it's from somewhere else. I think you should catch the DeleteUrlCache exception from ClearCache, rather than from ShowUI.

[jerriep]

Can you please post your Stacktrace for me?

[jerriep]

Also, does this happen if you run the compiled application outside of Visual Studio?

[dspear]

Yes, it happens outside Visual Studio. And this time, the stack trace is complete, showing that it is coming from LoginAsync. How can that be? I just looked at the disassembly of the DLL in my app folder, and there's clearly a catch there! I'll have to uninstall it again and search my disk for any other references. I'm sorry if I'm wasting your time with some sort of configuration problem of mine, but I'm not doing anything unusual I don't think.

[jerriep]

Is it possible to post that Stacktrace here for me?

[dspear]

This is hopeless. I uninstalled it and I deleted the cached copies in my C:\Users\name.nuget folder, reinstalled, and I'm getting the same stupid exception. I'm going to have to download the source and build it and debug it.

That stack trace was the same as the previous one I posted above. This most recent time, it's not showing anything higher in the list: System.AccessViolationException occurred HResult=-2147467261 Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Source=Auth0.Windows StackTrace: at Auth0.Windows.WebBrowserHelpers.DeleteUrlCacheEntry(IntPtr lpszUrlName) at Auth0.Windows.WebBrowserHelpers.ClearCache() InnerException:

[jerriep]

If you can test from the source code locally I would greatly appreciate it :)

Just make sure that you delete the reference to Auth0.Windows in the WinformsSample project (as it will point to the NuGet package) and then add the reference to the actual project itself

[dspear]

I don't have an old version. The catch just doesn't work. I'm debugging from the source now and getting the same error. Even if I move the try/catch around the DeleteUrlCacheEntry call itself, it still throws what it thinks is an unhandled exception. I have no idea why, continuing to look at it. Maybe I can figure out why it's throwing the exception we can't catch.

[dspear]

The data in the internetCacheEntry looks bad. I don't know if it's some sort of marshalling problem, or something about 64-bit pointers, or what.

For example: CacheEntryType: 467 (0x1d3) dwHeaderInfoSize: 2401616610 (0x8f25c2e2) dwUseCount: 0x4da4ba54 lpHeaderInfo.m_Value: 0x8f25c2e201d1a628 lpszFileExtension.m_value: 0x0000000001d1a628 lpszLocalFileName.m_value: 0x000001d34da4ba20 lpszSourceUrlName.m_value: 0x4da4ba2000000000

Clearly lots of this data is wrong. Why that causes an uncatchable exception, I have no idea.

[dspear]

Looking at the definition of INTERNET_CACHE_ENTRY_INFOA in WebBrowserHelpers.cs, the FieldOffset values indicate that 4 bytes have been reserved for the pointer to file names, but the debugger thinks that pointers are 64 bits long. I don't know exactly how the [FieldOffset] values are used, if they override the size of the fields, but I suspect that they do and that that is the source of the problem with this structure.

[dspear]

Yes, I've confirmed that those pointers are overlapping each other. I expect that they need to be 8 bytes in a 64-bit environment.

[dspear]

Yes, I have the fix, largely from this page: http://www.pinvoke.net/default.aspx/wininet.INTERNET_CACHE_ENTRY_INFO

This is how the structure should be defined: [StructLayout(LayoutKind.Explicit)] public struct ExemptDeltaOrReserved { [FieldOffset(0)] public UInt32 dwReserved; [FieldOffset(0)] public UInt32 dwExemptDelta; }

    [StructLayout(LayoutKind.Sequential)]
    private struct INTERNET_CACHE_ENTRY_INFO
    {
        public UInt32 dwStructSize;
        public IntPtr lpszSourceUrlName;
        public IntPtr lpszLocalFileName;
        public UInt32 CacheEntryType;
        public UInt32 dwUseCount;
        public UInt32 dwHitRate;
        public UInt32 dwSizeLow;
        public UInt32 dwSizeHigh;
        public System.Runtime.InteropServices.ComTypes.FILETIME LastModifiedTime;
        public System.Runtime.InteropServices.ComTypes.FILETIME ExpireTime;
        public System.Runtime.InteropServices.ComTypes.FILETIME LastAccessTime;
        public System.Runtime.InteropServices.ComTypes.FILETIME LastSyncTime;
        public IntPtr lpHeaderInfo;
        public UInt32 dwHeaderInfoSize;
        public IntPtr lpszFileExtension;
        public ExemptDeltaOrReserved dwExemptDeltaOrReserved;
    }

[jerriep]

@dspear Thank you for this, and apologies once again in the pain this caused you, and also the time taken to sort it out.

I have pushed 0.7.5 Beta1 to Nuget (https://www.nuget.org/packages/Auth0.WinformsOrWPF/0.7.5-beta1)

Please try and let me know whether it sorts out your issue. If it does I will remove the beta label

[dspear]

I have tried it and it works. I can successfully log in without any errors. Thank you.