Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WindowsTerminal!AppHost::_WindowInitializedHandler$_ResumeCoro$1+0x2cc -- access violation at Windows startup post Windows update restart #16235

Closed
bendono opened this issue Oct 27, 2023 · 2 comments · Fixed by #16267
Labels
Area-Windowing Window frame, quake mode, tearout In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal.

Comments

@bendono
Copy link

bendono commented Oct 27, 2023

Windows Terminal version

1.18.2310.9002

Windows build number

No response

Other Software

No response

Steps to reproduce

Unknown.

Expected Behavior

No response

Actual Behavior

I have ProcDump set as an AeDebug debugger (/ma full dumps). After a restarting from a Windows update, a WindowsTerminal dump was generated. Here are some relevant details. Please let me know if you need any more details.
I can also supply the dump if you tell me where to send it.

0:021> .lastevent
Last event: 3944.3b10: Access violation - code c0000005 (first/second chance not available)
  debugger time: Fri Oct 27 15:02:12.989 2023 (UTC + 9:00)
0:021> .exr -1
ExceptionAddress: 00007ff6ed1eed5c (WindowsTerminal!AppHost::_WindowInitializedHandler$_ResumeCoro$1+0x00000000000002cc)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000001
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000008
Attempt to read from address 0000000000000008
0:021> .ecxr
rax=0000017d8046a050 rbx=0000002a2deff1b0 rcx=0000000000000000
rdx=0000000000000005 rsi=0000000000000000 rdi=0000002a2defecc0
rip=00007ff6ed1eed5c rsp=0000002a2deff280 rbp=0000017d806f3680
 r8=0000017d8236e468  r9=0000017d8236e428 r10=00000fff47775dc4
r11=0100040010010010 r12=0000000000000000 r13=000000000000001c
r14=00007ffa955b70b0 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010204
WindowsTerminal!AppHost::_WindowInitializedHandler$_ResumeCoro$1+0x2cc:
00007ff6`ed1eed5c 488b4908        mov     rcx,qword ptr [rcx+8] ds:00000000`00000008=????????????????

0:021> k
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr           Call Site
00 0000002a`2deff280 00007ff6`ed1e5370 WindowsTerminal!AppHost::_WindowInitializedHandler$_ResumeCoro$1+0x2cc [C:\__w\1\s\src\cascadia\WindowsTerminal\AppHost.cpp @ 1333] 
01 (Inline Function) --------`-------- WindowsTerminal!std::coroutine_handle<void>::resume+0xc [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.37.32822\include\coroutine @ 85] 
02 (Inline Function) --------`-------- WindowsTerminal!wil::details::dispatcher_handler::Complete+0x1c [C:\__w\1\s\packages\Microsoft.Windows.ImplementationLibrary.1.0.220201.1\include\wil\cppwinrt_helpers.h @ 87] 
03 (Inline Function) --------`-------- WindowsTerminal!wil::details::dispatcher_handler::operator()+0x1c [C:\__w\1\s\packages\Microsoft.Windows.ImplementationLibrary.1.0.220201.1\include\wil\cppwinrt_helpers.h @ 81] 
04 0000002a`2deff350 00007ffa`8abf25e1 WindowsTerminal!winrt::impl::delegate<winrt::Windows::System::DispatcherQueueHandler,wil::details::dispatcher_handler>::Invoke+0x20 [C:\__w\1\s\src\cascadia\WindowsTerminal\Generated Files\winrt\Windows.system.h @ 1623] 
05 0000002a`2deff380 00007ffa`955b70c6 Windows_UI!Microsoft::WRL::Details::DelegateArgTraits<long (__cdecl Windows::System::IDispatcherQueueHandler::*)(void)>::DelegateInvokeHelper<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<2>,Windows::System::IDispatcherQueueHandler,Microsoft::WRL::FtmBase>,<lambda_59517943c03487243f9bea31c6c1a784>,-1>::Invoke+0x71
06 0000002a`2deff3b0 00007ffa`9558529b CoreMessaging!Windows::System::DispatcherQueue::DeferInvokeCallback+0x16
07 0000002a`2deff3e0 00007ffa`95579d34 CoreMessaging!Microsoft__CoreUI__Dispatch__TimeoutHandler$CallbackThunk+0x11b
08 0000002a`2deff460 00007ffa`955795de CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCall::Callback_Dispatch+0x2c4
09 0000002a`2deff520 00007ffa`95589d84 CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCallDispatcher::Callback_OnDispatch+0x15e
0a 0000002a`2deff590 00007ffa`95588d36 CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop+0xc04
0b 0000002a`2deff6b0 00007ffa`95586f71 CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch+0x1d6
0c 0000002a`2deff7a0 00007ffa`95586d9c CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter_DoWork+0xf1
0d 0000002a`2deff880 00007ffa`9a63e858 CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter_WindowProc+0xfc
0e 0000002a`2deff900 00007ffa`9a63e3dc user32!UserCallWinProcCheckWow+0x2f8
0f 0000002a`2deffa90 00007ffa`9a650c93 user32!DispatchClientMessage+0x9c
10 0000002a`2deffaf0 00007ffa`9a9b0e64 user32!_fnDWORD+0x33
11 0000002a`2deffb50 00007ffa`98401064 ntdll!KiUserCallbackDispatcherContinue
12 0000002a`2deffbd8 00007ffa`9a63a5c3 win32u!NtUserPeekMessage+0x14
13 0000002a`2deffbe0 00007ffa`9a63a523 user32!_PeekMessage+0x43
14 0000002a`2deffc50 00007ff6`ed21ec85 user32!PeekMessageW+0x143
15 0000002a`2deffcc0 00007ff6`ed21ec0a WindowsTerminal!WindowThread::_pumpRemainingXamlMessages+0x4d [C:\__w\1\s\src\cascadia\WindowsTerminal\WindowThread.cpp @ 52] 
16 0000002a`2deffd40 00007ff6`ed1d4762 WindowsTerminal!WindowThread::Refrigerate+0x5a [C:\__w\1\s\src\cascadia\WindowsTerminal\WindowThread.cpp @ 151] 
17 0000002a`2deffd80 00007ff6`ed1e59de WindowsTerminal!`WindowEmperor::_createNewWindowThread'::`2'::<lambda_1>::operator()+0x23a [C:\__w\1\s\src\cascadia\WindowsTerminal\WindowEmperor.cpp @ 252] 
18 (Inline Function) --------`-------- WindowsTerminal!std::invoke+0x5 [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.37.32822\include\type_traits @ 1752] 
19 0000002a`2deffe30 00007ffa`98481bb2 WindowsTerminal!std::thread::_Invoke<std::tuple<`WindowEmperor::_createNewWindowThread'::`2'::<lambda_1> >,0>+0xe [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.37.32822\include\thread @ 56] 
1a 0000002a`2deffe60 00007ffa`990e7344 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x42
1b 0000002a`2deffe90 00007ffa`9a9626b1 kernel32!BaseThreadInitThunk+0x14
1c 0000002a`2deffec0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

0:021> lm v m WindowsTerminal
Browse full module list
start             end                 module name
00007ff6`ed1d0000 00007ff6`ed282000   WindowsTerminal   (private pdb symbols)  c:\symbols\cache\WindowsTerminal.pdb\EDF2737A9E7C4F5DB889021C6A7F7E1D1\WindowsTerminal.pdb
    Loaded symbol image file: WindowsTerminal.exe
    Image path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.18.2822.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
    Image name: WindowsTerminal.exe
    Browse all global symbols  functions  data
    Timestamp:        Tue Oct 10 08:21:51 2023 (65248B0F)
    CheckSum:         000B806A
    ImageSize:        000B2000
    File version:     1.18.2310.9002
    Product version:  1.18.2310.9002
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:

Best regards.

@bendono bendono added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Oct 27, 2023
@zadjii-msft
Copy link
Member

Looks like this is MSFT:46763065 internally. Dumps show this repros on 1.19 too.

I think this was #16061 which had a theoretical fix in #16065. Looks like you're on Terminal Stable v1.18.2822.0, and https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is supposed to have had that fix in it. Dang.

I'll try and load up a dump.

@zadjii-msft
Copy link
Member

ohp well this is embarrassing

const auto strongThis = weakThis.lock();
if (!strongThis)
{
co_return;
}
ShowWindow(_window->GetHandle(), nCmdShow);
// If we didn't start the window hidden (in one way or another), then try to
// pull ourselves to the foreground. Don't necessarily do a whole "summon",
// we don't really want to STEAL foreground if someone rightfully took it
const bool noForeground = nCmdShow == SW_SHOWMINIMIZED ||

I never actually checked if we still had a _window. We're alive, yay! But we're still in the middle of refrigerating. So, there's no HWND anymore 🤦

@zadjii-msft zadjii-msft added Product-Terminal The new Windows Terminal. Area-Windowing Window frame, quake mode, tearout and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Oct 30, 2023
@zadjii-msft zadjii-msft added this to the Terminal v1.20 milestone Oct 30, 2023
@zadjii-msft zadjii-msft added the In-PR This issue has a related PR label Nov 6, 2023
DHowett pushed a commit that referenced this issue Nov 6, 2023
For history: 

> This is MSFT:46763065 internally. Dumps show this repros on 1.19 too. 
> 
> This was previously #16061 which had a theoretical fix in #16065.
Looks like you're on Terminal Stable v1.18.2822.0, and
https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is
supposed to have had that fix in it. Dang.

> well this is embarrassing ... I never actually checked if we _still
had a `_window`_. We're alive, yay! But we're still in the middle of
refrigerating. So, there's no HWND anymore

Attempt to fix this by actually ensuring there's a `_window` in
`AppHost::_WindowInitializedHandler`

Closes #16235
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Nov 6, 2023
DHowett pushed a commit that referenced this issue Nov 7, 2023
For history:

> This is MSFT:46763065 internally. Dumps show this repros on 1.19 too.
>
> This was previously #16061 which had a theoretical fix in #16065.
Looks like you're on Terminal Stable v1.18.2822.0, and
https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is
supposed to have had that fix in it. Dang.

> well this is embarrassing ... I never actually checked if we _still
had a `_window`_. We're alive, yay! But we're still in the middle of
refrigerating. So, there's no HWND anymore

Attempt to fix this by actually ensuring there's a `_window` in
`AppHost::_WindowInitializedHandler`

Closes #16235

(cherry picked from commit 59dcbbe)
Service-Card-Id: 91041358
Service-Version: 1.18
DHowett pushed a commit that referenced this issue Nov 7, 2023
For history:

> This is MSFT:46763065 internally. Dumps show this repros on 1.19 too.
>
> This was previously #16061 which had a theoretical fix in #16065.
Looks like you're on Terminal Stable v1.18.2822.0, and
https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is
supposed to have had that fix in it. Dang.

> well this is embarrassing ... I never actually checked if we _still
had a `_window`_. We're alive, yay! But we're still in the middle of
refrigerating. So, there's no HWND anymore

Attempt to fix this by actually ensuring there's a `_window` in
`AppHost::_WindowInitializedHandler`

Closes #16235

(cherry picked from commit 59dcbbe)
Service-Card-Id: 91041359
Service-Version: 1.19
DHowett pushed a commit that referenced this issue Nov 7, 2023
For history:

> This is MSFT:46763065 internally. Dumps show this repros on 1.19 too.
>
> This was previously #16061 which had a theoretical fix in #16065.
Looks like you're on Terminal Stable v1.18.2822.0, and
https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is
supposed to have had that fix in it. Dang.

> well this is embarrassing ... I never actually checked if we _still
had a `_window`_. We're alive, yay! But we're still in the middle of
refrigerating. So, there's no HWND anymore

Attempt to fix this by actually ensuring there's a `_window` in
`AppHost::_WindowInitializedHandler`

Closes #16235

(cherry picked from commit 59dcbbe)
Service-Card-Id: 91041358
Service-Version: 1.18
radu-cernatescu pushed a commit to radu-cernatescu/terminal that referenced this issue Nov 8, 2023
For history: 

> This is MSFT:46763065 internally. Dumps show this repros on 1.19 too. 
> 
> This was previously microsoft#16061 which had a theoretical fix in microsoft#16065.
Looks like you're on Terminal Stable v1.18.2822.0, and
https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is
supposed to have had that fix in it. Dang.

> well this is embarrassing ... I never actually checked if we _still
had a `_window`_. We're alive, yay! But we're still in the middle of
refrigerating. So, there's no HWND anymore

Attempt to fix this by actually ensuring there's a `_window` in
`AppHost::_WindowInitializedHandler`

Closes microsoft#16235
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Windowing Window frame, quake mode, tearout In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants