Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"Invalid standard handle identifier" since 3.0.0 update #9770

Closed
2 tasks done
mleguevel opened this issue Dec 11, 2020 · 14 comments
Closed
2 tasks done

"Invalid standard handle identifier" since 3.0.0 update #9770

mleguevel opened this issue Dec 11, 2020 · 14 comments
Labels
lifecycle/locked lifecycle/stale

Comments

@mleguevel
Copy link

mleguevel commented Dec 11, 2020 •
edited

Hello,

I upgraded to the version 3.0.0 today and since the upgrade, docker commands all end with an error.

  • I have tried with the latest version of my channel (Stable or Edge)
  • I have uploaded Diagnostics
  • Diagnostics ID: F280684A-3B48-49F9-B15D-2F448E4187FD/20201211104027

Expected behavior

Being able to use the docker command on windows without having an error

Actual behavior

Any command on windows ends up with the following error:

panic: Invalid standard handle identifier: 4294967286

goroutine 1 [running]:
github.com/docker/cli/vendor/github.com/Azure/go-ansiterm/winterm.GetStdFile(0xfffffff6, 0xc0000547f8, 0x2b0)
        /go/src/github.com/docker/cli/vendor/github.com/Azure/go-ansiterm/winterm/ansi.go:173 +0x1f3
github.com/docker/cli/vendor/github.com/moby/term/windows.NewAnsiReader(0xfffffff6, 0xc00000000f, 0x20d46c0)
        /go/src/github.com/docker/cli/vendor/github.com/moby/term/windows/ansi_reader.go:34 +0x36
github.com/docker/cli/vendor/github.com/moby/term.StdStreams(0xc0003d3790, 0xc0004c3eb8, 0x1, 0x1, 0x0, 0x0)
        /go/src/github.com/docker/cli/vendor/github.com/moby/term/term_windows.go:75 +0x1eb
github.com/docker/cli/cli/command.NewDockerCli(0x0, 0x0, 0x0, 0x19b926c, 0x1b4f0a0, 0xc00020de90)
        /go/src/github.com/docker/cli/cli/command/cli.go:473 +0x1a7
main.main()
        /go/src/github.com/docker/cli/cmd/docker/docker.go:291 +0x4b

Information

I've tested it with docker run, docker exec and docker logs. Actually, just running the docker command alone gives the same result. I tried running the commands from mobaxterm, windows cmd and powershell and I have the same error on each of those.

I tried reinstalling docker desktop and running the last two options in the "Troubleshooting" menu (Clean / Purge data and Reset to factory defaults) with no luck.

Running services from docker-compose works fine though.

I tried looking at the code but I'm not a go developer, so take it with a grain of salt:

From the stack trace, it seems that syscall.STD_INPUT_HANDLE is compared to windows.STD_INPUT_HANDLE and that they do not have the same value? From the go documentation, windows.STD_INPUT_HANDLE seems to be -10 & (1<<32 - 1) = 4294967286 which matches the handle identifier that's displayed in the error message.

  • Windows Version: Windows 10 1809 17763.1577
  • Docker Desktop Version: 3.0.0
  • Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: no

Steps to reproduce the behavior

I have no idea because it might be related to my windows installation. But on my machine, reproducing it consists in running any docker command.
@stephen-turner
Copy link
Contributor

Hmmm, that's very odd. It sounds like the sort of bug that would be widespread, but we haven't had any other reports. I'm going to ask the team that writes the CLI (which is just an upstream to us) if they have any ideas.

@iamrearwindow
Copy link

Same deal for me. Docker desktop upgraded to 3.0.0 on Windows 10 on 11-dec.
All CLI docker commands return - panic: Invalid standard handle identifier: 4294967286.

@ScotHillier
Copy link

I have the same problem.
panic: Invalid standard handle identifier: 4294967286

@ScotHillier
Copy link

I have it working, but I have no idea what the magic was. Here's what I did:

  1. Upgraded Visual Studio 2019 to the latest version

  2. Disabled the legacy console because I got an error when trying to reset to factory settings
    Open cmd.exe.
    Right click title bar -> Properties -> Uncheck Use legacy console.
    Click OK.

  3. Reset to factory Settings

@anishjain94
Copy link

This worked for me.
Disabled the legacy console because I got an error when trying to reset to factory settings
Open cmd.exe.
Right click title bar -> Properties -> Uncheck Use legacy console.
Click OK.

@saiyamarlon
Copy link

thank you, for the data

@mleguevel
Copy link
Author

This worked for me.
Disabled the legacy console because I got an error when trying to reset to factory settings
Open cmd.exe.
Right click title bar -> Properties -> Uncheck Use legacy console.
Click OK.

Yep, it does the trick for me as well. Thanks @ScotHillier

@stephen-turner I don't know if you want to keep this issue open?

@stephen-turner
Copy link
Contributor

stephen-turner commented Dec 15, 2020 •
edited

Good detection work, @ScotHillier, thank you. It's easy to reproduce by switching to legacy console (either cmd.exe or PowerShell).

I'll leave this ticket open for the moment and discuss with the CLI team whether it's fixable.

@tiborvass tiborvass mentioned this issue Dec 18, 2020
Merged
@stephen-turner stephen-turner mentioned this issue Dec 18, 2020
Closed
@stephen-turner
Copy link
Contributor

Good news, the CLI team have found the cause and believe they can fix it.

(I don't have a date yet: with the holiday season there probably won't be another release this year, so in the mean time please continue to use the workaround of turning off legacy mode in the console).

@stephen-turner stephen-turner mentioned this issue Jan 19, 2021
Closed
5 tasks
@smarie smarie mentioned this issue Jan 19, 2021
Closed
@kaosagnt kaosagnt mentioned this issue Feb 4, 2021
Closed
@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@FabianKramm FabianKramm mentioned this issue Apr 7, 2021
Closed
@TomTurkington
Copy link

I'm having this problem and though switching to non-Legacy works, it is not an option as that causes other problems. I see where stephen-turner indicates they i.d.'d the problem and were working on a fix but no update since then, and then the 'robot' decided this should be closed. It would be really nice if there was some way to mark this thread 'in progress' if indeed they are working on a fix so that the 'robot' doesn't close it until it is truly fixed. I just upgraded docker to latest/greatest and still am having the same problem.

@d-sphinx
Copy link

Still not fixed?

@TomTurkington
Copy link

TomTurkington commented Apr 30, 2021 via email

@jkabat jkabat mentioned this issue May 28, 2021
Closed
@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators May 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
lifecycle/locked lifecycle/stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@d-sphinx @mleguevel @stephen-turner @ScotHillier @anishjain94 @docker-robott @saiyamarlon @iamrearwindow @TomTurkington