Vscode: Python throws IOError in some scripts in Windows Integrated Terminal

[jacek-dargiel]

Running docker-compose commands fails when running from the integrated powershell terminal. Running same commands in the standalone powershell terminal works fine. Here's the failing message:

> docker-compose -f .\docker-compose.dev.yml pull

Pulling redis (redis:latest)...
latest: Pulling from library/redis
d13d02fa248d: Downloading [===>                                               ]  1.867MB/30.11MB
a1846f364e39: Download complete
dba901efed8c: Download complete
Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 653, in pull
  File "compose\project.py", line 512, in pull
  File "compose\service.py", line 1031, in pull
  File "compose\progress_stream.py", line 44, in stream_output
  File "compose\progress_stream.py", line 63, in print_output_event
  File "codecs.py", line 370, in write
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
IOError: [Errno 0] Error
Failed to execute script docker-compose

This looks like another instance of this issue - that one was reported to the docker repo, but the reporter does note that this only happens in the VS Code integrated terminal.

Also, please note, that I didn't have this problem up until today when I've installed the Fall Creators Update to Windows.

---

• VSCode Version: Code 1.17.2 (b813d12980308015bcd2b3a2f6efa5c810c33ba5, 2017-10-16T13:59:46.104Z)
• OS Version: Windows_NT x64 10.0.16299
• Extensions:

Extension|Author (truncated)|Version
---|---|---
ng-template|Ang|0.1.7
htmltagwrap|bra|0.0.3
jshint|dba|0.10.15
vscode-eslint|dba|1.3.2
EditorConfig|Edi|0.11.0
js-is-jsx|eg2|0.0.1
tslint|eg2|1.0.11
vscode-guid|hea|1.2.0
path-autocomplete|ion|1.6.1
vscode-github|Kni|0.22.0
graphql-for-vscode|kum|1.6.2
Angular-BeastCode|Mik|5.0.8
HTMLHint|mka|0.4.0
azure-account|ms-|0.1.3
debugger-for-chrome|msj|3.4.0
angular2-inline|nat|0.0.17
createGUID|nwa|0.0.2
vscode-docker|Pet|0.0.20
ejs-language-support|Qas|0.0.1
vscode-icons|rob|7.15.0
stylelint|shi|0.30.0
Align|ste|0.2.0
jsx-snippets|Twe|0.0.1
gitblame|wad|2.2.0
twig|wha|1.0.2
jinja|who|0.0.8
change-case|wma|1.0.0

(3 theme extensions excluded)

---

Steps to Reproduce:

1. 
   2.

Reproduces without extensions: Yes/No

[Tyriar]

@jacek-dargiel are you using a python virtual environment?

[jacek-dargiel]

Not sure. How can I check? I do have python 2.7 installed locally.

[Ahryman40k]

Hi.
It seems I have the same issue with docker and vscode since I installed fall creator 2 days ago.
In my case I have python 2.7 installed and python extensions in vscode.

[TheWozMSN]

Docker --version and Docker-Machine --version works as expected. Only Docker-Compose --version is failing in my preliminary test. Hope this helps

[Tyriar]

@jacek-dargiel you would probably know if you were using it 🙂

@Ahryman40k @TheWozMSN are you both on Windows?

[TheWozMSN]

I am on the current insider build of windows 10.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Daniel Imms [e-mail]
Sent: Thursday, October 26, 2017 12:07:53 AM
To: Microsoft/vscode
Cc: Doug Woznicki; Mention
Subject: Re: [Microsoft/vscode] docker-compose fails when running from the integrated PS terminal (#36630)

@jacek-dargielhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjacek-dargiel&data=02%7C01%7Cdwoznicki%40msn.com%7Cfbf899d125bc4930ae0e08d51c27221b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636445876749203371&sdata=MAyv2X%2FBk5q5T0erDeFwwXjqRrSFU%2B%2FY2TSeGEJSmuk%3D&reserved=0 you would probably know if you were using it 🙂

@Ahryman40khttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fahryman40k&data=02%7C01%7Cdwoznicki%40msn.com%7Cfbf899d125bc4930ae0e08d51c27221b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636445876749359635&sdata=zf8O3bbeE3OyjplO%2FlZ8BVeHH%2BK3awU2bgzfGlb0pSk%3D&reserved=0 @TheWozMSNhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fthewozmsn&data=02%7C01%7Cdwoznicki%40msn.com%7Cfbf899d125bc4930ae0e08d51c27221b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636445876749359635&sdata=svVHI02VrcQ2VxrXfQWD4bp4pMFwZKhN23O78xtEkUw%3D&reserved=0 are you both on Windows?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode%2Fissues%2F36630%23issuecomment-339545452&data=02%7C01%7Cdwoznicki%40msn.com%7Cfbf899d125bc4930ae0e08d51c27221b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636445876749359635&sdata=sx%2Fg6n%2FCp7F6f7NYsSINl0eRDKsPC%2FR1s1IA0H3Q9mc%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMtuAfJkl_YyK1xKTN0I00uy3k1wcKJLks5swAWZgaJpZM4QAhER&data=02%7C01%7Cdwoznicki%40msn.com%7Cfbf899d125bc4930ae0e08d51c27221b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636445876749359635&sdata=13ab1kK5SNda7BjIZJdho7tgng2tC5hlD8VvsMACn%2Bk%3D&reserved=0.

[Ahryman40k]

@Tyriar
I'm using Windows 10 Pro.

[jrock2004]

@Tyriar do I need to install python for docker compose to work in vscode? I got a brand new windows 10 installed running 1709 and I have the same issue

[TheWozMSN]

Further Comment. Docker-Compose works in a regular powershell command window. Not with Integrated Powershell

[stwessl]

Think this might need to be taken up in the docker compose repo. If it is
not already

On Fri, 27 Oct 2017, 13:15 Doug Woznicki, [e-mail] wrote:

Further Comment. Docker-Compose works in a regular powershell command
window. Not with Integrated Powershell

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/36630#issuecomment-339943863,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABy95AVdqTJHAlAKzcX-5n9ez0L33g_4ks5swbtggaJpZM4QAhER
.

[Tyriar]

Could anyone look at the bottom of the stacktrace and find out what is making it fail?

File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text

It might be something to do with the env?

[Silic0nS0ldier]

Just hit this issue myself.

PS D:\jorda\Desktop\UF4.0> docker-compose up
Pulling mysql (mysql:5.7)...
5.7: Pulling from library/mysql
85b1f47fba49: Pulling fs layer
27dc53f13a11: Pulling fs layer
095c8ae4182d: Pulling fs layer
0972f6b9a7de: Waiting
Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 938, in up
  File "compose\project.py", line 430, in up
  File "compose\service.py", line 311, in ensure_image_exists
  File "compose\service.py", line 1031, in pull
  File "compose\progress_stream.py", line 44, in stream_output
  File "compose\progress_stream.py", line 63, in print_output_event
  File "codecs.py", line 370, in write
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
IOError: [Errno 0] Error
Failed to execute script docker-compose

Last time I used this command was 3 months ago, and it had worked then. Most notable changes are updating to Fall Creators Update (non-Insider), several updates to docker, and several VS Code updates. Everything was up to date the last time it worked, and everything is up to date now.

Like the OP, regular PS window works fine.

Taking a look at the stack trace, it seems the error propagates from Colorama, a Python terminal colouring library. I'm terrible at Python, so I can't see any obvious reasons for it to be the cause.

I've spotted the issue at:

• StackOverflow, with VS Code used
• Colorama GitHub repo, with command prompt used

Looks like this is a bug in Colorama triggered by unknown circumstances.

[capripio]

+1 same issue occured!

[zeus]

+1 same issue

[huzhuo]

+1 same issue

[vitfgarcia]

+1 same issue

[stefda]

+1 same issue here on Fall Creators Update

I can confirm that reverting back to a Windows build prior to Fall Creators Update fixes the issue.

[Tyriar]

@miniksa @bitcrazed might be an issue with FCU?

[alexsandro-xpt]

+1 same issue here on Fall Creators Update and:

VSCode

Version 1.17.2
Commit b813d12980308015bcd2b3a2f6efa5c810c33ba5
Date 2017-10-16T13:59:46.104Z
Shell 1.7.7
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

[AustinWinstanley]

Confirmed. This started with Fall Creators Update which I got yesterday and now this is occurring. Can also confirm it works in PowerShell standalone.

Windows 10 Pro
Version 1709
Build 16299.19

[TheWozMSN]

I have a 1607 (10.0.14393 Build 14393) Windows 10 and an Insider Fast Current windows 10. Both with same error. I don't have any Python installed.

[Tobse]

+1 same issue here on Fall Creators Update BUT I am using the integrated terminal of PhpStorm. So it seems not to depend on VSCode.

[wilomgfx]

+1 same issue here on Fall Creators update too. Dont have python installed on my host too.

[miniksa]

Filed as MSFT:14643897. I'll get to it.

[wilomgfx]

@miniksa awesome thanks!

[atrauzzi]

Related? https://github.com/docker/compose/issues/2775

Is there any kind of workaround we can do right now?

[ghost]

+1 same issue here. Happens after fall creators update

[miniksa]

Please do not +1 for the sake of it without anything new that could contribute to the investigation. Please add yourself for notifications when the thread moves and react to other people's comments. Bumping this in my inbox on a Friday morning with nothing useful is a recipe for making me furious before my morning coffee kicks in.

If you have debugged something that could help me figure it out or you can identify the exact build number where this first occurred, that's useful.

Otherwise, please be patient and let me get around to investigating this bug. Thank you for your understanding.

[bitcrazed]

All: Please note that GitHub has added a reaction icon in the top left of each post:

If you want to share that you're impacted by the OP or a post within the thread, please thumbs-up appropriately.

If you don't want to do it for @miniksa, please do it for me - you don't have to work with him when he's all grouchy. SRSLY!!

[helto4real]

I got this error upgrading to latest insider

Also use fall creators update. It worked yesterday with the version of visual studio code before this one.

UPDATE!
It works when using version 2 in the compose files (yml) from 3

[bitcrazed]

@helto4real Please file this as a separate issue since this is not related to docker-compose failing

[Tetraib]

I believe it also fails in regular powershell but more silently. It fails but only shows up after you kill the hanging process.

[bitcrazed]

@Tetraib What happens if you run chcp 65001 first?

[frimik]

@bitcrazed I tried chcp 65001, still happens.

docker-compose -f docker-compose.yml up -d --build
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 1027
1.9: Pulling from library/golang
3889bb8d808b: Downloading [===>                                               ]  254.9MB/4.07GB
eTraceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 952, in up
  File "compose\project.py", line 431, in up
  File "compose\service.py", line 312, in ensure_image_exists
  File "compose\service.py", line 1036, in pull
  File "compose\progress_stream.py", line 44, in stream_output
  File "compose\progress_stream.py", line 72, in print_output_event
  File "codecs.py", line 370, in write
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
IOError: [Errno 0] Error
Failed to execute script docker-compose

[Tetraib]

@bitcrazed what seems to make it works in powershell but not in vs code is to

1. Execute chcp in cmd which returned 850 in my case
2. Execute chcp 850 in powershell

chcp 65001 does not seems to solve the problem
So for now I stoped using the integrated terminal in vs code and use the native powershell to run docker-compose.

It is sometimes hard to pickup the bug. Sometimes random, sometimes keeps failing in a row.

[shawinder]

same issue with latest VS Code (1.18.1)

Windows 10 Pro
Version 1709
OS Build 16299.19

[lazyc97]

I get the same problem on hyper terminal so I suspect this bug has something to do with Electron. For now, the workaround for me is using --no-color flag.

[pekkaklarck]

Robot Framework users are encountering same/similar IOError: [Errno 0] Error issue (see robotframework/robotframework#2709). After seeing a StackOverflow question with same error, I thought that the problem could be caused by several processes writing and reading to (possibly) redirected stdout. I thought adding seek(0, 2) before writing to stdout as proposed by the accepted answer to the aforementioned questions would help, but first reports from users aren't very positive. I personally cannot reproduce the problem as I run Linux and only have Windows 7 in a virtual machine.

After browsing through comments to this issue, I started to think could the problem be related to console colors instead. We don't use colorama, but the error occurs in our custom console coloring code which most likely uses same Windows APIs as colorama. Could there have been changes to them in the latest Windows 10 versions?

[tmsns]

Hey @pekkaklarck,

There were changes in the console. People are mentioning this is happening since fall creators, and lo and behold: https://blogs.msdn.microsoft.com/commandline/2017/08/02/updating-the-windows-console-colors/

Might be related.

[bitcrazed]

Thanks for the info @all - we've field a bug & will be exploring this issue

[miniksa]

Can someone please provide repro steps here from a clean Windows box? I'm unfamiliar with VSCode, Docker, Docker Compose, or anything having to do with web development.

I followed the Getting Started with Docker Compose guide this morning here: https://docs.docker.com/compose/gettingstarted/#step-4-build-and-run-your-app-with-compose and installed https://docs.docker.com/docker-for-windows/install/ which included Compose, apparently.

I ran the "docker-compose up" command and seem to have no problems in either Powershell or the integrated terminal inside VSCode.

Please give me step-by-steps as if I am a web development idiot (which I am) so I can get this reproing and attach a debugger to the console subsystem and see what's up.

PS C:\foo\composetest> docker version
Client:
Version: 17.09.0-ce
API version: 1.32
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:40:09 2017
OS/Arch: windows/amd64

Server:
Version: 17.09.0-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:45:38 2017
OS/Arch: linux/amd64
Experimental: true

Visual Studio Code:

Windows Version: Build 17046.rs_onecore_dep_aci.171120-1700 en-US x64 Enterprise

[miniksa]

Well, fiddling around with it enough, I got it to happen. But I can't figure out which specific call it is failing on. I have no Python-fu so I don't know how to tell what call it is making and failing.

I'm going to keep flailing around here, but one of y'all web devs is going to have to likely step up to help this poor, ignorant systems programmer.

[akittas]

Same issue here, but when trying to use the terminal from PyCharm (cmd/git bash/powershe;ll).
Regular powershell/git bash terminal works fine

[shawinder]

@miniksa Try attached zip.
docker-compose-error.zip

Fyi. Compose works fine for simple configuration but fails when there are multiple containers, volumes.

OS : latest windows 10 Pro - Build 16299.98
Docker : latest windows CE

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: true

VSCode : latest

[miniksa]

That failed the first run, @shawinder, but then I ran it again and it was fine.

[miniksa]

You know, this might be some sort of race between tartley/colorama decoding VT into Win32 calls and rprichard/winpty in its scraping loop to re-encode Win32 calls back to VT under VSCode. When I do get it to repro in VSCode, it's very flaky as if it is a race condition.

I'll keep looking around a bit, but being unable to have a reliable repro or understanding what parameters the colorama python module is actually trying to send and to which Win32 API is hindering my investigation.

[pekkaklarck]

You can see how colorama interacts with WIn32 API via ctypes here: https://github.com/tartley/colorama/blob/master/colorama/win32.py

[shawinder]

@miniksa I tried running it multiple times and got the same error. Not sure how it works for you second time.

Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 938, in up
  File "compose\project.py", line 417, in up
  File "compose\project.py", line 646, in warn_for_swarm_mode
  File "site-packages\docker\api\daemon.py", line 90, in info
  File "site-packages\docker\utils\decorators.py", line 46, in inner
  File "site-packages\docker\api\client.py", line 189, in _get
  File "site-packages\requests\sessions.py", line 488, in get
  File "site-packages\requests\sessions.py", line 475, in request
  File "site-packages\requests\sessions.py", line 596, in send
  File "site-packages\requests\adapters.py", line 423, in send
  File "site-packages\requests\packages\urllib3\connectionpool.py", line 595, in urlopen
  File "site-packages\requests\packages\urllib3\connectionpool.py", line 363, in _make_request
  File "httplib.py", line 1042, in request
  File "httplib.py", line 1082, in _send_request
  File "httplib.py", line 1038, in endheaders
  File "httplib.py", line 882, in _send_output
  File "httplib.py", line 844, in send
  File "site-packages\docker\transport\npipeconn.py", line 31, in connect
  File "site-packages\docker\transport\npipesocket.py", line 22, in wrapped
  File "site-packages\docker\transport\npipesocket.py", line 50, in connect
pywintypes.error: (2, 'WaitNamedPipe', 'The system cannot find the file specified.')
Failed to execute script docker-compose

[miniksa]

@shawinder, that stack is different from the rest of them that were listed. Not sure what's up there.

[lazyc97]

@shawinder I think you forgot to do docker-machine env | invoke-expression

[talamaska]

For me it's not happening in ordinary Powershell, it seems I have quite a number of warnings from the backend in that docker I'm trying to run. I don't see Powershell having issues to display them nor any errors from colorama. I do have quite list of dependable on each other tasks in tasks.json like so. I suspect that the task runner might have some issues actually, like was mentioned before some race condition. Because I see python errors and various steps of the build docker tasks. I ran those tasks one by one in PowerShell without errors.

{
      "taskName": "docker:build-api-code",
      "type": "shell",
      "command": "docker-compose -f ../../build-pipeline/docker-compose.ci.publish.yml up ci-publish-api"
    },
    {
      "taskName": "docker:build-api-container",
      "type": "shell",
      "command": "docker-compose -f ../../build-pipeline/docker-compose.yml -f ../../build-pipeline/docker-compose.override.yml build financialwellness.api",
      "dependsOn": "docker:build-api-code"
    },
    {
      "taskName": "docker:run-api",
      "identifier": "run-api",
      "type": "shell",
      "isBackground": true,
      "command": "docker-compose -f ../../build-pipeline/docker-compose.yml -f ../../build-pipeline/docker-compose.override.yml up financialwellness.api",
      "dependsOn": "docker:build-api-container"
    },

[miniksa]

I figured out the root cause this morning and I'm trying to devise a solution now.

It is a regression we caused in WriteConsoleA (https://docs.microsoft.com/en-us/windows/console/writeconsole), but the regression shows up only when someone is attempting to block the console output by generating a selection rectangle on the screen while a Python utility is outputting text. In more detail, it only happens when WriteConsoleA is being serviced off of what we call a "wait routine" when the console output stream is being blocked by a particular event. WriteConsoleW is not affected.

The issue seems to be that when we service WriteConsoleA off of a wait routine, we provide a "lpNumberOfCharsWritten" byte count of more bytes than were initially put in by the client application. That is, when Python writes out the letter "a" to WriteConsoleA, it says it is 1 byte big in nNumberOfCharsToWrite. If we service the request right away, we respond and say lpNumberOfCharsWritten=1. But due to a logical error in capturing the information for later servicing with our wait routines, if it is serviced later off a wait routine, we will respond and say lpNumberOfCharsWritten=2. It appears something in the Python Runtime or a library it is leveraging to output text from behind Python streams is comparing the bytes given to the number we said were written and is throwing the Traceback when they mismatch.

You don't see it outside of VSCode much because I doubt any of you are clicking on your screen to generate a selection rectangle while docker-compose is outputting text to a standard CMD or Powershell session. If you did, you would almost certainly see the same Traceback as soon as you hit escape or otherwise cancelled the selection.

You don't necessarily see it with other applications much because most applications we see do one of the following:

1. Use WriteConsoleW to emit UTF-16 encoded text into the Windows console. The W version is not afflicted by this bug.
2. Use WriteConsoleA to emit codepage-encoded text into the Windows console but ignore the return codes and the feedback values like lpNumberOfCharsWritten.

You see it inside VSCode all the time because winpty-agent.exe is extremely rapidly injecting a "select all" command into the underlying console window in a very tight loop in an attempt to block any output while it scrapes out the screen with ReadConsoleOutput (https://docs.microsoft.com/en-us/windows/console/readconsoleoutput) and then injects an "escape" to stop the selection and let output resume. I'm not sure why the winpty-agent.exe authors do this as ReadConsoleOutput will take a lock on the underlying screen buffer and the contents cannot change while it is reading, but I presume they have a good reason.

Also, a special callout to whomever in the pipeline is taking over the exception handlers for conhost.exe in this environment and killing everything whenever something goes wrong. That really made this one a peach to debug as I had to devise a workaround to get the console under a debugger without that getting in the way and killing the whole thing when an exception was generated.

I don't believe I need any more information to figure this one out. I'm staring down the code right now and trying to figure out the right way to return the correct byte count value off of a wait routine servicing a delayed WriteConsoleA call. I'll update the thread when I have a fix.

If there are any further questions as to the background or details, feel free to ask and I'll provide what I can for the curious. Thanks!

[miniksa]

I have committed a fix for this into our branch today. We are heading into the holiday season around here, so I wouldn't expect to see it in the outside world until Windows Insider builds early next year.

[Tyriar]

@miniksa great! I'll close this off since it's an upstream issue.

[shawinder]

While we wait for the fix to come in 2018, you can fix the problem by install git-scm terminal and overwrite default power-shell terminal using following setting in VSCODE -> Preferences -> Settings:

{
    "terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe"
}

[Silic0nS0ldier]

@shawinder Or not. Makes no difference on my end.

[mtpultz]

@Tyriar is there somewhere we can subscribe since likely everyone has changed their workflows to avoid this issue and won't remember to try this anymore (esp after holidays) since now with the issue closed there won't be any notifications regarding updates.

[divad4686]

@shawinder I tried that but still not working.

[Tyriar]

@miniksa I guess I'll leave this open, if you can please update here when the Windows update starts rolling out.

[rprichard]

You see it inside VSCode all the time because winpty-agent.exe is extremely rapidly injecting a "select all" command into the underlying console window in a very tight loop in an attempt to block any output while it scrapes out the screen with ReadConsoleOutput (https://docs.microsoft.com/en-us/windows/console/readconsoleoutput) and then injects an "escape" to stop the selection and let output resume. I'm not sure why the winpty-agent.exe authors do this as ReadConsoleOutput will take a lock on the underlying screen buffer and the contents cannot change while it is reading, but I presume they have a good reason.

ReadConsoleOutput is atomic, but that's not good enough.

In the common case, winpty reconstructs a stream of output corresponding to what's in the console buffer. To do this, it needs to do several things atomically:

1. Figure out how much the console has scrolled.
   
   
   
   • Use GetConsoleScreenBufferInfo to get the window position.
   
   
   • Use WriteConsoleOutputW to write a "sync marker" into the older area of the console buffer.
   
   
   • Use ReadConsoleOutputW to find the "sync marker". If it has moved since it was written, we know how many lines the buffer has scrolled.
   
   
2. Read the cursor position (GetConsoleScreenBufferInfo)
3. Finally, it read the console data proper, including (a) everything that's currently visible, but also (b) lines that were visible during the previous scraping (ReadConsoleOutputW).

The final scraping uses ReadConsoleOutputW, which prior to Windows 8, can only read about 64KiB of data at once. A large console window can be too big to read in a single call. (e.g. 250 * 100 * sizeof(CHAR_INFO) == 100000).

Using selection doesn't prevent an app from modifying the console buffer, but it does block WriteFile/WriteConsole, which is good enough for the kind of console programs that winpty is trying to work with.

If winpty instead worked more like screen and only showed the currently visible console window, then it could presumably avoid using selection, but it'd be an inferior UX. e.g.:

• It'd be unobvious how to view the scrollback. (a keybinding to move the console window?)
• No more than 9999(?) lines of scrollback. (Maybe the limit's actually 16K or 32K; I'm unsure.)
• When a program writes something, the console window snaps back to the bottom, making it hard to view the scrollback.
• Searching the scrollback would be difficult.

[rprichard]

It is a regression we caused in WriteConsoleA (https://docs.microsoft.com/en-us/windows/console/writeconsole), ...

@miniksa FWIW, when I was examining this issue, I saw that WriteFile was broken but not WriteConsoleA. https://github.com/Microsoft/console/issues/40

[miniksa]

@rprichard, both functions end up in pretty much the same area on our side. So the fix will apply to WriteFile as well.

[eryksun]

@miniksa, I reached a similar conclusion about the bug several days ago, but only for a WriteFile request that's blocked by an active text selection. For me, WriteConsoleA works correctly in this case. I assumed they'd be handled by the same code in the console host, but you say it's "pretty much the same area".

[vaustral]

This hit us hard the last 2 days, glad we found this, we're shifting our workflows elsewhere. VSCode was primary use. It fails every other time.

[FarmerSun]

+1 same issue
Windows 10
VSCode
docker-compose

[adoreleon]

Just a note...
In my case I found out that this error happen beacause i changed my user password...
So docker keep trying to share my folders with the old password

Just open the Docker For Windows, unckeck and check the folder and do a apply so docker ask for the password again

[damtur]

Is there any workaround for this until the fix is live? It's a huge blocker for me. Or at least some predictions when this will be available?

[miniksa]

I checked today and we're about 3 weeks from getting it to Windows Insiders builds. The integration train is just starting up again after the holidays.

[Tyriar]

@miniksa thanks for the update! 😃

[sutt]

The workaround is to write another print function, print2() which try/except print, then replace all your instances of 'print' with 'print2()' like here: https://github.com/sutt/exercises/commit/915db7f7789da14237d98517f711e8458c0d3e8e

For MS: this is rather troublesome bug because it kills the python debugging process before the line you want to investigate can be reached. That's why I'm doing such ugly stuff to get my code debuggable again.

[damtur]

@sutt yes but for my use case that would require docker team to do that in their software since the exception comes from using docker and docker-compose.

[rprichard]

The legacy console is probably a workaround for this issue, if you're able to use it. The legacy console doesn't work with WSL. Search for "Use legacy console (requires relaunch)".

[bitcrazed]

We understand the pain that issues like this casue, but recommend NOT employing legacy mode unless absolutely necessary: While it may allow very old command-line apps to continue to work, it'll cause untold issues in modern command-line apps.

The fix that @miniksa mentions above is bubbling up through our build system and should appear soon in an insider build. Please do upgrade to new builds as they're released, and let us know if the issue remains, or if its been fixed.

Many thanks to our community for all your support.

[inequity]

@bitcrazed Any idea how long it will take to bubble up to a Windows update for regular Win10 users? I'm not familiar with the update release cadence or Windows Insider Builds

[vaustral]

I'm kind of in the same spot, its' basically disabled docker functions for me. Any idea? I'm hesitant to get insider builds for work related functions.

[bitcrazed]

@inequity Regular Windows builds are shipped approx' every 6-months - around spring and fall. We just shipped Fall Creators Update in Sept 2017, so the next release should be around springtime 2018.

Thus, the fix above will arrive in the general Windows spring release. If you need it beforehand, you might want to sign-up for Insiders builds: Insiders builds are essentially snapshots of the next version of Windows as its being built. We aim to ship "Fast Ring" builds aprox' every week. "Slow Ring" builds approx. every 4-6 weeks.

[neilforrest]

I have been using the legacy console option mentioned by @rprichard for several days, and I can confirm that it does resolve the issue in my use case (which is running python scripts from tasks and from the integrated powershell terminal).

However as hinted at by @bitcrazed Bash for windows no longer works ("Unsupported console settings").

For my workflow, switching on/off the legacy console option as needed seems like the least bad solution.

Considering switching to insider builds, but I'm unsure of the stability.

[Silic0nS0ldier]

Had to fight some unrelated docker issues in the Windows Insider builds to test this, but it appears the fix gone out (observed on 17093).

Suggest people don't go jumping in right now though (unless they have a machine to treat as a guinea pig) due to those aforementioned issues. Linux containers were a no go for me (LCOW feature on the docker edge build withstanding).

[ozin7]

I had the same issue on Windows 10 Home, I was able to fix it using the Docker Toolbox terminal.

[atrauzzi]

That's not a "fix", just a workaround.

[ilude]

Still an issue with version: 1.20.1 of vscode on windows 10 with docker-compose 1.18.0 (screenshot below)

But on a positive note I may have discovered a

Possible Real Workaround/Solution

1. Run docker-compose version and note the output

2. Download the latest nightly build of the docker-compose binary from https://github.com/docker/compose/releases

3. Backup your existing docker-compose.exe file (or don't blame me when this possibly doesn't work and you want to go back :innocent: )
   Mine was located here: C:\Program Files\Docker\Docker\resources\bin

4. Copy the downloaded nightly file to the above path and rename it to docker-compose.exe

5. Run docker-compose version to confirm you're using the new binary

---

The version I'm using that's working so far:

docker-compose version 1.20.0dev, build 4ceeaad0
docker-py version: 3.1.0
CPython version: 3.6.4
OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017

---

Screenshot of failure with previous stable docker-compose 1.18.0:

docker-compose version 1.18.0, build 8dd22a96
docker-py version: 2.6.1
CPython version: 2.7.14
OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017

[jongio]

@bitcrazed , @chrisdias - Are you tracking this as a generic VS Code issue or is this one related only to docker? The reason I ask is because I'm seeing this with any colorizer. Shall I use this issue to track generic colorizer fails or should I open a new issue?

Also, do you have an ETA on this fix?

Thanks,
Jon

[copeland3300]

I don't think this is related to docker, as I'm not using it on my machine but I am getting the issue with the integrated terminal.

It doesn't seem to happen when I run a separate PowerShell window and run the python script. I should also mention I'm using Anaconda 5.1.0 for python 2.7.

When initially opening the integrated terminal, Code seems to be running the following line
& cmd /k "C:\Anaconda2\Scripts\activate.bat & PowerShell"

I should also note that this does not happen when running the file using debug. It runs correctly to the end.

[chrisdias]

@jonbgallant as I understand from @Tyriar this is a windows issue, not a VS Code, Docker, or VSCode Docker (extension) issue.

[Tyriar]

Yes it's a problem with Windows (see https://github.com/Microsoft/vscode/issues/36630#issuecomment-344030750, https://github.com/Microsoft/vscode/issues/36630#issuecomment-357084696). With a similar issue in the past I kept it open to make it easier for people to find the issue and not create a stream of duplicates for me to handle. We'll close this off when stable Windows starts getting the fix.

[jayshrivastava]

I was having a similar problem (post patch I assume v. 1.18.0 of Docker Compose), so I came here. In case anyone else has the same issue, I'll leave this for reference.

It was a longpaths issue for me due to Jenkins giving the project folder a unique code. I was able to complete my compose using powershell, but Jenkins gave my these errors:

Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 71, in main
  File "compose\cli\main.py", line 124, in perform_command
  File "compose\cli\main.py", line 959, in up
  File "compose\project.py", line 452, in up
  File "compose\service.py", line 308, in ensure_image_exists
  File "compose\service.py", line 967, in build
  File "site-packages\docker\api\build.py", line 150, in build
  File "site-packages\docker\utils\build.py", line 14, in tar
  File "site-packages\docker\utils\utils.py", line 100, in create_archive
  File "tarfile.py", line 1881, in gettarinfo
**WindowsError: [Error 3] The system cannot find the path specified:** u'C:\\Program Files 
(x86)\\Jenkins\\workspace\\repo-name-7F4KYNQD36XGPFD43T2E7OJE3M35TAB44IFL6IX324UGUB4NSC2A@2\\www\\administrator\\components\\com_jfilemanager\\assets\\files\\adsfdfadsf
adsfdasf\\asdfasfdasfdaf\\asdfasdfasf.JPG'

Basically, my copy of the www folder in my compose file failed because the path was too long. I had to enable long paths on the windows server I had docker and jenkins installed on.

  www:
        build: .
        ports:
            - "8001:80"
        volumes:
            **- ./www:/var/www/html/**
        links:
            - db
        networks:
            - default

All I had to do was follow this:
https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

[bapcyk]

I have the same problems but this is not related to:

• Windows (I run the same command in powershell.exe/cmd.exe out of Visual Studio Code many times and never get this error)
• long paths (path is short, less 32 chars)
• virtual env (I don't use virtual environment)
• docker (I don't use docker)

And this bug happens very often, for example, several times in a row

[ronaldgreeff]

I have the same error and all I'm doing is running python code with no modules (also no virtualenv)
If I sequentially "run python file in terminal", the error references random lines each time (line 15, line 25, line 34) and then works, then throws the error again.

Windows 10, Python 2.7.14

EDIT: I posted this comment before finding this - https://www.bountysource.com/issues/52206767-random-io-errors-on-windows-10-0-16299-64. Apparently it's a bug in Win 10.

[Wosi]

I was facing the same issues in November 2017 with the Fall Creators Update. I was able to delay this update until today. Now I'm unable to work with VSCode since all my compile and test scripts don't work anymore. I probably have to look for a different editor while this issue is open ;-(

I really beg you to fix this issue as soon as possible! I really don't want to abandon my beloved VSCode.

My original issue was this: https://github.com/Microsoft/vscode/issues/38068

[jongio]

I think it has something to do with print function - I was able to get around it by wrapping my print calls in a try block and then using print() in the except block, like this:

// Using python click

    def echo(self, text, color="", dim=False):
        try:
            click.secho(text, fg=color, dim=dim)
        except:
            print (text)

I've also had luck putting the futures print at the top of my python script:

from __future__ import print_function

[NicolasDorier]

Same issue here. Same command work in a separate powershell, not in the integrated terminal.

[raokrutarth]

The issue is still not resolved. Please take a look. Steps:
recursive function with printstatements. executes some of the statements and then randomly IOError: [Errno 0] Error

Version 1.21.1
Commit 79b44aa704ce542d8ca4a3cc44cfca566e7720f1
Date 2018-03-14T14:47:13.351Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture ia32

[Tyriar]

@raokrutarth it's an issue in Windows which takes a while to roll out.

[Wosi]

@Tyriar Is there a fix on the way? How can I get it earlier?

[Tyriar]

@Wosi it's fixed in the Windows Insiders channel https://github.com/Microsoft/vscode/issues/36630#issuecomment-359969098, you might not want to commit to that just to fix this though. It should be coming in the upcoming Spring release of Windows w

[Box-Of-Hats]

Appears to be fixed in the latest Windows 10 Spring Creators Update

[dllerena]

@Box-Of-Hats It was fixed on Windows 1803!! I installed it and tested it!! YAY!!!

[Tyriar]

🎉 Closing this off as people are confirming it's fixed! If you're experiencing this problem make sure you have installed the Windows 10 April Update (1803).