Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: http://code.visualstudio.com/Download#insiders

It crashed again. This time it happened almost instantly.

I'm not sure if this helps but there were two terminals open, one running npm start and the other one was running sass in_folder:out_folder --watch.

@avsinacio

Leave VS Code open for a while

For how long?

The timing wasn't uniform.
The only pattern that I noticed was that it never exceeded an hour before crashing.

I wonder if this issue is being caused by an installed extension. Can you try to run VS Code without extensions? From the command line (NOT the integrated terminal in Code), execute: code --disable-extensions and try your steps again to see if it reproduces. If you see it is an issue with the extension, please file it against the extension repository itself.

I tried that but the problem still persists.
This time it happened too when I clicked on the twitter feedback button.

I'm trying to use the git bash terminal for the npm and sass instead of using the integrated terminal in Code. Apparently, when I don't use the integrated terminal it doesn't happen.

Adding @Tyriar

I believe this is a duplicate of #34039 which is fixed in 1.16.1 (and Insiders). Did you try on the latest Insiders build? It wasn't clear from your comment.

Looks like the crash is caused by windows-process-tree. I have a guess as to what causes it; computers having more than 1024 causing an access violation as the process info is collected into a ProcessInfo[1024].

Upstream issue: microsoft/vscode-windows-process-tree#9

Reliable repro is to just keep creating new powershell sessions, my PC crashes at around 40.

The issue is fixed in windows-process-tree@0.1.6 e6874a3

There were two potential crashes fixed:

• The major crash was caused by calling CreateToolhelp32Snapshot too much, causing an access violation. The fix for this was to prevent the windows-process-tree library ever entering the native code for more than 1 request at a time. microsoft/vscode-windows-process-tree@d02c7cd
• A lesser crash that will likely rarely happen; when there are more than 1024 processes running there would be accesses beyond the size of the array. This was fixed by stopping and returning the 1024 if there are so many processes microsoft/vscode-windows-process-tree@592c945

Happening again after update to Code x32 1.16.1, terminal is crashing the code again, on Win 7 SP1 Enterprize x64, while running any longer script but mostly on grunt build or grunt run. Our stack is npm (6.11.x) + grunt + angular 4 app.

Also mostly by having 2 terminals in the same time, but not only then.

Because we love Code so much and all the effort put in it, we want to greet the VS Code Team, and help by spreading good word about the Code, it is (including MS Visual Studio and TypeScript) one of the best products MS ever made :) Keep up the good work and thank you all.

Same behavior here, tested with a load of CLI , sometimes it crashes instantly, sometimes it doesn't with the exact same CLI.

Version 1.16.1
Shell 1.7.3
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

I'm testing the 1.16.1 since early this morning. So far, so good.
Sorry for taking too long to respond, I was hospitalised since thursday.

Crashing started for me a couple of days ago, on 1.16.0 . Also while running terminals.
I've updated to 1.16.1 but it has not resolved the issue.

Just to clarify the situation if this can help, the crash of Code happens only while using multiple terminals (more than 1), the update 1.16.1 didn't change this behavior at all. So while using single terminal everything works fine.

Hope it helps, greetings to Code Team.

This never ended up making it into a 1.16.2 as I've been out. Unfortunately you will need to wait until 1.17.0 for the fix.

There seems to be a few of these crashes reported against 1.17.0-insiders still but these are likely people not updating. There was a steep decline around the time that I made the fix 👍

I also get this issue intermittently when I do npm run webpack from an integrated terminal with npm run start in another integrated terminal. Where webpack runs webpack -w and start runs nodemon

All I do is save a file, the file watcher (-w) picks up the change and vscode crashes as webpack tries to do its thing.

Also, annoyingly, the node.exe processes that were started in the terminal (by way of npm) continue to run even after code.exe has crashed, and there's no way to get back to the terminal to ctrl-c it and I have to kill the node process from task manager. I would expect that process started in the integrated terminal would be part of a job that would be terminated when vscode exits. (But it appears that the process breaks away, since it didn't terminate along with code.exe)

(Windows 10 x64)

> code --version
1.16.1
27492b6bf3acb0775d82d2f87b25a93490673c6d

> npm --version
4.2.0

> node --version
v7.10.0

webpack ^3.6.0

@wyckster the process leak issue is tracked in #26807

Its Working Now 👍 !!

Thank you @Tyriar and complete VS Code Team, this is now fixed in 1.17 and VS Code is working excellent on Win platform :)

We want just to help you so you can close all other bugs related to this, terminal is not crashing anymore, and is much faster.

Keep up the good work and thank you on this software (VS Studio meets Sublime)

@pozzito awesome, great to hear! 😃

Hi, not sure if this is related, so I haven't opened a new bug yet, but I'm encountering a full system freeze on Windows 10 after I wake my computer in the morning and click on VS Code. VS Code was already open, I was just switching to it by clicking on the Taskbar icon.

I've been encountering full system freezes on my work machine for several months now. I've gone through 4 machines at work trying to figure out what the problem is, but after the release of 1.17.x, it seems clearer that VS Code appears to be the culprit. This has happened to me two days in a row now (ever since I upgraded to 1.17.2).

I've noticed that I get a Perflib error (event ID: 1008) in the Windows Event Viewer right before the freeze happens.

The Open Procedure for service "WmiApRpl" in DLL "C:\WINDOWS\system32\wbem\wmiaprpl.dll" failed. 
Performance data for this service will not be available. 
The first four bytes (DWORD) of the Data section contains the error code.

There's also a PerfNet error (event ID: 2004) right before the Perflib error.

Unable to open the Server service performance object. 
The first four bytes (DWORD) of the Data section contains the status code.

Please disregard my previous comment. I've asked the same question in #35590 instead