starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Crash in Monarch_::GetPID #17107

New Issue
Open
opened 2026-01-31 05:32:23 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 05:32:23 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Mar 28, 2022).

Originally assigned to: @zadjii-msft on GitHub.

This one's wild, because it don't make NO sense.

MSFT:38540483

Some verbatim Team notes, because searching teams is impossible and I won't be able to find this again

okay so second dump from bottom

0:000> lmDvmWindowsTerminal
Browse full module list
start             end                 module name
00007ff6`75e00000 00007ff6`75e75000   WindowsTerminal   (no symbols)           
    Loaded symbol image file: WindowsTerminal.exe
    Mapped memory image file: C:\ProgramData\Dbg\sym\WindowsTerminal.exe\622F96A975000\WindowsTerminal.exe
    Image path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.12.10733.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
    Image name: WindowsTerminal.exe
    Browse all global symbols  functions  data
    Timestamp:        Mon Mar 14 14:25:29 2022 (622F96A9)
    CheckSum:         00071A4E
    ImageSize:        00075000
    File version:     1.12.2203.14003
    Product version:  1.12.2203.14003
    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:
0:000> lmDvmMicrosoft_Terminal_Remoting
Browse full module list
start             end                 module name
00007ffe`ece80000 00007ffe`ecec3000   Microsoft_Terminal_Remoting   (private pdb symbols)  C:\ProgramData\Dbg\sym\Microsoft.Terminal.Remoting.pdb\A3DE2F1865ED46C490034B3D23F05EAE1\Microsoft.Terminal.Remoting.pdb
    Loaded symbol image file: Microsoft.Terminal.Remoting.dll
    Mapped memory image file: C:\ProgramData\Dbg\sym\Microsoft.Terminal.Remoting.dll\622F940D43000\Microsoft.Terminal.Remoting.dll
    Image path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.12.10733.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Remoting.dll
    Image name: Microsoft.Terminal.Remoting.dll
    Browse all global symbols  functions  data
    Timestamp:        Mon Mar 14 14:14:21 2022 (622F940D)
    CheckSum:         00047923
    ImageSize:        00043000
    File version:     1.12.2203.14003
    Product version:  1.12.2203.14003
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:

in WindowManager::_createMonarchAndCallbacks, _monarch isn't null in WindowManager::WindowManager, there's a try/catch(...) around _createMonarchAndCallbacks(). So even if that did A/V in GetPID, it should be caught (then try again)

modules look like the same version

hmmmm

but you can't catch a null pointer dereference

i was wondering if it was a torn version thing insofar as the monarch is running one version and the new executable is a different one

and it tried to create a monarch by clsid, got the old one, failed to talk to it

but that wouldn't be a A/V, would it?

would it

thats where i get scared. here's why

In one dump, i went up a few stack frames?

_monarch->m_ptr was NOT null

yea i don't see any null monarchs

and then i got to wondering

if cppwinrt-Monarch internally QIs for IMonarch and gets null, will it blow up if it hits that line

the autogenerated code doesn't show up in the debugger

#define WINRT_IMPL_SHIM(...) (*(abi_t<__VA_ARGS__>**)&static_cast<__VA_ARGS__ const&>(static_cast<D const&>(*this)))

check_hresult(WINRT_IMPL_SHIM(winrt::Microsoft::Terminal::Remoting::IMonarch)->GetPID(&result));(*(abi_t<winrt::Microsoft::Terminal::Remoting::IMonarch>**)&static_cast<winrt::Microsoft::Terminal::Remoting::IMonarch const&>(static_cast<D const&>(*this)))D is winrt::Microsoft::Terminal::Remoting::Monarchso

(*(abi_t<winrt::Microsoft::Terminal::Remoting::IMonarch>**)&static_cast<winrt::Microsoft::Terminal::Remoting::IMonarch const&>(static_cast<winrt::Microsoft::Terminal::Remoting::Monarch const&>(*this)))

(
    *(abi_t<winrt::Microsoft::Terminal::Remoting::IMonarch>**)
    &static_cast<winrt::Microsoft::Terminal::Remoting::IMonarch const&>(
        static_cast<winrt::Microsoft::Terminal::Remoting::Monarch const&>(*this)
    )
)

so maybe the old one wasn't a IMonarch

but still this would go away once folks are settled

from a cold start this shouldn't be hittable, only in the middle of an update, if that's really the truth of the matter

could we... test this?

that's my understanding

i don't know how to get it to partially stage an update

that's my big issue

that would help us test the FONT thing, the DLL thing, and now this

OH WAIT

OH OH WAIT

launch a dev build of the Terminal that doesn't have the IMonarch change, then swap out Remoting.dll/winmd and do it again?

or just

does unpackaged glom with packaged?

does unpackaged glom with unpackaged?

.....................................

if so, yeah, just unpack 10732 and 10532

unpackaged gloms to, well

hm

gloms to packaged?

so an unpackaged 10532 talking with a packaged 10732

other way perhaps

since 10732 talks IMonarchese

right

okay I can test that (in the morning)

I had 5 minutes spare

so I tested it

In the torn version state, it's much worse than I expected! It logs E_NOINTERFACE thousands and thousands of time in a tight infinite loop

Originally created by @zadjii-msft on GitHub (Mar 28, 2022). Originally assigned to: @zadjii-msft on GitHub. This one's wild, because it don't make NO sense. MSFT:38540483 <details> <summary>Some verbatim Team notes, because searching teams is impossible and I won't be able to find this again</summary> > okay so second dump from bottom > > ``` > 0:000> lmDvmWindowsTerminal > Browse full module list > start end module name > 00007ff6`75e00000 00007ff6`75e75000 WindowsTerminal (no symbols) > Loaded symbol image file: WindowsTerminal.exe > Mapped memory image file: C:\ProgramData\Dbg\sym\WindowsTerminal.exe\622F96A975000\WindowsTerminal.exe > Image path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.12.10733.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe > Image name: WindowsTerminal.exe > Browse all global symbols functions data > Timestamp: Mon Mar 14 14:25:29 2022 (622F96A9) > CheckSum: 00071A4E > ImageSize: 00075000 > File version: 1.12.2203.14003 > Product version: 1.12.2203.14003 > 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: > 0:000> lmDvmMicrosoft_Terminal_Remoting > Browse full module list > start end module name > 00007ffe`ece80000 00007ffe`ecec3000 Microsoft_Terminal_Remoting (private pdb symbols) C:\ProgramData\Dbg\sym\Microsoft.Terminal.Remoting.pdb\A3DE2F1865ED46C490034B3D23F05EAE1\Microsoft.Terminal.Remoting.pdb > Loaded symbol image file: Microsoft.Terminal.Remoting.dll > Mapped memory image file: C:\ProgramData\Dbg\sym\Microsoft.Terminal.Remoting.dll\622F940D43000\Microsoft.Terminal.Remoting.dll > Image path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.12.10733.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Remoting.dll > Image name: Microsoft.Terminal.Remoting.dll > Browse all global symbols functions data > Timestamp: Mon Mar 14 14:14:21 2022 (622F940D) > CheckSum: 00047923 > ImageSize: 00043000 > File version: 1.12.2203.14003 > Product version: 1.12.2203.14003 > File flags: 0 (Mask 3F) > File OS: 4 Unknown Win32 > File type: 2.0 Dll > File date: 00000000.00000000 > Translations: 0000.04b0 > Information from resource tables: > ``` > > in `WindowManager::_createMonarchAndCallbacks`, `_monarch` isn't null in `WindowManager::WindowManager`, there's a `try/catch(...)` around `_createMonarchAndCallbacks()`. So even if that did A/V in `GetPID`, it should be caught (then try again) > > modules look like the same version > hmmmm > > but you can't catch a null pointer dereference > > i was wondering if it was a torn version thing insofar as the monarch is running one version and the new executable is a different one > > and it tried to create a monarch by clsid, got the old one, failed to talk to it > but that wouldn't be a A/V, would it? > > would it > thats where i get scared. here's why > > In one dump, i went up a few stack frames? > > `_monarch->m_ptr` was NOT null > yea i don't see any null monarchs > and then i got to wondering > > if cppwinrt-Monarch internally QIs for IMonarch and gets null, will it blow up if it hits that line > > the autogenerated code doesn't show up in the debugger > ``` > #define WINRT_IMPL_SHIM(...) (*(abi_t<__VA_ARGS__>**)&static_cast<__VA_ARGS__ const&>(static_cast<D const&>(*this))) > ``` > > ``` > check_hresult(WINRT_IMPL_SHIM(winrt::Microsoft::Terminal::Remoting::IMonarch)->GetPID(&result));(*(abi_t<winrt::Microsoft::Terminal::Remoting::IMonarch>**)&static_cast<winrt::Microsoft::Terminal::Remoting::IMonarch const&>(static_cast<D const&>(*this)))D is winrt::Microsoft::Terminal::Remoting::Monarchso > ``` > > ``` > (*(abi_t<winrt::Microsoft::Terminal::Remoting::IMonarch>**)&static_cast<winrt::Microsoft::Terminal::Remoting::IMonarch const&>(static_cast<winrt::Microsoft::Terminal::Remoting::Monarch const&>(*this))) > ``` > > ``` > ( > *(abi_t<winrt::Microsoft::Terminal::Remoting::IMonarch>**) > &static_cast<winrt::Microsoft::Terminal::Remoting::IMonarch const&>( > static_cast<winrt::Microsoft::Terminal::Remoting::Monarch const&>(*this) > ) > ) > ``` > > so maybe the old one wasn't a IMonarch > > but still this would go away once folks are settled > > from a cold start this shouldn't be hittable, only in the middle of an update, if that's really the truth of the matter > > could we... test this? > that's my understanding > > i don't know how to get it to partially stage an update > > that's my big issue > > that would help us test the FONT thing, the DLL thing, and now this > > OH WAIT > > OH OH WAIT > launch a dev build of the Terminal that doesn't have the IMonarch change, then swap out Remoting.dll/winmd and do it again? > or just > > does unpackaged glom with packaged? > > does unpackaged glom with unpackaged? > ..................................... > if so, yeah, just unpack 10732 and 10532 > unpackaged gloms to, well > > hm > > gloms to packaged? > > so an unpackaged 10532 talking with a packaged 10732 > other way perhaps > > since 10732 talks IMonarchese > right > > okay I can test that (in the morning) > I had 5 minutes spare > > so I tested it > > In the torn version state, it's much worse than I expected! It logs E_NOINTERFACE thousands and thousands of time in a tight infinite loop </details>
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-Remoting Issue-Bug Needs-Tag-Fix Priority-1 Product-Terminal Resolution-Fix-Committed zAskModeBug zInbox-Bug
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#17107
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?