Comments (11)
Hi I'm an AI powered bot that finds similar issues based off the issue title.
Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!
Closed similar issues:
- Windows Terminal Wont Open - Logs Faulting application to Event Viewer (#14133), similarity score: 0.76
- WIndows Terminal (Preview) is missing, even though it's still installed (#2429), similarity score: 0.75
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
from terminal.
If you send a feedback via the Feedback Hub, can you please share a link here?
Additionally (or alternatively) can you go to %LOCALAPPDATA%\CrashDumps
and check if there are any WindowsTerminal.exe.dmp
files?
I am not going to reinstall windows and have to backup 1tb of data or risk it being lost over this.
It's definitely not my right to meddle, but if you're afraid of losing that data (= can't restore it some other way), and don't have a backup of that data right now, it's already as critical as it gets. As you're probably aware, even when your PC is completely switched off, any file on your SSD/HDD may randomly corrupt itself, even if the likelihood is small. The likelihood gets way larger if it's switched on. Please consider making backups of data you cannot restore some other way soon.
from terminal.
If you send a feedback via the Feedback Hub, can you please share a link here? Additionally (or alternatively) can you go to
%LOCALAPPDATA%\CrashDumps
and check if there are anyWindowsTerminal.exe.dmp
files?I am not going to reinstall windows and have to backup 1tb of data or risk it being lost over this.
It's definitely not my right to meddle, but if you're afraid of losing that data (= can't restore it some other way), and don't have a backup of that data right now, it's already as critical as it gets. As you're probably aware, even when your PC is completely switched off, any file on your SSD/HDD may randomly corrupt itself, even if the likelihood is small. The likelihood gets way larger if it's switched on. Please consider making backups of data you cannot restore some other way soon.
Feedback Hub with recording && CrashDump files shared: https://aka.ms/AAqd98q
Self-hosted .dmp files from %LOCALAPPDATA%\CrashDumps
: https://www.sign-off-the-internet-and-get-a.life/CrashDumps/
I can back up my data, it's just time consuming. It's also annoying to have to reinstall Windows over this issue, I just hoped that there would be an easier manual solution. Even if not all that easy...
I will start backing up my data, I suppose.
Please keep me posted on your findings and suggestions! Thanks for the reply, and let me know if you need anything else.
from terminal.
Regarding your system, I have bad news. All of your dumps show:
*** WARNING: Check Image - Checksum mismatch - Dump: 0x106d34, File: 0x1038b3 - C:\Symbols\sym\sym\ucrtbase.dll\81CF5D89100000\ucrtbase.dll
(That's probably C:\Windows\System32\ucrtbase.dll
.)
This corruption will probably not break your system instantly, but if you have any backup plans, I suggest making them very soon. Maybe DISM detects corruptions in ucrtbase.dll and this is just a false alarm, but this warning is mildly concerning, because one usually doesn't see it.
WindowsTerminal.exe.20628.dmp
is a crash in XAML/WinUI and is probably not what you're usually hitting.WindowsTerminal.exe.36432.dmp
is the only crash in Windows Terminal Preview 1.21 and probably the best lead. ItsFAILURE_ID_HASH
is3638c755-7d8f-cc6a-d47f-a527d4b38699
.- All the other ones are 1.19 and have no proper stack trace. Their
FAILURE_ID_HASH
is15d5ad85-1fad-32ad-f179-efa79edef8d2
which seems to be happening for a number of people since about 2024-05-02 and not just you. It seems it's exclusive to 1.19 though. It's possible that it's actually the same crash as the previous bullet point, but in disguise.
Regarding WindowsTerminal.exe.36432.dmp
: Unfortunately, you're the only person who has hit this so far. Your dump shows an error code of 0x80040154
which could be REGDB_E_CLASSNOTREG
. Googling for that doesn't bring up inspiring results, in particular when considering the checksum warning: https://stackoverflow.com/a/1496238
However, this is only a guess. It's possible that the application is crashing for you and others for a different reason. It's difficult to say what it could be, especially since the Feedback Hub item doesn't seem to be processed yet. If you want to investigate this yourself, you can install WinDbg from the app store (https://www.microsoft.com/store/productId/9PGJGD53TN86), click "Launch app package" and launch Windows Terminal Preview. You won't have source code access inside WinDbg unfortunately, but you at least get the stack traces of anything that's happening.
from terminal.
@lhecker I appreciate your experienced insight and willingness to go out of your way to help. Well explained, and suggested. I will continue to dig a bit and see what I find.. I suppose a back up + refresh / restore point is in order, ultimately. I honestly might just try win11.
If they're throwing different errors based on version, I'll try other versions also. And not sure what I'd be looking at with stack traces, but I'll do some googling and also let you know what transpires, if anything else.
No way to simply try and replace that ucrtbase.dll, eh? I don't want to download one randomly online for security reasons.. and from what I see I can't find Microsoft offering one.
Please don't close the issue yet, if you don't mind. I hope this reference helps your dev team and also anyone in the future. Thanks again!
from terminal.
No way to simply try and replace that ucrtbase.dll, eh? I don't want to download one randomly online for security reasons.. and from what I see I can't find Microsoft offering one.
Just to be clear, I'm not 100% sure if the warning is correct. It's just not something I usually see in my own Windows 10 dumps. I can give you my C:\Symbols\sym\sym\ucrtbase.dll\81CF5D89100000\ucrtbase.dll
file: ucrtbase.zip
If you open its properties and go to the Signatures tab, you should see that it's signed by Microsoft.
Edit: Oh, I almost forgot to mention:
Before you replace it, could you check if their checksums match? If you don't know how, launch PowerShell and run:
Get-FileHash SHA1 <path>
If they don't match, could you upload your version as a .zip here? We'd be interested to see what the differences are. (You should also keep a copy yourself of course, just to be sure.)
Please don't close the issue yet, if you don't mind.
For what it's worth, I'm not 100% sure it's because of just your system. We do have an overall increase in 15d5ad85-1fad-32ad-f179-efa79edef8d2
crashes after all. So, I fully agree with you.
from terminal.
@lhecker Hey, Sorry it's been over a week. I've been meaning to reply, finally got some time to sit down and analyze some things.
The SHA-1 of the .dll file you provided C:\Users\hazey\Downloads\ucrtbase\ucrtbase.dll
matches the .dll file path being shown in WinDbg .dmp file logs WARNING: Check Image - Checksum mismatch - Dump: 0x106d34, File: 0x1038b3 - C:\ProgramData\Dbg\sym\ucrtbase.dll\81CF5D89100000\ucrtbase.dll
on my end.
PS C:\> Get-FileHash -Path "C:\Users\hazey\Downloads\ucrtbase\ucrtbase.dll" -Algorithm SHA1
Algorithm Hash Path
--------- ---- ----
SHA1 35C04E8403FB7BC7FCF7868B51ABC6BD499C5192 C:\Users\hazey\Downloads\ucrtbase\ucrtbase.dll
PS C:\> Get-FileHash -Path "C:\ProgramData\Dbg\sym\ucrtbase.dll\81CF5D89100000\ucrtbase.dll" -Algorithm SHA1
Algorithm Hash Path
--------- ---- ----
SHA1 35C04E8403FB7BC7FCF7868B51ABC6BD499C5192 C:\ProgramData\Dbg\sym\ucrtbase.dll\81CF5D89100000\ucrtbase.dll
However, I am failing to see how this is relevant - or where the .dmp files got that .dll path & file, unless it creates a new version of the .dll in that path upon hitting the error or upon running WinDbg. I believe that is the case, because that .dll shows a file creation date of May 15, 2024 which is when I ran the WinDbg again.
Point being, it does not match the SHA-1 checksum on the .dll in the notes on the error in the Event Viewer logs wherein it shows Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
PS C:\> Get-FileHash -Path "C:\WINDOWS\System32\ucrtbase.dll" -Algorithm SHA1
Algorithm Hash Path
--------- ---- ----
SHA1 F156A272DBC6695CC170B6091EF8CD41DB7BA040 C:\WINDOWS\System32\ucrtbase.dll
Again, as per relevance, I'm going through these other details in this response because A)
I am involved in cyber security pentesting and for all I know I could have a malicious DLL here (I will note on this further shortly) and B)
I don't really know 100% of what I'm looking at here, for all I know any of this information could potentially help you and your team or possibly give us some new insight on other things to check, at your discretion. So apologies if it seems like a lot.
After reading your last response, on May 15th I took it upon myself to install and evaluate multiple different versions of WindowsTerminal.. from 1.21 back to about 1.15-ish. I think I skipped 1.16, maybe 1.17... Same issue - runs first time when launched from install - or from Windows Store if the version matches to one on there - otherwise crashes when trying to open from file, taskbar search, or "run" (WindowsKey+R).
I also downloaded WinDbg as you suggested, and also ran it on all the .dmp files that I sent you from the previous session.
STRANGELY -- I am not getting the same FAILURE_ID_HASH
-- even on the same .dmp files you processed from that first session?? I don't think the Failure ID Hash differs from PC to PC, or session to session, based on your statement that you're getting duplicate failure hashes from multiple users...
-
For
WindowsTerminal.exe.36432.dmp
I gotFAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}
which doesn't match yours, for Windows Terminal Preview v1.21 -
For
WindowsTerminal.exe.22232.dmp
&WindowsTerminal.exe.21672.dmp
&WindowsTerminal.exe.20104.dmp
I got the sameFAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}
for Windows Terminal v1.19 -- all of which are either different installs or me just trying to open the program a different time.- ^^ All have
ERROR_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."
- ^^ All have
-
For
WindowsTerminal.exe.20628.dmp
which I believe is for Windows Terminal v1.21 I gotFAILURE_ID_HASH: {b9efb0c8-7ba7-8f0b-b47a-fd1770cb6293}
which doesn't match yours, but same error with the WinUI/XAML.- ^^ Which is
ERROR_CODE: (NTSTATUS) 0xc0000005
- "The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s."
- ^^ Which is
CrashDumps_from_May13-2024.zip -- All crash dumps from May 13th for Windows Terminal versions 1.19 & 1.21
WinDbg_log_WindowsTerminal_dmp_files_from_May13-2024.txt -- WinDbg logs from the May 13th .dmp files I ran. (I only did the recent most 5 .dmp files, figuring they'd all be similar.).
May 15th 2024 retry of different versions:
v1.19.11213:
- WindowsTerminal.exe.30236.dmp
- FAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}
v1.20.11271:
- WindowsTerminal.exe.26772.dmp
- FAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}
v1.21.11271:
- WindowsTerminal.exe.21276.dmp
- FAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}
v1.18.10301:
- WindowsTerminal.exe.29988.dmp
- FAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}
v1.15.2524:
- WindowsTerminal.exe.27824.dmp
- FAILURE_ID_HASH: {e31753ac-c98a-8055-3663-47e707543d20}
^^ ALL ERROR_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."
CrashDumps_from_May15-2024.zip - All .dmp files from May 15th, 2024
WinDbg_log_WindowsTerminal_dmp_files_from_May15-2024.txt - WinDbg logs for .dmp files from May 15th, 2024
May 22nd, 2024 - retry of v1.19 from MS Store:
v1.19.11213:
- WindowsTerminal.exe.32660.dmp
FAILURE_ID_HASH: {2f8ddf11-773f-f784-ac2b-d6c9d216b29e}
^^ ERROR_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."
CrashDump_from_May22-2024.zip - .dmp file from May 22nd, 2024
WinDbg_log_WindowsTerminal_dmp_files_from_May22-2024.txt - WinDbg log file for the .dmp from May 22nd, 2024
Okay, so as you can see -- I am getting completely different FAILURE_ID_HASH values on different dates, for different versions (save for the one WinUI/XML error which is an outlier) -- but they all have the same ERROR_CODE.
As I alluded to earlier in the post, I am a cybersecurity hobbyist. I have to wonder if I have a poisoned DLL file in ucrtbase.dll, especially after seeing that error message ERROR_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.
I ran Norton on both ucrtbase.dll files that I gave you the SHA-1 checksums for, no red flags. However, I know that does not mean anything. Perhaps it's severe speculation, but I have to wonder, because it is very possible. Even though, I do not even play with malware on purpose, or at all - for that matter. I do CTF events, etc, and some minor research on web apps and systems. Nothing ever outside of a virtual machine.
Anyway, tell me what you think. If nothing else, then I am going to backup my data this weekend and do the windows refresh. I actually just built a brand new PC with Win 11 Pro so in the end, this won't matter much for me. Regardless, I would still like to get to the bottom of it, even if it only helps you guys out in any form.
Here is the ucrtbase.dll from C:\Windows\System32\ucrtbase.dll
which is the initial .dll used which is throwing the error as seen in Event Viewer, and does not match your file checksum:
ucrtbase_dll_from_C-Windows-System32-ucrtbase_dll.zip
Here is the ucrtbase.dll from C:\ProgramData\Dbg\sym\ucrtbase.dll\81CF5D89100000\ucrtbase.dll
even though you only wanted it if the checksum did not match, just want to send everything:
ucrtbase_dll_from_C-ProgramData-Dbg-sym.zip
The WinDbg logs state *** WARNING: Check Image - Checksum mismatch - Dump: 0x106d34, File: 0x1038b3 - C:\ProgramData\Dbg\sym\ucrtbase.dll\81CF5D89100000\ucrtbase.dll
so, who knows if that is relevant or not...
Thanks again, let me know if you need anything else.
PS: Perhaps you'll also find some different, helpful info in the stack trace / STACK_TEXT of some of these.
from terminal.
Worth noting that I found yesterday.. searching and opening "CMD" "PowerShell" or "WSL" in Windows search/start button opens the respective tool right in Windows terminal v1.19 without an issue. Whereas trying to open "wt" or "wt.exe" - whether from search, run, or the direct file in its folder - causes this issue described in this thread.
Very strange. I don't know if there is more information I can offer you that would help you understand more of what is occurring here, but if there is then please let me know. I did some searching around, and installed Process Explorer from SysInternals. Just starting to dig around now, not sure what I'm looking for but it shows ucrtbase.dll & Microsoft.UI.Xaml.dll running just fine in the above-mentioned instances.
I don't want to give you guys more issues to worry about than you need, if this whole task seems null to you then that's fine. I would genuinely like to think that it's worth solving a potential issue that many others may encounter. If you think it's just a one-off occurrence due to my PC or Windows having an error, I can live with backing up data/reinstalling Windows. As mentioned, I built a new PC last week so that would be the route I end up going anyway.
Just wanted to share that new piece of info at the top. Let me know if I can get you anything else. Thanks again!
from terminal.
Hello, I came across this case and I would like to add my observations about this problem just to help you guys understand more deeply what could be the cause of this issue (at the risk of repeating already known information).
We have several clients who are experiencing the same issue : when trying to launch an application through Windows Terminal from our application, it crashes and only informs us about the fact that the process has been terminated.
What we know
- The faulting module is the previously mentioned
ucrtbase.dll
generating the error code0xC0000409
(STATUS_FAIL_FAST_EXCEPTION) - I found the crash report stating theses errors which contains more complete information about it. I will send it soon in another post when our security team will confirm no critical information is shown in it.
- As we can see here in the Event Viewer the BEX64 EventName is displayed, which states that there is a memory access violation.
Here are the arguments passed to the ProcessStartInfo C# object : cmd /c "C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2404.10.0_x64__8wekyb3d8bbwe\Notepad\Notepad.exe"
Thanks in advance !
from terminal.
Hey there,
Came back this morning to make the dump file and found out it is working now... Still with the QA team trying to reproduce the issue.
EDIT
One of our QA team member was still able to reproduce the issue (OS BUILD = 22621.3593, Windows Terminal Version = 1.20.11381.0).
Weirdly I still am not able to remake the crash happen... Here is the crash report file from last week :
Here is also the process dump file from this QA Team member :
from terminal.
Okay well, that dump was a RemoteDesktopManger dump, so that wasn't helpful, but maybe the .wer
is?
OpenConsole.exe
Description
Faulting Application Path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalCanary_1.22.1591.0_x64__8wekyb3d8bbwe\OpenConsole.exe
Creation Time: 6/12/2024 6:14:55 AM
Problem: Stopped responding and was closed
Status: Report sent
Problem signature
Problem Event Name: MoAppHang
Package Full Name: Microsoft.WindowsTerminalCanary_1.22.1591.0_x64__8wekyb3d8bbwe
Application Name: praid:App
Application Version: 1.22.2406.7001
Application Timestamp: 6663385c
Hang Signature: 844c
Hang Type: 2097152
Extra information about the problem
Bucket ID: 5ee8e7973455ba78b3b8b4e9f02b10fa (1421084599285125370)
5ee8e797-3455-ba78-b3b8-b4e9f02b10fa
is something. But IRONICALLY, the only dump in there is a moapplication_hang_cfffffff_microsoft.windowsterminalcanary!hang_quiesce
from my own machine. That only ever happens when the OS kills an app (to install updates, usually?)
weird.
from terminal.
Related Issues (20)
- Terminal closes when store tries to update $(id) HOT 1
- Terminal becomes extremely laggy after printing large amount of CJK characters HOT 4
- Terminal update crashes all running applications HOT 3
- Snippets & useCommandline don't account for grapheme clusters quite right
- Can't wake up a closed headless window HOT 1
- PHP Artsan command not recognised as URI HOT 2
- No response when open windows terminal HOT 7
- CSI 58 (undercurl color) sequence misbehaves when in "legacy ANSI" format HOT 11
- Pressing ESC + j or k will equal to Alt + j or k when using Neovim in Windows Terminal
- Suggest me code for this.
- I like some suggestions hare.
- Clicked URL contains unwanted delimiter HOT 3
- Crash when exiting a tab with the debug tap HOT 2
- Font loading faults after Windows update KB5039212 HOT 5
- Changing a value belonging to Resources.resw under Microsoft.Terminal.Control.Lib causes build to fail.
- Better Warnings for Custom Pixel Shader Compilation Failures
- Windows key doesn't work when assigning key actions
- Escape sequence leaking to terminal on starting/attaching `tmux` (over `ssh`) HOT 2
- BUG: Error in TypeData "Microsoft.PowerShell.DeserializingTypeConverter": Cannot create an instance of the type converter for type Microsoft.PowerShell.DeserializingTypeConverter due to exception: The type initializer for 'Microsoft.PowerShell.DeserializingTypeConverter' threw an exception.. , and 3 another errors HOT 1
- Pasting multiline text not working (in shell, vi and hangs kakoune) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terminal.