Microsoft-ui-xaml: MapControl crashes with zoom level > 4.5 and MapStyle.Road

Created on 17 Nov 2020 · 16Comments · Source: microsoft/microsoft-ui-xaml

Describe the bug
MapControl crashes.
This issue started to happen a few hours ago, out of nowhere (Nov 17th midnight UTC).
It happens locally when debugging (see demo project below) and all my live apps for seemingly all my users!
Developer dashboard reports the crash as: fail_fast_fatal_app_exit_c0000409_bingmaps.dll!mapcontrol::detailtexturesource::begingettexture

This is an excerpt from the crash in the Event viewer:

Faulting module name: ucrtbase.dll, version: 10.0.19041.546, time stamp: 0x73123758
Exception code: 0xc0000409
Fault offset: 0x0009edbb
Faulting process id: 0x2c24
Faulting application start time: 0x01d6bca21d0101fa
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll

Steps to reproduce the bug
Use the MapControl in an app. Use the Style "Road". Zoom in past zoom level 4.5 (either programmatically or manually)
--> crash

Expected behavior
No crash

Example project:
App1.zip

Example live apps:
https://www.microsoft.com/en-us/p/xaml-ui-controls/9nblggh31bxt
https://www.microsoft.com/en-us/p/geophoto-geotag-map-slideshow/9wzdncrfj0f2

area-External

Source

tipa

👍13

Most helpful comment

Yeah, someone from Microsoft needs to fix this ASAP!

moshegutman on 17 Nov 2020

👍5 👀1 ❤1

All 16 comments

video of crash https://streamable.com/09m2lk

dpaulino on 17 Nov 2020

We're experiencing the same issue with our wpf application. Here's the result from windbg:
KEY_VALUES_STRING: 1

Key  : Analysis.CPU.mSec
Value: 127046

Key  : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-CDBMDLO

Key  : Analysis.DebugData
Value: CreateObject

Key  : Analysis.DebugModel
Value: CreateObject

Key  : Analysis.Elapsed.mSec
Value: 186372

Key  : Analysis.Memory.CommitPeak.Mb
Value: 608

Key  : Analysis.System
Value: CreateObject

Key  : CLR.BuiltBy
Value: NET48REL1LAST_C

Key  : CLR.Engine
Value: CLR

Key  : CLR.Version
Value: 4.8.4250.0

Key  : Timeline.OS.Boot.DeltaSec
Value: 377005

Key  : Timeline.Process.Start.DeltaSec
Value: 9

Key  : WER.OS.Branch
Value: 19h1_release

Key  : WER.OS.Timestamp
Value: 2019-03-18T12:02:00Z

Key  : WER.OS.Version
Value: 10.0.18362.1

Key  : WER.Process.Version
Value: 1.0.0.0

ADDITIONAL_XML: 1

OS_BUILD_LAYERS: 1

NTGLOBALFLAG: 0

PROCESS_BAM_CURRENT_THROTTLED: 0

PROCESS_BAM_PREVIOUS_THROTTLED: 0

APPLICATION_VERIFIER_FLAGS: 0

CONTEXT: (.ecxr)
eax=00000001 ebx=19363ea0 ecx=00000007 edx=000001e3 esi=00000003 edi=178df874
eip=759befbb esp=178df6c8 ebp=178df6dc iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ucrtbase!abort+0x4b:
759befbb cd29 int 29h
Resetting default scope

EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 759befbb (ucrtbase!abort+0x0000004b)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 00000007
Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT

PROCESS_NAME: ST.LasVegas.WPF.Retail.exe

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_CODE_STR: c0000409

EXCEPTION_PARAMETER1: 00000007

MISSING_CLR_SYMBOL: 0

STACK_TEXT:
178df6dc 759be38b 178df70c 759a86c6 178df73c 17087cd7 178df748 170876fd 178df82c 1708752e 178df868 170950a8 178df8a4 16eb5f4a 178df8b8 16eb60b9 178df8c4 16efa15b 178df8d0 16ef9ee5 178df8e4 16ef9e7c 178df91c 16eee0b9 178df934 17094e35 178df988 17086840 178df9a0 7a3d3dd0 178df9ac 7a3d83d2 178df9d8 7a3ef343 178dfa64 7a3d75e6 178dfa70 7a3d3dd0 178dfa7c 7a3d83d2 178dfaa8 7a3d5e50 178dfab0 79cc4735 178dfad8 79cc4027 178dfb04 77359984 178dfb3c 7735868c 178dfcec 76d66359 178dfcfc 77388944 178dfd58 77388914 178dfd68 00000000 823a6ab3 178df874 759be350 ucrtbase!abort+0x4b
823a6a83 178df874 1568e7c0 ucrtbase!terminate+0x3b
07788b64 178df82c 170876fd ucrtbase!__crt_state_management::wrapped_invoke+0x21
178df7b0 178df874 00000001 BingMaps!MapControl::DetailTextureSource::completeParentOperation+0x28
194c7298 178df874 00000000 BingMaps!MapControl::DetailTextureSource::beginGetTexture+0x19a
194c7298 1568e7c0 1568e7b0 BingMaps!MapControl::DetailTextureSource::childOperationCompleted+0x3e
1568d320 16eb5f20 1568d320 BingMaps!std::_Func_impl_no_alloc >,std::shared_ptr > >,Math::TileId,Pal::AsyncOperation > const &),MapControl::DetailTextureSource ,MapControl::TileFrameKey const &,std::shared_ptr >,std::shared_ptr > > &,Math::TileId const &,std::_Ph<1> const &>,void,Pal::AsyncOperation > &>::_Do_call+0x48
1568d350 16eb60a0 16efa15b BingMaps!Pal::AsyncOperation::callbackFromBaseClass+0x2a
1568d320 16eac7c0 16ef9ee5 BingMaps!std::_Func_impl_no_alloc::)(void),Pal::AsyncOperation >,void>::_Do_call+0x19
1568d320 1568d330 00000000 BingMaps!std::_Func_class::operator()+0x22
00000001 bf74463f 00b54618 BingMaps!Pal::UntypedAsyncOperation::tryComplete+0x4a
00000001 00b54610 1568d320 BingMaps!Pal::UntypedAsyncOperation::setSucceededOrFailedInternal+0x62
178df96c bf7446ab 00b54610 BingMaps!Pal::AsyncOperation >::setSucceeded+0x69
00b54620 00b54618 00b54610 BingMaps!MapControl::PipelineAsyncSource,std::shared_ptr > >::process+0x75
18edd9b0 18edd998 7a3d83d2 BingMaps!std::_Func_impl_no_alloc > >,std::shared_ptr > >::)(MapControl::TileFrameKey const &,std::shared_ptr > >,std::pair >,std::shared_ptr > > > const &,std::shared_ptr const &),MapControl::PipelineAsyncSource > >,std::shared_ptr > > *,MapControl::TileFrameKey const &,std::shared_ptr > >,std::pair >,std::shared_ptr > > > &,std::shared_ptr &>,void>::_Do_call+0x20
7ea0dd26 155e44b4 155e44c0 MapConfiguration!std::_Func_class::operator()+0x22
7ea0de9a 1556f578 7a3ef210 MapConfiguration!Pal::Task::run+0x41
1556f578 7a3d75d0 7a3d3dd0 MapConfiguration!Utility::PrioritizedTaskQueue::executeNextTask+0x133
1556f578 1556f560 7a3d83d2 MapConfiguration!std::_Func_impl_no_alloc,void>::_Do_call+0x16
7ea0de56 7a3d5e40 0740cf90 MapConfiguration!std::_Func_class::operator()+0x22
178dfad8 79cc4735 00b547c8 MapConfiguration!Pal::Task::run+0x41
00b547c8 0740cf90 79cc3f80 MapConfiguration!Microsoft::WRL::Details::DelegateArgTraits,ABI::Windows::System::Threading::IWorkItemHandler,Microsoft::WRL::FtmBase>, &,-1,ABI::Windows::Foundation::IAsyncAction *>::Invoke+0x10
81215622 79cc3f80 075c2598 threadpoolwinrt!Windows::System::Threading::CThreadPoolWorkItem::CommonWorkCallback+0xa5
178dfc18 0740cf90 075c2598 threadpoolwinrt!Windows::System::Threading::CThreadPoolWorkItem::BatchedCallback+0xa7
178dfc18 075c2610 8519dab9 ntdll!TppWorkpExecuteCallback+0x144
15569710 76d66340 178dfd58 ntdll!TppWorkerThread+0x72c
15569710 8519db0d 00000000 kernel32!BaseThreadInitThunk+0x19
ffffffff 773aa0d6 00000000 ntdll!__RtlUserThreadStart+0x2f
77357f60 15569710 00000000 ntdll!_RtlUserThreadStart+0x1b

SYMBOL_NAME: ucrtbase!abort+4b

MODULE_NAME: ucrtbase

IMAGE_NAME: ucrtbase.dll

STACK_COMMAND: ~39s ; .ecxr ; kb

FAILURE_BUCKET_ID: FAIL_FAST_FATAL_APP_EXIT_c0000409_ucrtbase.dll!abort

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x86

OSNAME: Windows 10

IMAGE_VERSION: 10.0.18362.1110

FAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}

Followup: MachineOwner

perssondan on 17 Nov 2020

I have the same issue, and posted on StackOverflow
https://stackoverflow.com/questions/64870089/uwp-mapcontrol-crashes-after-zooming-in

moshegutman on 17 Nov 2020

same issue!!!!
but ms can't block apps with this bugs, i work with my app!!!.
It is unacceptable that it does not work. Who can we write to to solve this problem quickly?

premiaware on 17 Nov 2020

A quick workaround is to start the map in Aerial mode

<maps:MapControl Style="AerialWithRoads" />

moshegutman on 17 Nov 2020

👍2

Workaround is awesome, however if you switch back into Terrain it will then crash.

BobbyCannon on 17 Nov 2020

Yeah, someone from Microsoft needs to fix this ASAP!

moshegutman on 17 Nov 2020

👍5 👀1 ❤1

Hi all, I'm an engineer at Microsoft. I've been tracking this issue with tipa since before this ticket was created. I don't work with the mapcontrol team, but I wanted to help out with this issue. So, I've reached out to the relevant teams internally. This issue was caused by an issue server side that was published recently. They're rolling back the server-side changes, so hopefully we see the control start to work normally soon.

dpaulino on 17 Nov 2020

👍4

Thank you for this feedback @dpaulino
All of my apps in prod have crashed today... A big big mess that I didn't had sine 15 years at least

ricavir11 on 17 Nov 2020

I got this message from Microsoft:

Hi Moshe,

Upon investigation, the Bing Maps UWP control was inadvertently unable to handle a certain condition around the tiles. To mitigate this issue, our Product Group has initiated rolling back the change that impacted this experience. This issue should be beginning to resolve within the next hour, if not already.

Regards,
Kelvin Goseng
Support Engineer | Bing Maps Enterprise Support
Microsoft Corporation

moshegutman on 17 Nov 2020

👍4

The crash doesn't seem to be happening anymore in this app that tipa reported: https://www.microsoft.com/en-us/p/xaml-ui-controls/9nblggh31bxt.

Can others confirm if the control is working normally in your apps?

dpaulino on 17 Nov 2020

👍1

Can confirm it works in our apps as well.

DaanTul on 17 Nov 2020

Yes working again. @dpaulino can you pass along these comments to the map control team:

Bing Maps UWP team really needs to be on GitHub, we need an official place to report issues
Bing Maps needs to communicate with customers during outages. They have a Twitter (@bingmaps), use it.
It was great of @dpaulino to step in to help connect, but where is the Bing Maps team?
Can we expect a RCA of this incident, and steps that Bing Maps will take to prevent incidents like this in the future?

moshegutman on 17 Nov 2020

👍2

@moshegutman I passed it along. I'm sorry this happened. I have a few production Windows apps in the store myself. It's frustrating to realize that some server side dependency that's out of our control can shut down our production apps so suddenly. Fingers crossed that the team can provide some transparency.

dpaulino on 17 Nov 2020

👍2

@dpaulino : you express exactly my actual feeling...

ricavir11 on 17 Nov 2020

Looks like the issue is unrelated to WinUI and already resolved, so closing this issue.