Zoom Null Reference Exception

[JeremiahOsborne]

Hello all, I'm running into an issue were zooming quickly causes a NullRefrenceException to be thrown. To provide further context, I'm using a standard map object and its built-in panning/zooming capabilities (no custom logic). 

When zooming in, the output is spammed with 'System.Net.WebException', 'System.Net.Http.HttpRequestException', and 'System.ObjectDisposedException' in System.dll. The exception points directly at "innerAsyncResult.InternalWaitForCompletion()" at line 402 in "ForwardingReadStream.cs".

I assume this is related to too many http requests being made, but i'm unsure. There doesn't seem to be a work around even when wrapping a "setViewpointAsync" call.

Here are the details from the call stack:

System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=System
StackTrace:
at System.Net.Cache.ForwardingReadStream.EndRead(IAsyncResult asyncResult) in System.Net.Cache\ForwardingReadStream.cs:line 402

[PreetiMaske]

Is it a WPF Framework app? If yes, try a WPF .NET app.

[JeremiahOsborne]

Not sure i'm following, I'm using a normal WPF desktop application solution and using components from the nuget packages shown below:

So far everything works fine, just seems to run into an "Object reference not set to an instance of an object" issue when scrolling too quickly.

[PreetiMaske]

For WPF , you can create two types of application : WPF using .NET Framework or WPF using .NET. These are two different frameworks for creating a WPF app. I was suggesting to create a WPF application targeting .NET.
Red circled ones are Microsoft's template for 1) WPF .NET and 2) WPF using .NET Framework. I was suggesting to use either the Maps SDK template( highlighted in blue) or the one I checked in image below.

Blue is ArcGIS Maps SDK template for WPF .NET 

SDK templates can be installed from within Visual Studio. See https://developers.arcgis.com/net/install-and-set-up/#install-the-visual-studio-project-templates-op... for more info.

[dotMorten_esri]

The exception you're pointing to shouldn't be an issue - this can occur deep down the .NET networking stack when a request gets cancelled, but it should _not_ lead to an application crash. It's merely a first-chance exception, and just how .NET does network requests. Did you by any chance enable that exception in the error-list to break on first chance exceptions of this type? Are you actually seeing an application crash if you just continue? (or run without the debugger attached)