Windows 11'de WMIC'in kaldırılması, pidtree'deki Node süreç ağacı yönetimini sessizce bozuyor

Ne bozuldu

Microsoft'un WMIC komut satırı aracını Windows 11'den kaldırması, Node araçlarındaki süreç ağacı algılamasını sessizce bozuyor. dev.to'da bir yazıya göre, Node'dan bir süreç ağacını listelemenin standart yolu olarak tanımlanan, birçok aracın pkill tarzı davranışına altyapı sağlayan ve haftada milyonlarca indirme alan npm paketi pidtree, 1.0.0'ın altındaki tüm sürümlerde Windows'ta wmic'e başvuruyor. Güncel bir Windows 11 kurulumunda bu binary artık mevcut olmadığından her çağrı "spawn wmic ENOENT" hatasıyla reddediliyor. Daha da kötüsü, bu reddedilme genellikle yutuluyor: yazar, hatanın çağıran tarafın başarısız bir aramayı "bu sürecin çocuğu yok" olarak yorumladığı bir Promise.allSettled içine düştüğünü görmüş.

Görünür belirti önce geldi. Bir kodlama ajanını barındıran terminal bölmesi yaklaşık 77 MB bellek bildiriyordu — kabaca yalnızca PowerShell host'unun kendisi; ne ajan ne de başlattığı dev server sayılmıştı. Her bölme boşta bir shell gibi okunuyordu.

Belgelenmiş bir kaldırma, görünmez bir başarısızlık

Yazıya göre Microsoft, WMIC'i Windows 10 21H1'de kullanımdan kaldırdı ve Windows 11 22H2 ile birlikte varsayılan imajdan çıkarmaya başladı. Yazarın test makinesinde — Windows 11 Home, build 26200, Ağustos 2026'da kontrol edildi — Get-Command wmic basitçe tanınmıyor diyor. Kaldırma duyurulmuş ve belgelenmişti; buna rağmen bozulma sürüyor, çünkü wmic çağrıları geliştiricilerin gerçekten yazdığı uygulama kodunda değil, kütüphanelerin içinde yaşıyor.

pidtree 1.0.0 bunu çözüyor: önce yine wmic'i deniyor, spawn başarısız olursa PowerShell'in Get-CimInstance'ına geri düşüyor. Sorun ise semver'de. ^0.6.0 gibi bir caret aralığı asla 1.0.0'a çözümlenmez, çünkü 0.x sürümlerindeki caret semantiği yalnızca aynı minor içinde hareket eder. Yazarın kendi projesi ^0.6.0 belirtmişti, lockfile 0.6.0'a sabitlemişti ve sonuç olarak her Windows çağrısı yalnızca sorgulanan süreci içeren bir ağaç döndürüyordu. Pratik öneri: package'nin ima ettiğini değil, gerçekte çözümlenen sürümü kontrol edin.

wmic'i kendiniz değiştirmek

Yükseltme yapamayanlar için yazı, Get-CimInstance Win32_Process'ı öneriyor — bir performans uyarısıyla. İçgüdü PID başına bir filtrelenmiş sorgu göndermektir ama yazarın benchmark'ı, 5 filtrelenmiş sorgunun 517 ms aldığı halde 396 sürecin tamamının tek bir snapshot'ının yaklaşık 200 ms'de tamamlandığını gösteriyor. Ek yük dönen satır hacminde değil, her CIM sorgusunu başlatmadadır. Önerilen pattern, her polling döngüsü başına bir snapshot alıp bunu bellek içi bir ebeveynden-çocuklara map'ine dönüştürmek ve ardından ilgilendiğiniz her PID için bu map'i gezmektir.

Windows'ta bir ağacı öldürmek

Yazı aynı zamanda sorunun ikinci yarısını da ele alıyor: sonlandırma. Windows'ta POSIX tarzı süreç grupları ve yetimlerin otomatik temizliği yoktur, dolayısıyla Stop-Process ve Node'un process.kill(pid)'i tam olarak bir süreç sonlandırır. Bir kök shell'i öldürmek onun torunlarını çalışır halde bırakır; açık dosyalar ve portlar elde kalır, ebeveyn PID'leri artık ölü bir süreci işaret eder.

taskkill /F /T bunu, ağacı gezerek torunları atalarından önce sonlandırarak halleder. Sıralama önemlidir: önce kökü öldürürseniz, yetimleri bulmak için ihtiyaç duyduğunuz ebeveyn bağlantıları yok olur ve geride, temizlemeye çalıştığınız şeyle hiçbir şekilde bağlantısı olmayan kopuk süreçler kalır. Önce ağacı çözün ya da işin tamamını taskkill /F /T'ye devredin. Yazar ayrıca PID yeniden kullanımını bir risk olarak işaret ediyor — Windows PID'leri agresif biçimde geri dönüştürür, bu yüzden polling döngüleri arasında önbelleğe alınan her PID, zorla öldürmeden önce güncel bir snapshot'a karşı doğrulanmalıdır.

Soyağacı tamamen kaybolduğunda

Bazı süreçler hiçbir şekilde kökenlerine yeniden bağlanamaz. Bir ajan tarafından arka planda başlatılan bir dev server'ın çoğu zaman kullanılabilir bir soyağacı yoktur: ara süreçler çıkmıştır, ebeveyn PID'leri bayat veya geri dönüştürülmüştür ve çalıştırılabilir dosya yalnızca node.exe'dir. Kalan tek sinyal sürecin geçerli çalışma dizinidir — ancak Node, Windows'ta başka bir sürecin cwd'sini okumak için bir API sunmuyor. Yazı, koffi FFI kütüphanesini kullanarak ntdll'in NtQueryInformationProcess'ini çağırıp PEB üzerinden geçerli-dizin alanına kadar gitmeyi öneren bir geçici çözüm çiziyor; gerekli offset'lerin belgelenmediğini ve değişebileceğini de kabul ediyor. Yükseltilmiş süreçler ve diğer kullanıcıların süreçleri gerekli erişimi reddediyor, dolayısıyla bu teknik servisleri ve Docker Desktop gibi araçları sessizce atlıyor; retler her polling'de değil, PID başına bir kez loglanmalıdır.

Neden önemli

Bu, rutin ve iyi belgelenmiş bir platform kullanımdan kaldırmasının, bağımlılık grafiğinin derinliklerinde sessiz bir bozulmaya dönüşmesinin somut bir örneği. pidtree'ye bağımlı olan hiç kimse kendisi bir wmic çağrısı yazmadı; başarısızlık dolaylı olarak geliyor ve bir çökme değil, makul görünen bir boş sonuç olarak ortaya çıkıyor — tam da yıllarca hayatta kalabilen hata türü. Windows'ta terminal, ajan veya süreç yöneticisi geliştiren herkes için kontrol listesi kısa: çözümlenen pidtree sürümünü doğrulayın, PID başına sorgular yerine döngü başına bir CIM snapshot'ı alın, ağaçları önce-çocuk olacak şekilde öldürün ya da kökü taskkill /T'ye devredin ve önbelleğe alınmış bir PID'ye polling'ler arasında asla güvenmeyin.