starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 08:24:54 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Crash when defterm handoff'ing a bat file? #19773

New Issue
Closed
opened 2026-01-31 06:53:13 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 06:53:13 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Apr 26, 2023).

  1. Terminal preview 1.18.1041
  2. Save the following as a bat file: 
    echo foo

for /L %%i  IN (0,1,100000) DO echo Line %%i 

pause
  3. add "windowingBehavior": "useAnyExisting",
  4. Set Terminal Preview as the default terminal
  5. Open a Terminal window
  6. double click the .bat in file explorer
  7. OpenConsole crashes into the post-mortem debugger‼️

Other bat files are fine?

It also doesn't crash if you run it manually?

Originally created by @zadjii-msft on GitHub (Apr 26, 2023). 1. Terminal preview 1.18.1041 2. Save the following as a bat file: ```bat echo foo for /L %%i IN (0,1,100000) DO echo Line %%i pause ``` 3. add `"windowingBehavior": "useAnyExisting",` 4. Set Terminal Preview as the default terminal 5. Open a Terminal window 6. double click the `.bat` in file explorer 7. OpenConsole crashes into the post-mortem debugger‼️ Other bat files are fine? It also doesn't crash if you run it manually?
claunia commented 2026-01-31 06:53:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 27, 2023):

Oh and it worked fine on 1.16.10262.0

@zadjii-msft commented on GitHub (Apr 27, 2023): Oh and it worked fine on 1.16.10262.0
claunia commented 2026-01-31 06:53:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 27, 2023):

............ aaaaaand it works fine in a dev build. I'm guessing this is just more of my machine's "defterm is messed up yo". That or 1041 had bugs (not unlikely)

@zadjii-msft commented on GitHub (Apr 27, 2023): ............ aaaaaand it works fine in a dev build. I'm guessing this is just more of my machine's "defterm is messed up yo". That or 1041 had bugs (not unlikely)
claunia commented 2026-01-31 06:53:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 4, 2023):

HMMMMMM I GOT IT TO HAPPEN AGAIN

image
image

0:007> k
 # Child-SP          RetAddr               Call Site
00 000000c2`3dcfeb00 00007ff6`4c02586a     OpenConsole!TextBuffer::GetRowByOffset+0x61 [D:\dev\public\terminal\src\buffer\out\textBuffer.cpp @ 96] 
01 000000c2`3dcfeb50 00007ff6`4c01e576     OpenConsole!Microsoft::Console::VirtualTerminal::AdaptDispatch::_DoLineFeed+0x3da [D:\dev\public\terminal\src\terminal\adapter\adaptDispatch.cpp @ 2161] 
02 000000c2`3dcfed60 00007ff6`4c05e6e1     OpenConsole!Microsoft::Console::VirtualTerminal::AdaptDispatch::LineFeed+0xa6 [D:\dev\public\terminal\src\terminal\adapter\adaptDispatch.cpp @ 2207] 
03 000000c2`3dcfedb0 00007ff6`4c05a39d     OpenConsole!Microsoft::Console::VirtualTerminal::OutputStateMachineEngine::ActionExecute+0x211 [D:\dev\public\terminal\src\terminal\parser\OutputStateMachineEngine.cpp @ 75] 
04 000000c2`3dcfeeb0 00007ff6`4c05c926     OpenConsole!`Microsoft::Console::VirtualTerminal::StateMachine::_ActionExecute'::`2'::<lambda_1>::operator()+0x6d [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 393] 
05 000000c2`3dcfef00 00007ff6`4c05770f     OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::_SafeExecute<`Microsoft::Console::VirtualTerminal::StateMachine::_ActionExecute'::`2'::<lambda_1> >+0x26 [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 2054] 
06 000000c2`3dcfef50 00007ff6`4c058787     OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::_ActionExecute+0x5f [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 391] 
07 000000c2`3dcfefa0 00007ff6`4c056ccb     OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::_EventGround+0x67 [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 990] 
08 000000c2`3dcfefe0 00007ff6`4c056ff1     OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::ProcessCharacter+0x17b [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 1740] 
09 000000c2`3dcff040 00007ff6`4bd3c912     OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::ProcessString+0x171 [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 1856] 
0a 000000c2`3dcff1e0 00007ff6`4bd3cb79     OpenConsole!WriteChars+0x282 [D:\dev\public\terminal\src\host\_stream.cpp @ 770] 
0b 000000c2`3dcff2b0 00007ff6`4bd3ce7e     OpenConsole!DoWriteConsole+0x219 [D:\dev\public\terminal\src\host\_stream.cpp @ 837] 
0c 000000c2`3dcff3c0 00007ff6`4bd3a561     OpenConsole!WriteConsoleWImplHelper+0x13e [D:\dev\public\terminal\src\host\_stream.cpp @ 878] 
0d 000000c2`3dcff450 00007ff6`4bf8ca03     OpenConsole!ApiRoutines::WriteConsoleWImpl+0x121 [D:\dev\public\terminal\src\host\_stream.cpp @ 1110] 
0e 000000c2`3dcff540 00007ff6`4bf9bc52     OpenConsole!ApiDispatchers::ServerWriteConsole+0x3d3 [D:\dev\public\terminal\src\server\ApiDispatchers.cpp @ 420] 
0f 000000c2`3dcff7d0 00007ff6`4bf87ec0     OpenConsole!ApiSorter::ConsoleDispatchRequest+0x242 [D:\dev\public\terminal\src\server\ApiSorter.cpp @ 178] 
10 000000c2`3dcff8b0 00007ff6`4bf871a4     OpenConsole!IoDispatchers::ConsoleDispatchRequest+0x20 [D:\dev\public\terminal\src\server\IoDispatchers.cpp @ 593] 
11 000000c2`3dcff8e0 00007ff6`4bc6da4e     OpenConsole!IoSorter::ServiceIoOperation+0xe4 [D:\dev\public\terminal\src\server\IoSorter.cpp @ 33] 
12 000000c2`3dcff960 00007ffc`5bd6292d     OpenConsole!ConsoleIoThread+0x28e [D:\dev\public\terminal\src\host\srvinit.cpp @ 1061]

Wow that all looks super fucked.

@zadjii-msft commented on GitHub (May 4, 2023): HMMMMMM I GOT IT TO HAPPEN AGAIN ![image](https://user-images.githubusercontent.com/18356694/236330822-8b2ffc83-cc1d-4321-a451-c52541aeafa8.png) ![image](https://user-images.githubusercontent.com/18356694/236331165-cf87f091-d67a-4588-8622-623593e0b219.png) ``` 0:007> k # Child-SP RetAddr Call Site 00 000000c2`3dcfeb00 00007ff6`4c02586a OpenConsole!TextBuffer::GetRowByOffset+0x61 [D:\dev\public\terminal\src\buffer\out\textBuffer.cpp @ 96] 01 000000c2`3dcfeb50 00007ff6`4c01e576 OpenConsole!Microsoft::Console::VirtualTerminal::AdaptDispatch::_DoLineFeed+0x3da [D:\dev\public\terminal\src\terminal\adapter\adaptDispatch.cpp @ 2161] 02 000000c2`3dcfed60 00007ff6`4c05e6e1 OpenConsole!Microsoft::Console::VirtualTerminal::AdaptDispatch::LineFeed+0xa6 [D:\dev\public\terminal\src\terminal\adapter\adaptDispatch.cpp @ 2207] 03 000000c2`3dcfedb0 00007ff6`4c05a39d OpenConsole!Microsoft::Console::VirtualTerminal::OutputStateMachineEngine::ActionExecute+0x211 [D:\dev\public\terminal\src\terminal\parser\OutputStateMachineEngine.cpp @ 75] 04 000000c2`3dcfeeb0 00007ff6`4c05c926 OpenConsole!`Microsoft::Console::VirtualTerminal::StateMachine::_ActionExecute'::`2'::<lambda_1>::operator()+0x6d [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 393] 05 000000c2`3dcfef00 00007ff6`4c05770f OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::_SafeExecute<`Microsoft::Console::VirtualTerminal::StateMachine::_ActionExecute'::`2'::<lambda_1> >+0x26 [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 2054] 06 000000c2`3dcfef50 00007ff6`4c058787 OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::_ActionExecute+0x5f [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 391] 07 000000c2`3dcfefa0 00007ff6`4c056ccb OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::_EventGround+0x67 [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 990] 08 000000c2`3dcfefe0 00007ff6`4c056ff1 OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::ProcessCharacter+0x17b [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 1740] 09 000000c2`3dcff040 00007ff6`4bd3c912 OpenConsole!Microsoft::Console::VirtualTerminal::StateMachine::ProcessString+0x171 [D:\dev\public\terminal\src\terminal\parser\stateMachine.cpp @ 1856] 0a 000000c2`3dcff1e0 00007ff6`4bd3cb79 OpenConsole!WriteChars+0x282 [D:\dev\public\terminal\src\host\_stream.cpp @ 770] 0b 000000c2`3dcff2b0 00007ff6`4bd3ce7e OpenConsole!DoWriteConsole+0x219 [D:\dev\public\terminal\src\host\_stream.cpp @ 837] 0c 000000c2`3dcff3c0 00007ff6`4bd3a561 OpenConsole!WriteConsoleWImplHelper+0x13e [D:\dev\public\terminal\src\host\_stream.cpp @ 878] 0d 000000c2`3dcff450 00007ff6`4bf8ca03 OpenConsole!ApiRoutines::WriteConsoleWImpl+0x121 [D:\dev\public\terminal\src\host\_stream.cpp @ 1110] 0e 000000c2`3dcff540 00007ff6`4bf9bc52 OpenConsole!ApiDispatchers::ServerWriteConsole+0x3d3 [D:\dev\public\terminal\src\server\ApiDispatchers.cpp @ 420] 0f 000000c2`3dcff7d0 00007ff6`4bf87ec0 OpenConsole!ApiSorter::ConsoleDispatchRequest+0x242 [D:\dev\public\terminal\src\server\ApiSorter.cpp @ 178] 10 000000c2`3dcff8b0 00007ff6`4bf871a4 OpenConsole!IoDispatchers::ConsoleDispatchRequest+0x20 [D:\dev\public\terminal\src\server\IoDispatchers.cpp @ 593] 11 000000c2`3dcff8e0 00007ff6`4bc6da4e OpenConsole!IoSorter::ServiceIoOperation+0xe4 [D:\dev\public\terminal\src\server\IoSorter.cpp @ 33] 12 000000c2`3dcff960 00007ffc`5bd6292d OpenConsole!ConsoleIoThread+0x28e [D:\dev\public\terminal\src\host\srvinit.cpp @ 1061] ``` Wow that all looks super fucked.
claunia commented 2026-01-31 06:53:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 4, 2023):

AND there are crashes for this that aren't just me!
MSFT:44310564 is {a4569db1-0940-c9d3-8768-caa7607e965c} a

@zadjii-msft commented on GitHub (May 4, 2023): AND there are crashes for this that _aren't_ just me! MSFT:44310564 is `{a4569db1-0940-c9d3-8768-caa7607e965c}` a
claunia commented 2026-01-31 06:53:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 4, 2023):

Oh dear

In the PtySignal thread:

[0x9]   OpenConsole!LockConsole + 0x2e   
[0xa]   OpenConsole!Microsoft::Console::PtySignalInputThread::_DoResizeWindow + 0x48   
[0xb]   OpenConsole!Microsoft::Console::PtySignalInputThread::_InputThread + 0x21c   
[0xc]   OpenConsole!Microsoft::Console::PtySignalInputThread::StaticThreadProc + 0x2a   
[0xd]   KERNEL32!BaseThreadInitThunk + 0x1d

The signal thread is waiting for a chance to resize the conpty to (in this case) (0x52,0x19). BUT IT KEEPS ON GOING ANYWAYS. It's printed 26 lines... to.. the... textbuffer?

I'd reckon this might even be the root cause of #14512. There's a miscommunication between the Terminal and conpty on how big it should be.

@zadjii-msft commented on GitHub (May 4, 2023): Oh dear In the PtySignal thread: ``` [0x9] OpenConsole!LockConsole + 0x2e [0xa] OpenConsole!Microsoft::Console::PtySignalInputThread::_DoResizeWindow + 0x48 [0xb] OpenConsole!Microsoft::Console::PtySignalInputThread::_InputThread + 0x21c [0xc] OpenConsole!Microsoft::Console::PtySignalInputThread::StaticThreadProc + 0x2a [0xd] KERNEL32!BaseThreadInitThunk + 0x1d ``` The signal thread is waiting for a chance to resize the conpty to (in this case) (0x52,0x19). BUT IT KEEPS ON GOING ANYWAYS. It's printed 26 lines... to.. the... textbuffer? I'd reckon this might even be the root cause of #14512. There's a miscommunication between the Terminal and conpty on how big it should be.
claunia commented 2026-01-31 06:53:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 4, 2023):

Interesting. Looking through the dump, the text buffer of OpenConsole!Microsoft::Console::Interactivity::ServiceLocator::s_globals.ciConsoleInformation.pCurrentScreenBuffer does actually look sane

0:007> dx -r1 (*((OpenConsole!std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> > *)0x20e19689b98))
(*((OpenConsole!std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> > *)0x20e19689b98))                 [Type: std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> >]
    [<Raw View>]     [Type: std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> >]
    [+0x000] _renderer        : 0x20e19687520 [Type: Microsoft::Console::Render::Renderer &]
    [+0x008] _hyperlinkMap    : { size=0x0 } [Type: std::unordered_map<unsigned short,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::hash<unsigned short>,std::equal_to<unsigned short>,std::allocator<std::pair<unsigned short const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > > >]
    [+0x058] _hyperlinkCustomIdMap : { size=0x0 } [Type: std::unordered_map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,unsigned short,std::hash<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >,std::equal_to<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const ,unsigned short> > >]
    [+0x0a8] _currentHyperlinkId : 0x1 [Type: unsigned short]
    [+0x0b0] _idsAndPatterns  : { size=0x0 } [Type: std::unordered_map<unsigned __int64,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::hash<unsigned __int64>,std::equal_to<unsigned __int64>,std::allocator<std::pair<unsigned __int64 const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > > >]
    [+0x100] _currentPatternId : 0x0 [Type: unsigned __int64]
    [+0x108] _charBuffer      [Type: wistd::unique_ptr<enum std::byte,wil::virtualalloc_deleter>]
    [+0x110] _storage         : { size=30 } [Type: std::vector<ROW,std::allocator<ROW> >]
    [+0x130] _currentAttributes [Type: TextAttribute]
    [+0x13c] _firstRow        : 0 [Type: int]
    [+0x140] _cursor          [Type: Cursor]
    [+0x170] _size            : {LT(0, 0) RB(119, 29) [120 x 30]} [Type: Microsoft::Console::Types::Viewport]
    [+0x180] _isActiveBuffer  : true [Type: bool]

It's the one in the actual adapter call that looks messed up.

I don't think anyone can go through and change the screen buffer while the ConsoleIO thread is processing that string, but maybe I'm just bad at windbg:

image

@zadjii-msft commented on GitHub (May 4, 2023): Interesting. Looking through the dump, the text buffer of `OpenConsole!Microsoft::Console::Interactivity::ServiceLocator::s_globals.ciConsoleInformation.pCurrentScreenBuffer` does actually look sane ``` 0:007> dx -r1 (*((OpenConsole!std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> > *)0x20e19689b98)) (*((OpenConsole!std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> > *)0x20e19689b98)) [Type: std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> >] [<Raw View>] [Type: std::unique_ptr<TextBuffer,std::default_delete<TextBuffer> >] [+0x000] _renderer : 0x20e19687520 [Type: Microsoft::Console::Render::Renderer &] [+0x008] _hyperlinkMap : { size=0x0 } [Type: std::unordered_map<unsigned short,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::hash<unsigned short>,std::equal_to<unsigned short>,std::allocator<std::pair<unsigned short const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > > >] [+0x058] _hyperlinkCustomIdMap : { size=0x0 } [Type: std::unordered_map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,unsigned short,std::hash<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >,std::equal_to<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const ,unsigned short> > >] [+0x0a8] _currentHyperlinkId : 0x1 [Type: unsigned short] [+0x0b0] _idsAndPatterns : { size=0x0 } [Type: std::unordered_map<unsigned __int64,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::hash<unsigned __int64>,std::equal_to<unsigned __int64>,std::allocator<std::pair<unsigned __int64 const ,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > > >] [+0x100] _currentPatternId : 0x0 [Type: unsigned __int64] [+0x108] _charBuffer [Type: wistd::unique_ptr<enum std::byte,wil::virtualalloc_deleter>] [+0x110] _storage : { size=30 } [Type: std::vector<ROW,std::allocator<ROW> >] [+0x130] _currentAttributes [Type: TextAttribute] [+0x13c] _firstRow : 0 [Type: int] [+0x140] _cursor [Type: Cursor] [+0x170] _size : {LT(0, 0) RB(119, 29) [120 x 30]} [Type: Microsoft::Console::Types::Viewport] [+0x180] _isActiveBuffer : true [Type: bool] ``` It's the one in the actual adapter call that looks messed up. I don't _think_ anyone can go through and change the screen buffer while the ConsoleIO thread is processing that string, but maybe I'm just bad at windbg: ![image](https://user-images.githubusercontent.com/18356694/236341047-6cecba01-6ae7-41e4-a72d-f5adee91b80e.png)
claunia commented 2026-01-31 06:53:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 5, 2023):

Thoughts while trying to fall asleep:

  • Maybe defterm should always make a new window (not glom). We could add a separate compatibility.allowDefaultTerminalGlomming: false to re-enable if users REALLY want
    • We've got tear-out now. We can always just re-attach
  • maybe defterm should pass the requested size of the pty TO the terminal handler, so that the terminal starts at the size the conpty does
  • ALTERNATIVELY, the terminal handler could give back to the pty how big it should start
    • This would probably pretty negatively impact pty startup time though. Don't love that.
  • None of this remedies the issue where this adapter call is getting mysteriously dispatched to a text buffer that doesn't exist?
@zadjii-msft commented on GitHub (May 5, 2023): Thoughts while trying to fall asleep: * Maybe defterm should always make a new window (not glom). We could add a separate `compatibility.allowDefaultTerminalGlomming: false` to re-enable if users REALLY want * We've got tear-out now. We can always just re-attach * maybe defterm should pass the requested size of the pty TO the terminal handler, so that the terminal starts at the size the conpty does * ALTERNATIVELY, the terminal handler could give _back_ to the pty how big it should start * This would probably pretty negatively impact pty startup time though. Don't love that. * None of this remedies the issue where this adapter call is getting mysteriously dispatched to a text buffer that _doesn't exist_?
claunia commented 2026-01-31 06:53:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 5, 2023):

Let's assume my windbg skills around pointers/refs is just bad. REGARDLESS, in this call to AdaptDispatch::_DoLineFeed,

  • bufferHeight is 9001, which would imply that was evaluated BEFORE the console host got itself into conpty mode. That should have resized the buffer to something smaller (probably 30 rows).
  • textBuffer.GetRowByOffset is literally called on L2126, and there it didn't divide by zero. SO
  • the textBuffer got changed between L2126 and L2161. How?
  • ApiRoutines::WriteConsoleWImpl takes the lock
  • currentPosition.y == bottomMargin == 29
  • topMargin=0 !> viewport.top=0
  • viewport.bottom=30 < bufferHeight=9001 -> true
    • _api.SetViewportPosition calls to ApiRoutines::SetConsoleWindowInfoImpl
      • the first thing that does is take the console lock. Hmm. Now that this lock is a ticket_lock, is the lock re-entrant? Yea okay it's a recursive_ticket_lock
      • Then it does 
          if (g.getConsoleInformation().IsInVtIoMode())
  {
      // SetViewportRect doesn't cause the buffer to resize. Manually resize the buffer.
      RETURN_IF_NTSTATUS_FAILED(context.ResizeScreenBuffer(Viewport::FromInclusive(Window).Dimensions(), false));
  }
    • AHA
    • That's a call to SCREEN_INFORMATION::ResizeScreenBuffer, which found that gci._bWrapText was true, then called ResizeWithReflow, which sure enough, replaces the text buffer.
@zadjii-msft commented on GitHub (May 5, 2023): Let's assume my windbg skills around pointers/refs is just bad. REGARDLESS, in this call to `AdaptDispatch::_DoLineFeed`, * `bufferHeight` is 9001, which would imply that was evaluated BEFORE the console host got itself into conpty mode. That should have resized the buffer to something smaller (probably 30 rows). * `textBuffer.GetRowByOffset` is literally called on L2126, and there it didn't divide by zero. SO * the `textBuffer` got changed between L2126 and L2161. How? * `ApiRoutines::WriteConsoleWImpl` takes the lock * `currentPosition.y == bottomMargin == 29` * `topMargin=0 !> viewport.top=0` * `viewport.bottom=30 < bufferHeight=9001 -> true` * `_api.SetViewportPosition` calls to `ApiRoutines::SetConsoleWindowInfoImpl` * the _first thing_ that does is take the console lock. Hmm. Now that this lock is a `ticket_lock`, is the lock re-entrant? Yea okay it's a `recursive_ticket_lock` * Then it does ```c++ if (g.getConsoleInformation().IsInVtIoMode()) { // SetViewportRect doesn't cause the buffer to resize. Manually resize the buffer. RETURN_IF_NTSTATUS_FAILED(context.ResizeScreenBuffer(Viewport::FromInclusive(Window).Dimensions(), false)); } ``` * AHA * That's a call to `SCREEN_INFORMATION::ResizeScreenBuffer`, which found that `gci._bWrapText` was true, then called `ResizeWithReflow`, which sure enough, **replaces the text buffer**.
claunia commented 2026-01-31 06:53:17 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 5, 2023):

NOW here's a question. Why was the original text buffer 9001 rows tall? Did something happen to not immediately replace the text buffer?

If CONSOLE_INFORMATION::AllocateConsole -> output.cpp@DoCreateScreenBuffer is called before... basically the bottom of ConsoleEstablishHandoff, then the first screen buffer would be created before it's in VtIo mode.

  • IoDispatchers::ConsoleHandleConnectionRequest
    • attemptHandoff (L450)
    • ConsoleAllocateConsole (L478)
      • SetUpConsole (L906)
        • CONSOLE_INFORMATION::AllocateConsole
      • This later sets up the VtIo, so I really think this has to be after handoff

Okay, so that first screen info is created after we setup handoff. Maybe there's something in the way it's created that ignores the VtIo setup we do for defterm. Maybe we never noticed, cause terminal's usually really good about immediately requesting a resize, but in this case, the CLI app really wants to get going, before Terminal's even had it's coffee

@zadjii-msft commented on GitHub (May 5, 2023): NOW here's a question. Why was the original text buffer 9001 rows tall? Did something happen to not immediately replace the text buffer? If `CONSOLE_INFORMATION::AllocateConsole -> output.cpp@DoCreateScreenBuffer` is called before... basically the bottom of `ConsoleEstablishHandoff`, then the first screen buffer would be created before it's in VtIo mode. * `IoDispatchers::ConsoleHandleConnectionRequest` * `attemptHandoff` (L450) * `ConsoleAllocateConsole` (L478) * `SetUpConsole` (L906) * `CONSOLE_INFORMATION::AllocateConsole` * This later sets up the VtIo, so I _really_ think this has to be after handoff Okay, so that first screen info _is_ created after we setup handoff. Maybe there's something in the way it's created that ignores the VtIo setup we do for defterm. Maybe we never noticed, cause terminal's usually really good about immediately requesting a resize, but in _this_ case, the CLI app really wants to get going, before Terminal's even had it's coffee
claunia commented 2026-01-31 06:53:17 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 5, 2023):

This later sets up the VtIo

we're really gonna gloss over that huh?

CONSOLE_INFORMATION::IsInVtIoMode === VtIo::IsUsingVt === VtIo._objectsCreated, which is only set after VtIo::CreateIoHandlers.

VtIo::CreateIoHandlers is called on srvinit.cppL978, after the call to SetUpConsole on L906

@zadjii-msft commented on GitHub (May 5, 2023): > This later sets up the VtIo we're really gonna gloss over that huh? `CONSOLE_INFORMATION::IsInVtIoMode` === `VtIo::IsUsingVt` === `VtIo._objectsCreated`, which is only set after `VtIo::CreateIoHandlers`. `VtIo::CreateIoHandlers` is called on `srvinit.cpp`L978, _after_ the call to `SetUpConsole` on L906
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-DefApp In-PR Issue-Bug Needs-Tag-Fix Product-Conhost Severity-Blocking Severity-Crash
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#19773
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?