Can a handled exception on Windows call terminate()?

I have a C++ application deployed on a Windows server VM in Azure.

It's been running fine for a few days, and then WER took a crash dump. The faulting thread had this stack trace:

00 0000004a`7fb7ac00 00007ffa`9505e15f ucrtbase!abort+0x4e 
01 0000004a`7fb7ac30 00007ffa`911239ba ucrtbase!terminate+0x1f 
02 0000004a`7fb7ac60 00007ffa`9112c710 VCRUNTIME140!__std_terminate+0xa 
03 0000004a`7fb7ac90 00007ffa`9112282a VCRUNTIME140!_CallSettingFrame+0x20 
04 0000004a`7fb7acc0 00007ffa`91121b82 VCRUNTIME140!__FrameUnwindToState+0x136 
05 (Inline Function) --------`-------- VCRUNTIME140!__FrameUnwindToEmptyState+0x7e 
06 0000004a`7fb7ad30 00007ffa`9112be80 VCRUNTIME140!__InternalCxxFrameHandler+0x19a
07 0000004a`7fb7ad90 00007ffa`9897a5cd VCRUNTIME140!__CxxFrameHandler+0x90 
08 0000004a`7fb7ade0 00007ffa`9891068a ntdll!RtlpExecuteHandlerForUnwind+0xd 
09 0000004a`7fb7ae10 00007ffa`9112c249 ntdll!RtlUnwindEx+0x38a 
0a 0000004a`7fb7b4f0 00007ffa`91122979 VCRUNTIME140!_UnwindNestedFrames+0x109 
0b 0000004a`7fb7bab0 00007ffa`91122090 VCRUNTIME140!CatchIt+0xb5 
0c 0000004a`7fb7bb30 00007ffa`91121c7e VCRUNTIME140!FindHandler+0x3f0 
0d 0000004a`7fb7bc00 00007ffa`9112be80 VCRUNTIME140!__InternalCxxFrameHandler+0x296 
0e 0000004a`7fb7bc60 00007ffa`9897a54d VCRUNTIME140!__CxxFrameHandler+0x90 
0f 0000004a`7fb7bcb0 00007ffa`9890fcf3 ntdll!RtlpExecuteHandlerForException+0xd 
10 0000004a`7fb7bce0 00007ffa`98911a09 ntdll!RtlDispatchException+0x373 
11 0000004a`7fb7c3e0 00007ffa`95c53c58 ntdll!RtlRaiseException+0x2d9 
12 0000004a`7fb7cbc0 00007ffa`91124572 KERNELBASE!RaiseException+0x68
13 0000004a`7fb7cca0 00007ffa`784bd3ce VCRUNTIME140!_CxxThrowException+0xc2 
14 0000004a`7fb7cd20 00007ffa`78350000 MyModule!operator new[]+0x2e 
15 0000004a`7fb7cd28 0000004a`7fb7cf88 MyModule!__imp_?id@?$codecvt@DDU_Mbstatet@@@std@@2V0locale@2@A
16 0000004a`7fb7cd30 00000000`00000000 0x0000004a`7fb7cf88

(I replaced the real module name with MyModule!)

Questions:

1. I'm guessing (by the function names in the stack trace, e.g. RtlpExecuteHandlerForException) that this flow if for handled exceptions. Is that correct? if yes, why is the application crashing nevertheless?

2. The __imp_?id@?$codecvt@DDU_Mbstatet@@@std@@2V0locale@2@A at the bottom of the stack looks mangled. I've tried to de-mangle it online and got __imp_public: static class std::locale::id std::codecvt<char,char,struct _Mbstatet>::id. Does that make sense? it looks like a reference to a field, not a function

3. I've tried running !analyze -v and it gives:

EXCEPTION_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.

What can be the cause of such exception? Can you please provide a short snippet which triggers such an exception in Windows?)