[DefApp] PowerShell opened via Win+X errors 50% of the time #14010

@miniksa commented on GitHub (May 28, 2021):

I don't like this 50% business but I'll get to this.

I wonder if it's related to the #10134 one because I swear I get that one to work just fine about 10% of the time...

@miniksa commented on GitHub (May 28, 2021): I don't like this 50% business but I'll get to this. I wonder if it's related to the #10134 one because I swear I get that one to work just fine about 10% of the time...

claunia commented

@zadjii-msft commented on GitHub (Jul 7, 2021):

@miniksa with #10134 merged, will we need to wait for a new Insiders flight to confirm if that fixed this?

@zadjii-msft commented on GitHub (Jul 7, 2021): @miniksa with #10134 merged, will we need to wait for a new Insiders flight to confirm if that fixed this?

claunia commented

@miniksa commented on GitHub (Jul 7, 2021):

@miniksa with #10134 merged, will we need to wait for a new Insiders flight to confirm if that fixed this?

Yes. I checked MSFT:33707417 payload tracking today and it's still percolating. It looks like it reached main on Thursday... but it's not reporting a build number yet.

@miniksa commented on GitHub (Jul 7, 2021): > @miniksa with #10134 merged, will we need to wait for a new Insiders flight to confirm if that fixed this? Yes. I checked MSFT:33707417 payload tracking today and it's still percolating. It looks like it reached `main` on Thursday... but it's not reporting a build number yet.

claunia commented

https://user-images.githubusercontent.com/5821575/125908076-f9d2040c-aaec-4f7e-b945-3c011abe92e0.mp4

@ianjoneill commented on GitHub (Jul 16, 2021):

I just checked with the latest Windows 11 build (10.0.22000.71) and terminal preview build (1.10.1933.0) and unfortunately I'm still seeing this.

I can't repro it via the Win + X menu any more, as the shortcut now leads to Windows Terminal directly.

I can repro it though by just searching for cmd in start and pressing enter. It's probably less prevalent than it was (maybe 15% of the time now), but it still happens.

It doesn't fail fast and display the error box like it used to any more either, it just seems to hang until you kill the terminal process, then the error box pops up afterwards.

Contents of the error dialog is the same as previously:

---------------------------
cmd.exe - Application Error
---------------------------
The application was unable to start correctly (0xc0000142). Click OK to close the application. 
---------------------------
OK   
---------------------------

Screen recording below. As shown in the video I created dumps of each process, so I can send you a OneDrive link if you think they'd be useful.

@ianjoneill commented on GitHub (Jul 16, 2021): I just checked with the latest Windows 11 build (10.0.22000.71) and terminal preview build (1.10.1933.0) and unfortunately I'm still seeing this. I can't repro it via the Win + X menu any more, as the shortcut now leads to Windows Terminal directly. I can repro it though by just searching for `cmd` in start and pressing enter. It's probably less prevalent than it was (maybe 15% of the time now), but it still happens. It doesn't fail fast and display the error box like it used to any more either, it just seems to hang until you kill the terminal process, then the error box pops up afterwards. Contents of the error dialog is the same as previously: ``` --------------------------- cmd.exe - Application Error --------------------------- The application was unable to start correctly (0xc0000142). Click OK to close the application. --------------------------- OK --------------------------- ``` Screen recording below. As shown in the video I created dumps of each process, so I can send you a OneDrive link if you think they'd be useful. https://user-images.githubusercontent.com/5821575/125908076-f9d2040c-aaec-4f7e-b945-3c011abe92e0.mp4

claunia commented

2026-01-31 03:58:24 +00:00

@miniksa commented on GitHub (Jul 16, 2021):

That is particularly curious. Yes please. I would love to have the dumps. Just beware they may contain sensitive information. You could DM me on Twitter if you don't want to share it publicly. Or you could probably guess my work email address based on my GH user name, but I can't guarantee the spam filter wouldn't lose you for me.

@miniksa commented on GitHub (Jul 16, 2021): That is particularly curious. Yes please. I would love to have the dumps. Just beware they may contain sensitive information. You could DM me on Twitter if you don't want to share it publicly. Or you could probably guess my work email address based on my GH user name, but I can't guarantee the spam filter wouldn't lose you for me.

claunia commented

2026-01-31 03:58:24 +00:00

@ianjoneill commented on GitHub (Jul 17, 2021):

I've sent you an email with a OneDrive link. Let me know if you get it or not.

I've never sent a tweet or DM, so I get the impression Twitter's spam filters would also prevent the message getting through - though if you don't get the email I can try.

@ianjoneill commented on GitHub (Jul 17, 2021): I've sent you an email with a OneDrive link. Let me know if you get it or not. I've never sent a tweet or DM, so I get the impression Twitter's spam filters would also prevent the message getting through - though if you don't get the email I can try.

claunia commented

2026-01-31 03:58:25 +00:00

@miniksa commented on GitHub (Jul 19, 2021):

I got it. I hope to have time to look today or tomorrow. Appreciated!

@miniksa commented on GitHub (Jul 19, 2021): I got it. I hope to have time to look today or tomorrow. Appreciated!

claunia commented

2026-01-31 03:58:25 +00:00

@ianjoneill commented on GitHub (Jul 19, 2021):

No problem - I know from first hand experience that debugging something you can't repro locally can be somewhat difficult, so if you need anything else just let me know.

@ianjoneill commented on GitHub (Jul 19, 2021): No problem - I know from first hand experience that debugging something you can't repro locally can be somewhat difficult, so if you need anything else just let me know.

claunia commented

2026-01-31 03:58:25 +00:00

@miniksa commented on GitHub (Jul 20, 2021):

@ianjoneill it looks like the processes you dumped there from inside the packaged application are in a normal state. I'm suspecting a bug in my OS code (that lives outside the package and will appear in a different process.)

The process I need is the conhost.exe started from C:\windows\system32\ that is created by the cmd.exe that you launch from the run box.

It's a little difficult to figure out which one that is.

If you use Process Explorer, it will be the cmd.exe hanging under explorer.exe (because you used Explorer's run box) and then the conhost.exe hanging under that:

You should be able to Right Click and Create Dump of it when it's in this state and send it to me and I can check the OS side of the fence too.

Also are you still using 10.0.21390.1, 1.9.1445.0?
I made an OS side change in 10.0.22000.65 that combines with a fix in 1.10.1933.0 to improve reliability of the connection and fix a few bugs.

Thanks!

@miniksa commented on GitHub (Jul 20, 2021): @ianjoneill it looks like the processes you dumped there from inside the packaged application are in a normal state. I'm suspecting a bug in my OS code (that lives outside the package and will appear in a different process.) The process I need is the `conhost.exe` started from `C:\windows\system32\` that is created by the `cmd.exe` that you launch from the run box. It's a little difficult to figure out which one that is. If you use [Process Explorer](https://docs.microsoft.com/sysinternals/downloads/process-explorer), it will be the `cmd.exe` hanging under `explorer.exe` (because you used Explorer's run box) and then the `conhost.exe` hanging under that: ![image](https://user-images.githubusercontent.com/18221333/126397143-94d25b73-6ed9-4d4f-9a1c-f30f8d4864ea.png) You should be able to Right Click and Create Dump of it when it's in this state and send it to me and I can check the OS side of the fence too. Also are you still using 10.0.21390.1, 1.9.1445.0? I made an OS side change in 10.0.22000.65 that combines with a fix in 1.10.1933.0 to improve reliability of the connection and fix a few bugs. Thanks!

claunia commented

@miniksa commented on GitHub (Jul 20, 2021):

Actually if I'm less of a goof... I can see you're on 1.10.1933.0 of the Windows Terminal Preview, but that your OS version is 22000.1. So perhaps you don't have my OS-side fixes yet but you do have the Terminal Preview where I updated the interface. So it could just be the interface version mismatch tripping you up now, where the bugs I fixed were tripping you up before.

@miniksa commented on GitHub (Jul 20, 2021): Actually if I'm less of a goof... I can see you're on 1.10.1933.0 of the Windows Terminal Preview, but that your OS version is 22000.1. So perhaps you don't have my OS-side fixes yet but you do have the Terminal Preview where I updated the interface. So it could just be the interface version mismatch tripping you up now, where the bugs I fixed were tripping you up before.

claunia commented

@miniksa commented on GitHub (Jul 20, 2021):

@DHowett informs me that my debugger "OS version" command might not be showing your full Windows 11 edition. Either way. The OS side conhost.exe will help me.

@miniksa commented on GitHub (Jul 20, 2021): @DHowett informs me that my debugger "OS version" command might not be showing your full Windows 11 edition. Either way. The OS side `conhost.exe` will help me.

claunia commented

@ianjoneill commented on GitHub (Jul 21, 2021):

I've sent you an email with a OneDrive link - I got the conhost process and the parent cmd process for good measure.

On the version number side, either the dump file or WinDbg is doing some misleading - as per the screenshot below.

@ianjoneill commented on GitHub (Jul 21, 2021): I've sent you an email with a OneDrive link - I got the conhost process and the parent cmd process for good measure. On the version number side, either the dump file or WinDbg is doing some misleading - as per the screenshot below. ![ver](https://user-images.githubusercontent.com/5821575/126440428-64dd73ed-e0be-4cc2-9e26-bb5a07d4b8a0.png)

claunia commented

@miniksa commented on GitHub (Jul 21, 2021):

Thanks. I found the issue. It was a race. I accidentally passed a stack variable as a parameter to another thread starting. If that thread started quickly enough, it would do the correct thing. If it didn’t win the race, the stack variable went out of scope and it would do strange things depending on how it was overwritten by the time it got around to it.

@miniksa commented on GitHub (Jul 21, 2021): Thanks. I found the issue. It was a race. I accidentally passed a stack variable as a parameter to another thread starting. If that thread started quickly enough, it would do the correct thing. If it didn’t win the race, the stack variable went out of scope and it would do strange things depending on how it was overwritten by the time it got around to it.

claunia commented

2bd5791feb/src/host/exe/CConsoleHandoff.cpp (L48-L67)

@miniksa commented on GitHub (Jul 21, 2021):

This function receives the connection message over COM from the inbox conhost.exe and queues it up for processing as the initial message by the console IO thread when it starts.

91b454ac95/src/host/srvinit.cpp (L862-L889)

This function runs on another freshly created thread consuming that message. Unfortunately I passed it as an LPVOID and cast it back. So it's a pointer to the other memory space... or unfortunately the stack space of the other thread. Oops.

I will move this initial message to a persistent location or heap memory before I pass it and it should resolve the issue.

@miniksa commented on GitHub (Jul 21, 2021): https://github.com/microsoft/terminal/blob/2bd5791feba6fb29d16d6c14b6d43f8c2bfa4f9f/src/host/exe/CConsoleHandoff.cpp#L48-L67 This function receives the connection message over COM from the inbox `conhost.exe` and queues it up for processing as the initial message by the console IO thread when it starts. https://github.com/microsoft/terminal/blob/91b454ac95b4f8404f2d7c2cb6b13f5c3205001d/src/host/srvinit.cpp#L862-L889 This function runs on another freshly created thread consuming that message. Unfortunately I passed it as an `LPVOID` and cast it back. So it's a pointer to the other memory space... or unfortunately the stack space of the other thread. Oops. I will move this initial message to a persistent location or heap memory before I pass it and it should resolve the issue.

claunia commented

@ianjoneill commented on GitHub (Jul 21, 2021):

I see - yes that certainly looks promising!

@ianjoneill commented on GitHub (Jul 21, 2021): I see - yes that certainly looks promising!

claunia commented

@ianjoneill commented on GitHub (Jul 21, 2021):

Also, thanks for the explanation - greatly appreciated 😄

@ianjoneill commented on GitHub (Jul 21, 2021): Also, thanks for the explanation - greatly appreciated 😄

claunia commented