Windows Terminal will not open #21702

@github-actions[bot] commented on GitHub (May 13, 2024):

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.

@github-actions[bot] commented on GitHub (May 13, 2024): 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)](https://github.com/microsoft/terminal/issues/14133), similarity score: 0.76 - [WIndows Terminal (Preview) is missing, even though it's still installed (#2429)](https://github.com/microsoft/terminal/issues/2429), similarity score: 0.75 > Note: You can give me feedback by thumbs upping or thumbs downing this comment.

claunia commented

@lhecker commented on GitHub (May 13, 2024):

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.

@lhecker commented on GitHub (May 13, 2024): 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.

claunia commented

@hazeyez commented on GitHub (May 13, 2024):

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.

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.

@hazeyez commented on GitHub (May 13, 2024): > 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. 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.

claunia commented

@lhecker commented on GitHub (May 13, 2024):

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. Its FAILURE_ID_HASH is 3638c755-7d8f-cc6a-d47f-a527d4b38699.
All the other ones are 1.19 and have no proper stack trace. Their FAILURE_ID_HASH is 15d5ad85-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.

@lhecker commented on GitHub (May 13, 2024): 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. Its `FAILURE_ID_HASH` is `3638c755-7d8f-cc6a-d47f-a527d4b38699`. * All the other ones are 1.19 and have no proper stack trace. Their `FAILURE_ID_HASH` is `15d5ad85-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.

claunia commented

@hazeyez commented on GitHub (May 14, 2024):

@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!

@hazeyez commented on GitHub (May 14, 2024): @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!

claunia commented

@lhecker commented on GitHub (May 14, 2024):

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:
⚠️ PLEASE ONLY REPLACE IT AFTER MAKING BACKUPS! ⚠️ Almost every application uses ucrtbase.dll. If anything is wrong with my version, then Windows will not boot anymore.

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.

@lhecker commented on GitHub (May 14, 2024): > 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](https://github.com/microsoft/terminal/files/15314350/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: ⚠️ **PLEASE ONLY REPLACE IT AFTER MAKING BACKUPS!** ⚠️ Almost every application uses ucrtbase.dll. If anything is wrong with my version, then Windows will not boot anymore. Before you replace it, could you check if their checksums match? If you don't know how, launch PowerShell and run: ```pwsh 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.

claunia commented

@hazeyez commented on GitHub (May 24, 2024):

@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 got FAILURE_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 same FAILURE_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."
For WindowsTerminal.exe.20628.dmp which I believe is for Windows Terminal v1.21 I got FAILURE_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."

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.

@hazeyez commented on GitHub (May 24, 2024): @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 got `FAILURE_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 same `FAILURE_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." - For `WindowsTerminal.exe.20628.dmp` which I believe is for **Windows Terminal v1.21** I got `FAILURE_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." [CrashDumps_from_May13-2024.zip](https://github.com/microsoft/terminal/files/15439630/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](https://github.com/microsoft/terminal/files/15439657/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](https://github.com/microsoft/terminal/files/15439802/CrashDumps_from_May15-2024.zip) - All .dmp files from May 15th, 2024 [WinDbg_log_WindowsTerminal_dmp_files_from_May15-2024.txt](https://github.com/microsoft/terminal/files/15439805/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](https://github.com/microsoft/terminal/files/15439838/CrashDump_from_May22-2024.zip) - .dmp file from May 22nd, 2024 [WinDbg_log_WindowsTerminal_dmp_files_from_May22-2024.txt](https://github.com/microsoft/terminal/files/15439849/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](https://github.com/microsoft/terminal/files/15439997/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](https://github.com/microsoft/terminal/files/15440012/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.

claunia commented

@hazeyez commented on GitHub (May 29, 2024):

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!

@hazeyez commented on GitHub (May 29, 2024): 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!

claunia commented

@NBeauregard21 commented on GitHub (Jun 6, 2024):

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 code 0xC0000409 (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 !

@NBeauregard21 commented on GitHub (Jun 6, 2024): 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 1. The faulting module is the previously mentioned `ucrtbase.dll` generating the error code `0xC0000409` ([STATUS_FAIL_FAST_EXCEPTION](https://learn.microsoft.com/en-us/shows/inside/c0000409)) 2. 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. 3. As we can see here in the Event Viewer the [BEX64](https://answers.microsoft.com/en-us/windows/forum/all/help-with-a-bex-error/77a5ba88-b193-4b47-abea-ee25dc150f5f#:~:text=BEX%20errors%20are%20typically%20raised,in%20a%20region%20of%20memory.) EventName is displayed, which states that there is a memory access violation. ![image](https://github.com/microsoft/terminal/assets/135652760/e8c22fce-4f9e-4d34-a08a-16d7fbaf681d) 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 !

claunia commented

AppCrash_WindowsTerminal._965cf8b56c1e7afb1637ef98838bb0927c916e1f_8ab01042_3c3eaea9-e9da-4577-8226-c117e3efef89.zip

@NBeauregard21 commented on GitHub (Jun 10, 2024):

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 :

Process dump (2).zip

@NBeauregard21 commented on GitHub (Jun 10, 2024): 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 : [AppCrash_WindowsTerminal._965cf8b56c1e7afb1637ef98838bb0927c916e1f_8ab01042_3c3eaea9-e9da-4577-8226-c117e3efef89.zip](https://github.com/user-attachments/files/15768753/AppCrash_WindowsTerminal._965cf8b56c1e7afb1637ef98838bb0927c916e1f_8ab01042_3c3eaea9-e9da-4577-8226-c117e3efef89.zip) Here is also the process dump file from this QA Team member : [Process dump (2).zip](https://github.com/user-attachments/files/15774079/Process.dump.2.zip)

claunia commented

@zadjii-msft commented on GitHub (Jun 12, 2024):

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.

@zadjii-msft commented on GitHub (Jun 12, 2024): 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.

claunia commented

@DHowett commented on GitHub (Jul 3, 2024):

bucket bed4d8196fdb2fdef2c863af506e661d looks like it contains something

@DHowett commented on GitHub (Jul 3, 2024): bucket `bed4d8196fdb2fdef2c863af506e661d` looks like it contains something

claunia commented