starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows Terminal crashes daily at exact same time with Access Violation in TerminalApp.dll #23965

New Issue
Closed
opened 2026-01-31 08:57:33 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 08:57:33 +00:00
Owner
Copy Link

Originally created by @LadyCailin on GitHub (Jan 15, 2026).

Windows Terminal version

1.23.13503.0

Windows build number

10.0.26200.0

Other Software

Claude Code, latest version (possibly)

Steps to reproduce

The crash occurs almost every night at exactly 04:41:02 local time (03:41:02 UTC) without any user interaction. The machine is idle overnight with Terminal left running.

  1. Open Windows Terminal with one or more tabs
  2. Leave Terminal running overnight
  3. Terminal crashes at 04:41:02 local time

This has occurred on consecutive nights with identical crash signatures.

Expected Behavior

Windows Terminal should remain running and stable when idle, regardless of background system activity.

Actual Behavior

Terminal crashes with an access violation at a precise, repeatable time every night. All tabs and session state are lost.

Crash details

The crash signature is identical across all occurrences:

Faulting application name: WindowsTerminal.exe, version: 1.23.2512.16003
Faulting module name: TerminalApp.dll, version: 1.23.2512.16003
Exception code: 0xc0000005 (Access Violation)
Fault offset: 0x000000000008d0bc
Faulting package: Microsoft.WindowsTerminal_1.23.13503.0_x64__8wekyb3d8bbwe

Event log evidence

Application Error events (Event ID 1000):

Date: 2026-01-15T03:41:02.867Z
Faulting application name: WindowsTerminal.exe, version: 1.23.2512.16003
Faulting module name: TerminalApp.dll, version: 1.23.2512.16003
Exception code: 0xc0000005
Fault offset: 0x000000000008d0bc
Report Id: 2290504d-ece9-46fc-9afc-ceaed0dc59db

Date: 2026-01-14T03:41:02.638Z
Faulting application name: WindowsTerminal.exe, version: 1.23.2512.16003
Faulting module name: TerminalApp.dll, version: 1.23.2512.16003
Exception code: 0xc0000005
Fault offset: 0x000000000008d0bc
Report Id: f6093847-a1a4-49e6-9388-c31eb6acadf1

Key observations

  1. Exact timing precision: The crash occurs at the same second (04:41:02) on consecutive days. This is not random - something deterministic is triggering it.
  2. Identical fault offset: The crash always occurs at offset 0x000000000008d0bc in TerminalApp.dll, suggesting the same code path is failing.
  3. Correlated system events: System event logs show the following activity within seconds of the crash:
  • IsolatedUserMode/Secure Trustlet events (NgcIso.exe - Windows Hello credential operations) (slightly after the crash)
  • Virtual Disk Service start/stop events (slightly before the crash)
  1. No user interaction: The crash occurs while the machine is idle overnight.

Possible contributing factors

  • Terminal sessions had been running for extended periods (8+ hours)
  • Acrylic transparency effects are enabled in settings
  • Usage includes CLI applications that generate substantial terminal output
  • Corporate domain-joined machine with security policies

I've uploaded the crash dump via feedback hub: https://aka.ms/AAz9rc3

(Problem investigated and summarized by claude, approved by me, a human).

Originally created by @LadyCailin on GitHub (Jan 15, 2026). ### Windows Terminal version 1.23.13503.0 ### Windows build number 10.0.26200.0 ### Other Software Claude Code, latest version (possibly) ### Steps to reproduce The crash occurs almost every night at exactly 04:41:02 local time (03:41:02 UTC) without any user interaction. The machine is idle overnight with Terminal left running. 1. Open Windows Terminal with one or more tabs 2. Leave Terminal running overnight 3. Terminal crashes at 04:41:02 local time This has occurred on consecutive nights with identical crash signatures. ### Expected Behavior Windows Terminal should remain running and stable when idle, regardless of background system activity. ### Actual Behavior Terminal crashes with an access violation at a precise, repeatable time every night. All tabs and session state are lost. Crash details The crash signature is identical across all occurrences: Faulting application name: WindowsTerminal.exe, version: 1.23.2512.16003 Faulting module name: TerminalApp.dll, version: 1.23.2512.16003 Exception code: 0xc0000005 (Access Violation) Fault offset: 0x000000000008d0bc Faulting package: Microsoft.WindowsTerminal_1.23.13503.0_x64__8wekyb3d8bbwe Event log evidence Application Error events (Event ID 1000): Date: 2026-01-15T03:41:02.867Z Faulting application name: WindowsTerminal.exe, version: 1.23.2512.16003 Faulting module name: TerminalApp.dll, version: 1.23.2512.16003 Exception code: 0xc0000005 Fault offset: 0x000000000008d0bc Report Id: 2290504d-ece9-46fc-9afc-ceaed0dc59db Date: 2026-01-14T03:41:02.638Z Faulting application name: WindowsTerminal.exe, version: 1.23.2512.16003 Faulting module name: TerminalApp.dll, version: 1.23.2512.16003 Exception code: 0xc0000005 Fault offset: 0x000000000008d0bc Report Id: f6093847-a1a4-49e6-9388-c31eb6acadf1 Key observations 1. Exact timing precision: The crash occurs at the same second (04:41:02) on consecutive days. This is not random - something deterministic is triggering it. 2. Identical fault offset: The crash always occurs at offset 0x000000000008d0bc in TerminalApp.dll, suggesting the same code path is failing. 3. Correlated system events: System event logs show the following activity within seconds of the crash: - IsolatedUserMode/Secure Trustlet events (NgcIso.exe - Windows Hello credential operations) (slightly after the crash) - Virtual Disk Service start/stop events (slightly before the crash) 4. No user interaction: The crash occurs while the machine is idle overnight. Possible contributing factors - Terminal sessions had been running for extended periods (8+ hours) - Acrylic transparency effects are enabled in settings - Usage includes CLI applications that generate substantial terminal output - Corporate domain-joined machine with security policies I've uploaded the crash dump via feedback hub: https://aka.ms/AAz9rc3 (Problem investigated and summarized by claude, approved by me, a human).
claunia commented 2026-01-31 08:57:36 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 15, 2026):

Your dumps point at MSFT-56758947, which happens inside winrt::TerminalApp::implementation::TerminalWindow::ShowDialog. One of them happens when accessing XamlRoot(), the other when accessing _Dispatcher. This:
04bcba39ae/src/cascadia/TerminalApp/TerminalWindow.cpp (L353-L356)

and this:
04bcba39ae/src/cascadia/TerminalApp/TerminalWindow.cpp (L338-L339)

Both of those have in common that we're not protecting ourselves from this destroying itself in the meantime. We need to add a weak_ref there and stop using this.

@lhecker commented on GitHub (Jan 15, 2026): Your dumps point at MSFT-56758947, which happens inside `winrt::TerminalApp::implementation::TerminalWindow::ShowDialog`. One of them happens when accessing `XamlRoot()`, the other when accessing `_Dispatcher`. This: https://github.com/microsoft/terminal/blob/04bcba39ae7758adc287e3bb50ba0c05a2825985/src/cascadia/TerminalApp/TerminalWindow.cpp#L353-L356 and this: https://github.com/microsoft/terminal/blob/04bcba39ae7758adc287e3bb50ba0c05a2825985/src/cascadia/TerminalApp/TerminalWindow.cpp#L338-L339 Both of those have in common that we're not protecting ourselves from `this` destroying itself in the meantime. We need to add a `weak_ref` there and stop using `this`.
claunia commented 2026-01-31 08:57:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 15, 2026):

Curious though - why is Terminal displaying a dialog at exactly the same time every night?

@DHowett commented on GitHub (Jan 15, 2026): Curious though - why is Terminal displaying a dialog at exactly the same time every night?
claunia commented 2026-01-31 08:57:36 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 15, 2026):

Going through our co_awaits I see a lot more opportunities for crashes. I'll try to fix them all (conservatively).

@lhecker commented on GitHub (Jan 15, 2026): Going through our `co_await`s I see a lot more opportunities for crashes. I'll try to fix them all (conservatively).
claunia commented 2026-01-31 08:57:36 +00:00
Author
Owner
Copy Link

@LadyCailin commented on GitHub (Jan 16, 2026):

Curious though - why is Terminal displaying a dialog at exactly the same time every night?

You know, this is a good question! I didn't know this could be related to dialogs, but now that I do, I have been having a weird issue with the terminal:

Image

This occurs whenever I switch the OS to dark mode, and it for some reason automatically switches back to light mode. I assumed this was a bug in the OS, that affects the terminal, but I have no clue! But this might be related.

@LadyCailin commented on GitHub (Jan 16, 2026): > Curious though - why is Terminal displaying a dialog at exactly the same time every night? You know, this is a good question! I didn't know this could be related to dialogs, but now that I do, I have been having a weird issue with the terminal: <img width="1728" height="918" alt="Image" src="https://github.com/user-attachments/assets/24cc72ce-108f-490b-9461-442d74ffa53f" /> This occurs whenever I switch the OS to dark mode, and it for some reason automatically switches back to light mode. I assumed this was a bug in the OS, that affects the terminal, but I have no clue! But this might be related.
claunia commented 2026-01-31 08:57:36 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 16, 2026):

You're hitting #19505. We aren't sure yet why it happens but have an idea how to fix it. The only bad news is that fixing this is a bit involved...

@lhecker commented on GitHub (Jan 16, 2026): You're hitting #19505. We aren't sure yet why it happens but have an idea how to fix it. The only bad news is that fixing this is a bit involved...
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-Windowing Issue-Bug Needs-Tag-Fix Priority-1 Product-Terminal 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#23965
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?