Repository: vscode
Issue: Repeated searches leaves orphaned, unkillable rg processes
Labels: bug,search

Type: <b>Bug</b>

On all modern versions I could test from 1.80 to 1.83-Insider, on Windows 11, VSCode searches launch rg.exe (ripgrep) processes in parallel with what seems to be a 1:1 mapping to the number of top-level folders in the workspace without pooling/parallel limits (at least none that I could see with up to ~50 folders).

With any number of folders however (including just 1) repeated searches will eventually leave one or more rg.exe processes hanging. 

When the workspace or VSCode is closed (or even the relevant folder removed from the workspace) this rg.exe becomes orphaned and is completely unkillable through any method I could find: not task manager, process explorer, pskill, taskkill, or wmic. Attempting to takeown and icacls the workspace also has no effect, nor killing every other non-core process in Windows, they're uniquely untouchable and only a reboot evicts them. 

Needless to say, this isn't ideal, and also mucks up any update process.

With a large enough workspace (but nothing over the top, a couple of dozen folders representing different repos) it's fairly easy to trigger this even just by typing with a cadence of ~0.5s per keystoke, which seems to be enough time for the automatic search to kick in, but not enough time for it to complete, which seems to be the most reliable reproducer (and perhaps only method of reproducing).  

The greater the folders/size/search result set, the easier it seems to be to achieve this state, but if you're aggressively searching, even one single large folder experiences this with typing `egg<Enter>g<Enter>g<Enter>...` quickly enough.

I've tried this with standalone installs from the VSCode site and Scoop, both regular and insider releases.

May also be related to other issues like #192454 but they've not been closed with any resolution and report wasn't detailed enough to confirm.

### How it manifests in process explorer

When they first hang, they appear like this as child processes

![image](https://github.com/microsoft/vscode/assets/10800163/980e0557-9575-4fde-b4e4-362e82d56419)

and when the parent processes are eventually killed, they hang around orphaned like this

![image](https://github.com/microsoft/vscode/assets/10800163/ccd618b6-cae1-4720-8e94-a8692b284c17)

I don't know what feature makes these orphans so invincible, there's one Deny flag I can see but a quick scan of other processes shows this isn't unique.

![image](https://github.com/microsoft/vscode/assets/10800163/91caf30f-d2a5-4d27-9cf4-c787fce41114)

## System details

VS Code version: Code - Insiders 1.83.0-insider (c72447e8d8aaa7497c9a4bd68bc4301584b92beb, 2023-09-22T09:29:47.641Z)
OS version: Windows_NT x64 10.0.22621
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|AMD Ryzen 9 5900X 12-Core Processor             (24 x 3693)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|63.91GB (39.23GB free)|
|Process Argv|--crash-reporter-id 3b777b0c-6c5f-41e2-aaec-e70f53b1003c|
|Screen Reader|no|
|VM|0%|
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
vscod805cf:30301675
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30404738
py29gd2263:30784851
vsclangdf:30492506
c4g48928:30535728
dsvsc012:30540252
pynewext54:30618038
vscrpc:30624061
showlangstatbar:30737417
ecj1e332:30687743
pythonfmttext:30716741
fixshowwlkth:30771523
showindicator:30805243
pythongtdpath:30726887
i26e3531:30792625
welcomedialog:30812478
pythonnosmt12:30779711
pythonidxpt:30768918
pythonnoceb:30776497
copilotsettingc:30808720
dsvsc013:30777762
dsvsc014:30777825
diffeditorv1:30786205
pythonlinttypecf:30823782
pythonmpsinfo:30842935
dsvsc015:30821418
pythontestfixt:30826906
pythonfb280951:30830809
pythonregdiag:30842812

```

</details>

<!-- generated by issue reporter -->