vscode-python repeatedly launching wmic

[derekwbrown]

Environment data

• VS Code version: 1.21.1 x64
• Extension version (available under the Extensions sidebar): 2018.3.1
• OS and version: Win10
• Python version (& distribution if applicable, e.g. Anaconda): 2.7.13
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): NA

Actual behavior

When open to a python file, code with the Python extension enabled is continually launching
wmic processes. This in turn backs the wmiprvse.exe service up, to the point where very
quickly it's consuming 100% of the CPU (on one core).

Expected behavior

VSCode shouldnt' cause my CPU to be fully loaded when nothing's actually happening

Steps to reproduce:

Install VSCode
Install the python extension
Open a python file.
Watch in taskmgr/process explorer as wmic processes are created repeatedly.

Disable python extension
Watch as no further wmic processes are created, and processor returns to idle.

[brettcannon]

Can you try setting "python.jediMemoryLimit": -1 in your settings.json file?

[MikhailArkhipov]

It is checking Jedi process memory footprint. It can be turned off.

[DonJayamanne]

My suggestion is to take control of the use of wmic ourselves (not use the npm package for windows os). VS Code is also using wmic to monitor processes for debugging (in a polling manner).
I.e. if they can do it reliably, we too should be able to do this by taking control over things, rather than relying on this.

@brettcannon @MikhailArkhipov
I propose we get a revised solution in for the next version, else this CPU could potentially throw off new users from using VSC (or the extension).

[derekwbrown]

Making that change did resolve (or suppress) the problem. But I've found that hitting WMI frequently has the same adverse affect; if there's a way to do it outside of WMI it's probably a good thing.

[MikhailArkhipov]

@DonJayamanne - I wouldn't worry too much. I think we can change default memory control to off (or at least on Windows). In the new analysis engine we have internal control of the memory consumption so the setting won't be needed eventually.

[YipYipX4]

I was experiencing this issue as well, but the workaround posted above worked for me. I'm very interested to understand the root cause of this issue because it isn't the first time I've had these symptoms.

I'm not even a Python developer normally (I usually write TypeScript and C# code), but I had been given a Python script to decipher and I used VSCode mainly for the syntax highlighting and IntelliSense. I did install the vscode-python extension and later I noticed my CPU was pegged at 100%.

Unfortunately, I did not suspect VSCode (or the Python extension) at first because I have previously had issues with high-CPU usage in WmiPrvSE.exe with extremely similar symptoms. FYI, this is a corporate machine with a ton of monitoring software on it, so I have assumed that one of those monitoring or security processes is overusing the WMI functionality. One of the symptoms was McAfee anti-virus repeatedly being required to scan tzres.dll and tzres.dll.mui, hundreds of times a second. McAfee has posting about this issue below, but of course, they claim the root cause is always something other than their software (and the article below links to a Microsoft posting for troubleshooting WMI, which again says the root cause is not WMI but something using it).

High CPU usage by mcshield.exe, and wmiprvse.exe and mcshield.exe are repeatedly opening and closing tzres.dll and tzres.dll.mui
https://kc.mcafee.com/corporate/index?page=content&id=KB88026

The symptom above was definitely occurring in this case, and the workaround stopped it. However, I have had the same symptom even when VSCode was not running and something else was causing it (perhaps regular Visual Studio Professional or Chrome or one of those dozens of corporate bloatware processes that are always running).

Thus, I would appreciate any insights into the root cause. Thanks!

[brettcannon]

@YipYipX4 the problem is that we use a project called Jedi for our IntelliSense and some users have complained about massive memory usage. So we introduced a mechanism to monitor the memory and prevent it from getting too big. Unfortunately the mechanism has had some adverse effects as well, so we are trying to figure out how best to handle this.

[derekwbrown]

WMI just doesn't perform well if you use it frequently (as in poll every 5 seconds). You can get the same information from the performance counters library w/o incurring the wmi perf hit.