Memakai WMI/CIM dari C# dan PowerShell — panduan praktis pengambilan informasi perangkat keras, pemantauan proses, dan kueri jarak jauh

“Saya ingin menampilkan nomor seri dan nama model PC di layar aplikasi bisnis.” “Saya ingin memantau ruang kosong disk server dan memberi peringatan.” “Saya ingin mendeteksi proses tertentu yang mulai berjalan.” “Saya ingin meng-query kondisi PC di lokasi jauh secara terpusat.” — permintaan semacam ini sudah jadi klasik saat membangun aplikasi bisnis dan alat pengelolaan Windows. Jawabannya yang sama klasiknya adalah WMI (Windows Management Instrumentation), atau dalam nama standarnya, CIM (Common Information Model).

flowchart TB
    accTitle: Permintaan klasik dan WMI/CIM
    accDescr: Jawaban klasik atas permintaan klasik aplikasi bisnis yaitu menampilkan nomor seri dan nama model, memantau ruang kosong disk, mendeteksi proses yang mulai, dan meng-query PC jarak jauh adalah WMI, atau dalam nama standar CIM
    r1["Nomor seri dan nama model"] --> ans["WMI (nama standar: CIM)"]
    r2["Memantau ruang kosong disk"] --> ans
    r3["Mendeteksi proses yang mulai"] --> ans
    r4["Meng-query PC jarak jauh"] --> ans

Gambar 1: Jawaban klasik atas empat permintaan klasik aplikasi bisnis adalah WMI/CIM.

Yang merepotkan, informasi seputar WMI mencampur yang lama dan yang baru. Pencarian menampilkan artikel berumur sepuluh tahun yang memakai Get-WmiObject berdampingan dengan artikel yang memakai Get-CimInstance; di sisi C# ada dua jalur, System.Management dan Microsoft.Management.Infrastructure. Sulit membedakan mana cara menulis yang berlaku sekarang, dan mana yang masih berjalan tetapi tidak dipilih untuk kode baru. Faktanya, Get-WmiObject tidak ada di PowerShell 7, dan itu baru terasa ketika skrip internal yang ditulis untuk 5.1 dimigrasikan.

Artikel ini ditujukan kepada pengembang C#/PowerShell yang mengimplementasikan pengambilan informasi perangkat keras, pemantauan proses, dan kueri PC jarak jauh di aplikasi bisnis. Isinya menata, berdasarkan sumber primer per Agustus 2026, mulai dari pemahaman minimal struktur WMI/CIM, cmdlet CIM PowerShell, dua API C#, resep yang sering dipakai, jebakan kinerja, hak, dan 64bit, sampai cara menilai situasi di mana WMI tidak seharusnya dipakai.

1. Kesimpulan dulu

• CIM adalah standar industri informasi pengelolaan yang disusun DMTF; WMI adalah implementasinya oleh Microsoft. API keluarga CIM di PowerShell dan C# adalah API generasi sekarang yang mengikuti standar ini, dan tujuan sambungannya adalah infrastruktur WMI yang sama.¹
• Yang berlaku di PowerShell adalah cmdlet CIM (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent). Cmdlet WMI lama (lima buah, termasuk Get-WmiObject) sudah dihapus sejak PowerShell 6 dan tidak berjalan di PowerShell 7.²
• Namespace bawaan adalah root/CIMV2; kueri sehari-hari pada dasarnya mempersempit kelas Win32_* di situ dengan WQL.³
• Kueri jarak jauh secara bawaan memakai WSMan (WinRM). -ComputerName membuat sesi WSMan sementara. Jika tujuan yang sama di-query berulang kali, memakai ulang sesi CIM (New-CimSession) adalah praktik mapan untuk kinerja; untuk mesin lama yang tidak bisa dikonfigurasi WinRM, ada opsi protokol DCOM.³⁴
• C# punya dua jalur: System.Management (ManagementObjectSearcher) dan Microsoft.Management.Infrastructure (CimSession). Keduanya khusus Windows, dan di .NET yang berlaku sekarang diimpor dari NuGet. Untuk kueri jarak jauh dan pemantauan yang serius, API MI — yang memakai sistem tipe yang sama dengan cmdlet CIM — lebih cocok.⁵⁶
• Deteksi proses yang mulai dilakukan dengan langganan peristiwa, bukan polling. Berlangganan Win32_ProcessStartTrace harus dijalankan dengan hak administrator.⁷⁸
• Jangan memakai SELECT * karena kebiasaan. Mempersempit data yang ditransfer dengan -Filter / -Property / -KeyOnly mencegah kira-kira setengah masalah kinerja WMI.³
• WMI bukan solusi untuk segala hal. Untuk pemantauan kinerja berfrekuensi tinggi, membaca-menulis pengaturan aplikasi sendiri, atau panggilan fungsi OS sekali jalan, performance counter, registri, API Win32, atau cmdlet khusus lebih cocok (tabel keputusan di bagian 8).

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 26, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Apa itu WMI/CIM — standar dan implementasi, namespace, kelas, WQL

Pertama, hubungan istilahnya ditata sekali.

flowchart TB
    accTitle: Hubungan standar CIM dan implementasi WMI
    accDescr: Standar CIM yang disusun dan dipelihara DMTF dipakai dalam kerangka inisiatif WBEM, implementasinya oleh Microsoft adalah WMI, MI generasi berikutnya kompatibel penuh dengan WMI lama, dan API keluarga CIM tersambung ke infrastruktur WMI yang sama
    dmtf["Disusun dan dipelihara DMTF"] --> cim["CIM (model standar industri)"]
    wbem["WBEM (inisiatif industri)"] --> wmi["WMI (implementasi Microsoft)"]
    cim --> wmi
    wmi -.-> mi["MI (generasi berikutnya, kompatibel penuh)"]
    api["API keluarga CIM (PowerShell / C#)"] --> wmi

Gambar 2: CIM adalah spesifikasi, WMI adalah implementasi di Windows. Tujuan sambungan API keluarga CIM adalah infrastruktur WMI yang sama.

Empat potongan struktur yang perlu dipegang pengembang:

• Namespace: hierarki yang mengelompokkan kelas. Untuk kueri sehari-hari hampir selalu root/CIMV2, yang juga bawaan cmdlet CIM.³ Yang lain termasuk root\default (provider registri, dan semacamnya).
• Kelas: tipe objek yang dikelola, misalnya Win32_ComputerSystem (komputer itu sendiri), Win32_LogicalDisk (drive logis), Win32_Process (proses). Kelas khusus Windows yang mewarisi kelas standar CIM (seperti CIM_LogicalDisk) memakai awalan Win32_.⁹
• Provider: komponen yang menyediakan substansi kelas. Saat di-query, provider menanyakan OS di tempat dan membangun nilainya.
• WQL: bahasa kueri mirip SQL. Seperti SELECT Name, State FROM Win32_Service WHERE StartMode = 'Auto', kelas diperlakukan seperti tabel lalu dipersempit. Bahasa kueri bawaan cmdlet CIM juga WQL.³

“Membaca informasi OS dan perangkat keras lewat kelas dan bahasa kueri yang terpadu” — itulah nilai WMI. Sebaliknya, penulisan dan operasi terbatas pada sebagian kelas yang punya metode yang bisa dipanggil lewat Invoke-CimMethod; ini bukan mekanisme yang bisa melakukan apa pun.

flowchart TB
    accTitle: Struktur kueri WMI
    accDescr: Kueri WQL diarahkan ke kelas Win32_* di dalam namespace root/CIMV2, provider yang menyediakan substansi kelas menanyakan OS di tempat untuk membuat nilai, lalu hasil dikembalikan
    wql["Kueri dengan WQL"] --> ns["Namespace root/CIMV2"]
    ns --> cls["Kelas Win32_*"]
    cls --> prov["Provider"]
    prov --> osq["Menanyakan OS di tempat"]
    osq --> res["Mengembalikan hasil"]

Gambar 3: Kueri menelusuri namespace, kelas, lalu provider; nilainya dibuat di tempat.

3. Pemakaian dari PowerShell — cmdlet CIM yang berlaku, cmdlet WMI sudah dihapus

3.1. Dasarnya Get-CimInstance

# Menentukan kelas (namespace bawaan root/CIMV2)
Get-CimInstance -ClassName Win32_OperatingSystem

# Tulis hanya isi klausa WHERE di -Filter (jangan tulis kata kunci WHERE)
Get-CimInstance -ClassName Win32_Service -Filter "StartMode = 'Auto' AND State <> 'Running'"

# Ambil hanya properti yang dibutuhkan agar volume transfer berkurang
Get-CimInstance -ClassName Win32_Process -Property Name, ProcessId, CreationDate

# Pakai -Query jika WQL ditulis utuh
Get-CimInstance -Query "SELECT * FROM Win32_Process WHERE Name LIKE 'p%'"

-Filter adalah klausa WHERE milik WQL itu sendiri; -Property membatasi kolom yang diambil.³ Nilai kembalian adalah objek CimInstance, dan properti tanggal (CreationDate, LastBootUpTime, dan semacamnya) sudah dikonversi ke DateTime. Berbeda dari Get-WmiObject lama, objek yang diambil tidak membawa metode secara langsung, jadi pemanggilan metode diserahkan ke Invoke-CimMethod.

flowchart TB
    accTitle: Pemanggilan metode CimInstance
    accDescr: CimInstance yang dikembalikan Get-CimInstance sudah punya properti tanggal terkonversi ke DateTime, tetapi tidak membawa metode secara langsung, jadi pemanggilan metode dilakukan dengan menyerahkan instans ke Invoke-CimMethod
    gci["Get-CimInstance"] --> inst["Objek CimInstance"]
    inst -.-> dt["Tanggal sudah DateTime"]
    inst -.-> nom["Tidak membawa metode langsung"]
    inst --> icm["Serahkan ke Invoke-CimMethod"]
    icm --> call["Pemanggilan metode"]

Gambar 4: CimInstance tidak membawa metode, jadi pemanggilan metode diserahkan ke Invoke-CimMethod.

# Memanggil metode instans: ambil pemilik setiap proses
Get-CimInstance -ClassName Win32_Process -Filter "Name = 'notepad.exe'" |
    Invoke-CimMethod -MethodName GetOwner

# Memanggil metode statis kelas: menjalankan proses
Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{ CommandLine = 'notepad.exe' }

# Memeriksa definisi kelas (daftar properti dan metode)
Get-CimClass -ClassName Win32_Process

3.2. Tabel migrasi dari cmdlet WMI lama

Sejak PowerShell 6 (termasuk PowerShell 7 yang berlaku sekarang), cmdlet WMI v1 berikut sudah dihapus. Fungsi yang sama disediakan modul CimCmdlets (WMI v2).²

Cmdlet CIM juga berjalan di Windows PowerShell 5.1, jadi yang baru ditulis, termasuk jika masih dijalankan di 5.1, ditulis di sisi CIM agar tidak menyisakan biaya migrasi. Gambaran koeksistensi dan migrasi 5.1 dan 7 ada di “Perbedaan Windows PowerShell 5.1 dan PowerShell 7”.

flowchart TB
    accTitle: Alasan menulis skrip baru dengan CIM
    accDescr: Skrip yang ditulis dengan cmdlet WMI masih berjalan di 5.1 tetapi sudah dihapus sejak PowerShell 6 sehingga harus ditulis ulang saat migrasi, sedangkan cmdlet CIM juga berjalan di 5.1 jadi jika yang baru ditulis di sisi CIM tidak ada biaya migrasi tersisa
    new["Skrip yang baru ditulis"] --> q1{"Ditulis dengan yang mana?"}
    q1 -->|Cmdlet WMI| old["Berjalan di 5.1"]
    q1 -->|Cmdlet CIM| cur["Juga berjalan di 5.1"]
    old --> del["Sudah dihapus di PowerShell 7"]
    del --> rew["Ditulis ulang saat migrasi"]
    cur --> norew["Tidak menyisakan biaya migrasi"]

Gambar 5: Jika yang baru ditulis dengan cmdlet CIM, tidak perlu ditulis ulang saat migrasi ke PowerShell 7.

4. Kueri jarak jauh — sesi CIM (WSMan secara bawaan) dan opsi DCOM

Cmdlet CIM, jika tujuan tidak ditentukan, tersambung ke WMI lokal lewat COM; jika -ComputerName ditentukan, mereka membuat sesi sementara lewat protokol WSMan (WinRM). Jika beberapa operasi dilakukan terhadap komputer yang sama, membuat sesi CIM lalu memakainya ulang lebih menguntungkan untuk kinerja.³

flowchart TB
    accTitle: Memilih cara koneksi CIM
    accDescr: Tanpa spesifikasi tersambung COM ke WMI lokal, spesifikasi ComputerName membuat sesi sementara WSMan di setiap kueri, beberapa operasi ke tujuan yang sama lebih efisien dengan memakai ulang New-CimSession, dan untuk tujuan tanpa WinRM ada opsi protokol DCOM
    exec["Menjalankan cmdlet CIM"] --> q1{"ComputerName ditentukan?"}
    q1 -->|Tidak| local["Koneksi COM ke WMI lokal"]
    q1 -->|Ya| q2{"Beberapa operasi ke tujuan yang sama?"}
    q2 -->|Sekali| temp["Sesi sementara WSMan"]
    q2 -->|Beberapa| sess["Pakai ulang New-CimSession"]
    temp -.-> cost["Dibuat di setiap kueri"]
    nowinrm["Tujuan tanpa WinRM"] -.-> dcom["Opsi protokol DCOM"]

Gambar 6: Kueri jarak jauh secara bawaan memakai WSMan; beberapa operasi ke tujuan yang sama memakai ulang sesi CIM.

# Sekali jalan: -ComputerName (sesi sementara dibuat setiap kali)
Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName Server01, Server02

# Kueri berulang: pakai ulang sesi CIM
$session = New-CimSession -ComputerName Server01
Get-CimInstance -ClassName Win32_OperatingSystem -CimSession $session
Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType = 3" -CimSession $session
Remove-CimSession $session

Untuk mesin lama yang tidak bisa dikonfigurasi WinRM, atau tujuan yang tidak bisa disambungkan lewat WSMan, protokol DCOM bisa dipilih.⁴

$dcom = New-CimSessionOption -Protocol Dcom
$session = New-CimSession -ComputerName OldServer -SessionOption $dcom

Prasyarat kueri jarak jauh:

• WinRM sudah dikonfigurasi di tujuan. winrm quickconfig sekaligus menyetel layanan agar start otomatis, membuat listener HTTP (port bawaan 5985), dan mendaftarkan pengecualian firewall.¹⁰ Untuk sambungan HTTPS (port bawaan 5986) itu belum cukup: siapkan sertifikat server, lalu konfigurasi listener HTTPS secara terpisah, misalnya dengan winrm quickconfig -transport:https.¹⁰
• Port terkait terbuka di firewall jalur. Praktik merancang dan mendaftarkan aturan inbound dibahas di artikel “Windows Firewall dan aplikasi bisnis”.
• Autentikasi. Di lingkungan domain, autentikasi bersama memakai Kerberos. Di workgroup Kerberos tidak tersedia, jadi pendaftaran ke TrustedHosts di sisi klien kadang diperlukan. Daftarkan hanya yang benar-benar perlu.¹⁰
• Hak. Pada konfigurasi bawaan, kueri dan operasi WMI jarak jauh pada dasarnya dijalankan dengan akun yang termasuk grup administrator di tujuan. Jika dibuka untuk pengguna biasa, izin akses perlu dikonfigurasi baik di WinRM maupun di namespace WMI.¹⁰
• DCOM tidak punya port listen yang tetap (memakai port dinamis RPC), sehingga merancang lewat firewall menjadi lebih sulit. Untuk mekanisme yang baru dibangun, WSMan sebagai bawaan lebih aman.

flowchart TB
    accTitle: Memeriksa prasyarat kueri jarak jauh
    accDescr: Di tujuan, winrm quickconfig sekaligus menyetel start otomatis layanan, membuat listener HTTP, dan mendaftarkan pengecualian firewall; listener HTTPS dikonfigurasi terpisah setelah menyiapkan sertifikat; di lingkungan workgroup, pendaftaran ke TrustedHosts kadang diperlukan
    qc["winrm quickconfig"] --> svc["Layanan start otomatis"]
    qc --> lis["Membuat listener HTTP (5985)"]
    qc --> fw["Pengecualian firewall"]
    lis ~~~ https["Listener HTTPS (5986)"]
    https -.-> cert["Siapkan sertifikat, konfigurasi terpisah"]
    fw ~~~ wg["Lingkungan workgroup"]
    wg -.-> th["Daftarkan ke TrustedHosts"]

Gambar 7: winrm quickconfig menerapkan konfigurasi bawaan sekaligus; listener HTTPS dan autentikasi workgroup ditangani terpisah.

5. Pemakaian dari C# — System.Management dan Microsoft.Management.Infrastructure

Ada dua jalur API untuk memakai WMI dari C#. Keduanya khusus Windows.

5.1. System.Management: dasar ManagementObjectSearcher

Serahkan WQL sebagai string, lalu terima koleksi hasil dengan Get().⁵

// NuGet: System.Management (khusus Windows)
using System.Management;

using var searcher = new ManagementObjectSearcher(
    @"root\cimv2",
    "SELECT DeviceID, FreeSpace, Size FROM Win32_LogicalDisk WHERE DriveType = 3");

foreach (ManagementObject disk in searcher.Get())
{
    var freeGb = (ulong)disk["FreeSpace"] / 1024.0 / 1024.0 / 1024.0;
    var sizeGb = (ulong)disk["Size"] / 1024.0 / 1024.0 / 1024.0;
    Console.WriteLine($"{disk["DeviceID"]} kosong {freeGb:F1} GB / total {sizeGb:F1} GB");
}

Properti dikembalikan sebagai object lewat pengindeks, jadi konfirmasikan tipe CIM di dokumentasi kelas (pada contoh ini FreeSpace / Size adalah uint64⁹) lalu cast. Mengira itu int lalu mencast-nya hingga InvalidCastException adalah tersandung klasik yang pertama.

flowchart TB
    accTitle: Jebakan pengambilan properti dan cast
    accDescr: Properti System.Management dikembalikan sebagai object lewat pengindeks, jadi tipe CIM harus dikonfirmasi di dokumentasi kelas sebelum di-cast; mengira int lalu mencast menimbulkan InvalidCastException
    idx["Ambil lewat pengindeks"] --> obj["Dikembalikan sebagai object"]
    obj --> chk["Konfirmasi tipe CIM di dokumentasi"]
    chk --> cast["Cast ke tipe yang benar"]
    obj -.-> wrong["Mengira int lalu cast"]
    wrong -.-> ex["InvalidCastException"]

Gambar 8: Properti dikembalikan sebagai object, jadi konfirmasikan tipe CIM sebelum cast.

5.2. API MI: dasar CimSession

CimSession menangani lokal dan jarak jauh dengan bentuk yang sama. Enumerasi, kueri, pemanggilan metode, langganan peristiwa, dan varian asinkronnya lengkap.⁶

// NuGet: Microsoft.Management.Infrastructure (khusus Windows)
using Microsoft.Management.Infrastructure;

// Lokal: CimSession.Create(null); jarak jauh: serahkan nama komputer
using CimSession session = CimSession.Create(null);

IEnumerable<CimInstance> disks = session.QueryInstances(
    @"root\cimv2", "WQL",
    "SELECT DeviceID, FreeSpace, Size FROM Win32_LogicalDisk WHERE DriveType = 3");

foreach (CimInstance disk in disks)
{
    var deviceId = (string)disk.CimInstanceProperties["DeviceID"].Value;
    var free = (ulong)disk.CimInstanceProperties["FreeSpace"].Value;
    Console.WriteLine($"{deviceId} kosong {free / 1024.0 / 1024 / 1024:F1} GB");
}

Tipe yang ditangani sama dengan CimInstance yang dikembalikan cmdlet CIM PowerShell, jadi alur “coba di PowerShell, lalu salin ke C#” terhubung secara alami. Untuk merancang kolaborasi C# dan PowerShell itu sendiri, lihat juga “Cara menjalankan PowerShell dari C# dan menerima hasilnya sebagai objek”.

flowchart TB
    accTitle: Alur mencoba di PowerShell lalu menyalin ke C#
    accDescr: Cmdlet CIM PowerShell dan API MI C# menangani tipe CimInstance yang sama, jadi alur pengembangan mencoba di PowerShell lalu menyalin ke C# terhubung secara alami
    trial["Coba di PowerShell"] --> gci["Cmdlet CIM"]
    impl["Implementasi penuh di C#"] --> mi["API MI"]
    gci --> ci["Tipe CimInstance yang sama"]
    mi --> ci
    ci -.-> flow["Penyalinan terhubung secara alami"]

Gambar 9: Cmdlet CIM dan API MI menangani tipe CimInstance yang sama, jadi uji coba menuju implementasi penuh.

6. Resep yang sering dipakai

6.1. Tabel cepat kelas klasik

6.2. Klasik pengelolaan aset: nomor seri, nama model, ruang disk

# Informasi model dan nomor seri (untuk dicocokkan dengan daftar aset PC)
$cs   = Get-CimInstance -ClassName Win32_ComputerSystem -Property Manufacturer, Model
$bios = Get-CimInstance -ClassName Win32_BIOS -Property SerialNumber
[pscustomobject]@{
    Manufacturer = $cs.Manufacturer
    Model        = $cs.Model
    Serial       = $bios.SerialNumber
}

# Ruang kosong disk lokal (DriveType = 3)
Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType = 3" |
    Select-Object DeviceID,
        @{ Name = 'FreeGB'; Expression = { [math]::Round($_.FreeSpace / 1GB, 1) } },
        @{ Name = 'SizeGB'; Expression = { [math]::Round($_.Size / 1GB, 1) } }

DriveType = 3 adalah nilai “disk lokal”; removable (2), network drive (4), dan CD (5) dikeluarkan.⁹ Untuk pemantauan, cukup menggilir skrip yang sama ke setiap server lewat sesi CIM — itu sudah jadi fondasi pemantauan disk tanpa agen.

flowchart TB
    accTitle: Fondasi pemantauan disk tanpa agen
    accDescr: Filter DriveType 3 mengeluarkan removable, network drive, dan CD sehingga hanya disk lokal yang menjadi sasaran; skrip yang sama digilir ke setiap server lewat sesi CIM, sehingga fondasi pemantauan disk tanpa agen terbentuk
    scr["Skrip mengambil ruang kosong"] --> flt["Persempit dengan DriveType = 3"]
    flt -.-> exc["Keluarkan removable dan semacamnya"]
    scr --> ses["Lewat sesi CIM"]
    ses --> srvs["Gilirkan ke setiap server"]
    srvs --> mon["Pemantauan tanpa agen"]

Gambar 10: Fondasi pemantauan adalah menggilir skrip yang sudah dipersempit ke disk lokal ke setiap server lewat sesi CIM.

6.3. Mendeteksi proses yang mulai — langganan peristiwa

Jangan “mengambil Win32_Process secara berkala lalu melihat selisihnya” dengan polling; pakai langganan peristiwa. Cara termudah untuk proses yang mulai adalah berlangganan Win32_ProcessStartTrace (kelas peristiwa provider jejak kernel; punya ProcessName / ProcessID / ParentProcessID, dan semacamnya⁸).

# Jalankan di PowerShell dengan hak administrator
$action = {
    $name = $Event.SourceEventArgs.NewEvent.ProcessName
    $id   = $Event.SourceEventArgs.NewEvent.ProcessID
    Write-Host "Proses dimulai: $name (PID=$id)"
}
Register-CimIndicationEvent -ClassName Win32_ProcessStartTrace `
    -SourceIdentifier ProcessStarted -Action $action

Langganan tetap berlaku selama sesi PowerShell tempat pendaftaran ini masih hidup, dan -Action dijalankan setiap kali proses mulai. Jika perintah pelepasan dijalankan sekaligus dalam satu napas, langganan hilang sebelum pemantauan sempat dimulai. Pelepasan dijalankan saat pemantauan diakhiri.

# Saat pemantauan diakhiri: lepaskan langganan
Unregister-Event -SourceIdentifier ProcessStarted

Register-CimIndicationEvent mendaftarkan langganan dengan nama kelas atau kueri peristiwa WQL, dan blok skrip -Action dijalankan setiap kali peristiwa masuk.⁷ Berlangganan kelas ini memerlukan hak administrator.⁷ Siapa yang boleh menerima peristiwa dikendalikan descriptor keamanan kelas peristiwa; sebagai pengguna biasa, akses ditolak.⁸

sequenceDiagram
    accTitle: Alur langganan peristiwa proses yang mulai
    accDescr: Sesi PowerShell dengan hak administrator mendaftarkan langganan lewat Register-CimIndicationEvent; setiap kali proses mulai, peristiwa masuk dan Action dijalankan; saat pemantauan diakhiri, Unregister-Event melepaskan langganan
    participant ps as Sesi PowerShell
    participant wmi as WMI
    ps->>wmi: Daftar langganan dengan Register-CimIndicationEvent
    Note over ps: Jalankan dengan hak administrator
    wmi-->>ps: Peristiwa masuk setiap kali proses mulai
    ps->>ps: Jalankan -Action
    ps->>wmi: Lepaskan dengan Unregister-Event (saat pemantauan selesai)

Gambar 11: Langganan berlaku selama sesi pendaftaran masih hidup; pelepasan dilakukan saat pemantauan diakhiri.

Cara lain adalah peristiwa pembuatan instans generik (__InstanceCreationEvent) yang bisa dipakai pada kelas mana pun. Di sini WMI melakukan polling pada interval WITHIN lalu mengubah selisih menjadi peristiwa, jadi trade-off antara interval deteksi dan beban diputuskan sendiri.

flowchart TB
    accTitle: Dua cara langganan untuk mendeteksi proses yang mulai
    accDescr: Win32_ProcessStartTrace berlangganan kelas peristiwa provider jejak kernel; __InstanceCreationEvent generik membuat WMI melakukan polling pada interval WITHIN lalu mengubah selisih menjadi peristiwa, sehingga trade-off interval deteksi dan beban diputuskan sendiri
    goal["Mendeteksi proses yang mulai"] --> t1["Win32_ProcessStartTrace"]
    goal --> t2["__InstanceCreationEvent"]
    t1 -.-> k1["Langganan jejak kernel"]
    t2 -.-> w1["Polling pada interval WITHIN"]
    w1 -.-> tr["Trade-off interval dan beban"]

Gambar 12: Berlangganan kelas peristiwa khusus, atau memakai peristiwa pembuatan instans generik dengan interval polling.

# Pantau instans baru Win32_Process dengan polling interval 5 detik
$query = "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_Process'"
Register-CimIndicationEvent -Query $query -SourceIdentifier ProcPoll -Action {
    Write-Host "Dimulai: $($Event.SourceEventArgs.NewEvent.TargetInstance.Name)"
}

Di C# (System.Management), ManagementEventWatcher mengisi peran yang sama.¹¹

using System.Management;

// Di proses yang berjalan sebagai administrator
var watcher = new ManagementEventWatcher(
    new WqlEventQuery("SELECT * FROM Win32_ProcessStartTrace"));
watcher.EventArrived += (_, e) =>
{
    var name = (string)e.NewEvent["ProcessName"];
    var pid  = (uint)e.NewEvent["ProcessID"];
    Console.WriteLine($"Proses dimulai: {name} (PID={pid})");
};
watcher.Start();
// Saat pemantauan selesai, jangan lupa watcher.Stop() dan Dispose

Jika dimasukkan ke pemantauan yang selalu hidup, rancang juga pendaftaran ulang ketika langganan putus (saat layanan di-restart, saat error). Desain “memeriksa dan menampilkan keadaan”, termasuk pemantauan perangkat, dibahas di “Praktik terbaik memeriksa dan menampilkan keadaan perangkat eksternal”.

stateDiagram-v2
    accTitle: Siklus hidup langganan pemantauan yang selalu hidup
    accDescr: Pada pemantauan yang selalu hidup, keadaan sedang berlangganan bisa putus karena layanan di-restart atau error, jadi rancang deteksi putusnya lalu daftar ulang hingga kembali berlangganan
    s1: Sedang berlangganan
    s2: Langganan putus
    s3: Daftar ulang
    [*] --> s1
    s1 --> s2: Layanan di-restart / error
    s2 --> s3
    s3 --> s1

Gambar 13: Pada pemantauan yang selalu hidup, rancang juga daftar ulang saat langganan putus agar kembali ke keadaan berlangganan.

7. Jebakan — kinerja, hak, 64bit, repositori, tanggal

7.1. SELECT * dan polling yang berlebihan

Kueri WMI adalah pemrosesan “provider membuat nilai di tempat”, bukan gratis. Dua antipola klasiknya:

• Memakai SELECT * karena kebiasaan. Mengambil semua properti semua baris Win32_Process memperbesar kerja provider dan transfer jaringan (saat jarak jauh). Persempit baris dengan -Filter, kolom dengan -Property, dan jika yang dibutuhkan hanya kunci untuk operasi berikutnya, pakai -KeyOnly. Semuanya disediakan resmi “untuk mengecilkan ukuran objek dan lalu lintas jaringan”.³
• Polling berperiode pendek. Desain seperti “setiap 1 detik Get-CimInstance Win32_Process” diganti dengan langganan peristiwa di bagian 6.3. Jika tetap memakai bentuk polling (WITHIN), perlebar interval sampai cukup untuk kebutuhan.

Mengulang -ComputerName satu mesin demi satu ke tujuan jarak jauh juga boros. Sesi sementara dibuat di setiap kueri, jadi beberapa operasi memakai ulang sesi CIM.³

flowchart TB
    accTitle: Antipola kinerja dan penggantinya
    accDescr: Kebiasaan SELECT asterisk dipersempit baris dan kolomnya dengan Filter dan Property, kunci saja memakai KeyOnly; polling berperiode pendek diganti langganan peristiwa; pengulangan ComputerName satu mesin diganti memakai ulang sesi CIM
    a1["Kebiasaan SELECT *"] --> f1["Persempit dengan Filter dan Property"]
    f1 -.-> f2["Jika hanya kunci, KeyOnly"]
    a2["Polling berperiode pendek"] --> f3["Ganti dengan langganan peristiwa"]
    a3["ComputerName satu mesin demi satu"] --> f4["Pakai ulang sesi CIM"]

Gambar 14: Mempersempit baris, kolom, dan kunci, plus mengganti ke langganan peristiwa, mencegah kira-kira setengah masalah kinerja WMI.

7.2. Hak untuk langganan peristiwa

Seperti di bagian 6.3, berlangganan keluarga Win32_ProcessStartTrace mensyaratkan hak administrator.⁷ “Berjalan di mesin pengembangan (dijalankan sebagai administrator), tetapi pemantauan tidak jalan di lingkungan pengguna biasa di situs pelanggan” adalah kecelakaan klasik, sejajar dengan dialog notifikasi firewall. Jika pemantauan dimasukkan ke aplikasi bisnis yang berjalan sebagai pengguna biasa, pertimbangkan memisahkan bagian pemantauan ke layanan Windows (LocalSystem, dan semacamnya) dan menghubungkannya ke aplikasi lewat komunikasi antarproses.

flowchart TB
    accTitle: Konfigurasi pemantauan di lingkungan pengguna biasa
    accDescr: Langganan yang mensyaratkan hak administrator dipisah dari aplikasi yang berjalan sebagai pengguna biasa, bagian pemantauan dipindah ke layanan Windows yang dijalankan sebagai LocalSystem dan semacamnya, lalu dihubungkan ke aplikasi lewat komunikasi antarproses
    svcm["Layanan Windows untuk pemantauan"] --> subm["Berlangganan jejak start"]
    svcm -.-> lsm["Dijalankan sebagai LocalSystem dan semacamnya"]
    appm["Aplikasi (pengguna biasa)"] ---|Komunikasi antarproses| svcm

Gambar 15: Langganan yang butuh hak administrator dipisah ke sisi layanan, lalu dihubungkan ke aplikasi lewat komunikasi antarproses.

7.3. 32bit/64bit dan provider

Di Windows 64bit, sebagian provider punya edisi 32bit dan 64bit; secara bawaan sisi yang cocok dengan jumlah bit aplikasi pemanggil yang menjawab.¹² Contoh khas adalah provider registri (StdRegProv) di root\default: dibaca dari aplikasi 32bit, yang dikembalikan adalah nilai sisi Wow6432Node (tampilan 32bit).¹² Jika “nilai registri yang dibaca WMI berbeda dari yang terlihat di regedit”, curigai ini dulu. Jika tampilan sisi sebaliknya yang dibutuhkan, minta secara eksplisit dengan __ProviderArchitecture (dan __RequiredArchitecture jika harus dipaksa) di konteks saat menyambung.¹² Gambaran masalah jumlah bit secara keseluruhan juga dibahas di “Memanggil API Win32 dengan aman dari C# — panduan praktis P/Invoke”.

flowchart TB
    accTitle: Pemilihan provider di lingkungan 64bit
    accDescr: Secara bawaan provider yang cocok dengan jumlah bit aplikasi pemanggil yang menjawab; kueri registri aplikasi 32bit menerima nilai sisi Wow6432Node, tetapi tampilan sisi sebaliknya bisa diminta secara eksplisit dengan __ProviderArchitecture
    q1{"Jumlah bit pemanggil?"} -->|32bit| p32["Provider 32bit yang menjawab"]
    q1 -->|64bit| p64["Provider 64bit yang menjawab"]
    p32 -.-> wow["Registri: nilai sisi Wow6432Node"]
    ctx["Menentukan __ProviderArchitecture"] -.-> ov["Minta tampilan sisi sebaliknya secara eksplisit"]

Gambar 16: Secara bawaan sisi yang cocok dengan jumlah bit pemanggil yang menjawab, jadi aplikasi 32bit membaca sisi Wow6432Node.

7.4. Gejala dan penanganan repositori WMI yang rusak

Definisi kelas WMI disimpan di repositori (bukan satu berkas; kumpulan berkas di folder Repository berfungsi sebagai basis data¹³). Jika terjadi inkonsistensi, error seperti “kelas yang seharusnya ada tidak ditemukan” atau “namespace tidak valid” mulai muncul meskipun aplikasi tidak diubah. Untuk menelusuri dan memperbaiki, pakai winmgmt.exe.¹³

rem Pemeriksaan konsistensi (jika hasilnya inconsistent, ada inkonsistensi)
winmgmt /verifyrepository

rem Pemeriksaan konsistensi + bangun ulang jika inkonsisten (isi yang bisa dibaca digabung)
winmgmt /salvagerepository

Yang perlu diingat: jangan menjadikan penghapusan atau inisialisasi repositori sebagai langkah pertama. Error yang muncul lewat WMI kadang berasal dari bagian OS lain, dan Microsoft menyatakan secara tegas bahwa menjadikan penghapusan repositori sebagai penanganan pertama “bisa merusak sistem atau aplikasi yang terpasang”.¹³ Ikuti urutan konfirmasi dengan /verifyrepository → perbaikan dengan /salvagerepository.

flowchart TB
    accTitle: Langkah menelusuri inkonsistensi repositori WMI
    accDescr: Jika muncul error seperti kelas tidak ditemukan, periksa konsistensi dengan verifyrepository milik winmgmt; jika inkonsisten, bangun ulang dengan salvagerepository; jangan jadikan penghapusan atau inisialisasi repositori sebagai langkah pertama
    sym["Error seperti kelas tidak ditemukan"] --> verify["winmgmt /verifyrepository"]
    verify --> q1{"Hasilnya inconsistent?"}
    q1 -->|Ya| salvage["winmgmt /salvagerepository"]
    q1 -->|Tidak| other["Curigai penyebab di bagian OS lain"]
    salvage -.-> merge["Isi yang bisa dibaca digabung"]
    del["Menghapus atau menginisialisasi repositori"] -.-> ng["Jangan jadi langkah pertama"]

Gambar 17: Ikuti urutan verify lalu salvage; jangan jadikan penghapusan sebagai langkah pertama.

7.5. Konversi format tanggal DMTF

Tanggal WMI disimpan sebagai string format DMTF spesifikasi CIM yyyymmddHHMMSS.mmmmmm±UUU (angka di ujung adalah offset dari UTC dalam menit; contoh: 20260801100000.000000+540). Jangan potong-tempel nilai mentah sebagai string; pakai API konversi.

• C# (System.Management): ManagementDateTimeConverter menyediakan konversi dua arah antara format DMTF dan DateTime / TimeSpan.¹¹
• API keluarga CIM (Get-CimInstance / API MI): properti tanggal sudah dikembalikan sebagai DateTime, jadi masalah ini tidak muncul. (Get-CimInstance Win32_OperatingSystem).LastBootUpTime bisa dipakai langsung sebagai DateTime dalam perhitungan.

flowchart TB
    accTitle: Menangani format tanggal DMTF
    accDescr: Tanggal WMI disimpan sebagai string format DMTF; jika nilai mentah dibaca dengan System.Management, konversi dengan ManagementDateTimeConverter; API keluarga CIM mengembalikan DateTime yang sudah dikonversi; jangan potong-tempel string sendiri
    dmtf["String format DMTF"] --> q1{"Diambil dengan API mana?"}
    q1 -->|System.Management| conv["ManagementDateTimeConverter"]
    q1 -->|API keluarga CIM| done["Dikembalikan sudah sebagai DateTime"]
    conv --> dtv["Konversi ke DateTime / TimeSpan"]
    cut["Potong-tempel string sendiri"] -.-> ng["Jangan dipakai"]

Gambar 18: Serahkan konversi string DMTF pada API konversi; dengan API keluarga CIM, pakai DateTime yang sudah dikonversi apa adanya.

8. Situasi di mana WMI tidak seharusnya dipakai — tabel keputusan sarana

WMI unggul sebagai “pintu baca yang terpadu”, tetapi tidak selalu pilihan terbaik. Berikut patokan pemakaian di lapangan.

Sumbu keputusannya sederhana: di wilayah yang sudah punya mekanisme khusus, pakai mekanisme khusus itu; pakai WMI/CIM untuk kueri lintas dan kueri jarak jauh. Get-NetFirewallRule di baris terakhir, secara internal, adalah kumpulan cmdlet yang dibangun di atas CIM — bentuk “menikmati manfaatnya tanpa menyentuh WMI/CIM secara langsung”.

flowchart TB
    accTitle: Sumbu keputusan sarana
    accDescr: Di wilayah yang sudah punya mekanisme khusus, pakai mekanisme khusus itu; untuk kueri lintas dan kueri jarak jauh di wilayah tanpa mekanisme khusus, pakai WMI dan CIM; cmdlet berbasis CIM khusus adalah bentuk yang menikmati manfaat tanpa menyentuh WMI dan CIM secara langsung
    q1{"Ada mekanisme khusus?"} -->|Ada| ded["Pakai mekanisme khusus"]
    q1 -->|Tidak| wmi["Pakai WMI / CIM"]
    wmi -.-> use["Kueri lintas dan kueri jarak jauh"]
    cmd["Cmdlet berbasis CIM khusus"] -.-> ben["Bentuk yang hanya menikmati manfaat"]

Gambar 19: Di wilayah yang sudah punya mekanisme khusus, pakai yang khusus; pakai WMI/CIM untuk kueri lintas dan kueri jarak jauh.

9. Ringkasan

• CIM adalah standar industri DMTF, WMI adalah implementasinya oleh Microsoft. Cmdlet CIM PowerShell maupun API MI C# adalah pintu masuk generasi sekarang yang mengikuti standar ini.
• Di PowerShell, Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent yang berlaku. Get-WmiObject dan cmdlet WMI lainnya tidak ada di PowerShell 7, jadi skrip baru ditulis di sisi CIM meski masih untuk 5.1.
• Kueri jarak jauh secara bawaan memakai WSMan (WinRM); beberapa operasi memakai ulang sesi CIM. Untuk tujuan tanpa WinRM, opsi DCOM adalah jalan keluar.
• Di C#, pilih antara System.Management (ringan, berorientasi lokal) dan Microsoft.Management.Infrastructure (berorientasi jarak jauh dan pemantauan, sistem tipe sama dengan cmdlet CIM). Keduanya paket NuGet khusus Windows.
• Pemantauan proses memakai langganan peristiwa, bukan polling. Berlangganan Win32_ProcessStartTrace memerlukan hak administrator.
• Hindari SELECT * dan polling berperiode pendek; persempit dengan -Filter / -Property / -KeyOnly. Ingat bahwa kueri dari proses 32bit mengarah ke provider 32bit, tanggal DMTF memakai API konversi, dan repositori yang rusak ditangani dengan urutan verify → salvage, bukan penghapusan.
• Jangan bawa WMI ke wilayah yang sudah punya mekanisme khusus (pengaturan, performance counter, panggilan API sekali jalan). Pakai WMI/CIM untuk kueri lintas dan kueri jarak jauh — itu satu kalimat tentang kapan memakainya.

Artikel terkait

• Cara menjalankan PowerShell dari C# (CSharp) dan menerima hasilnya sebagai objek
• Kumpulan perintah PowerShell praktis — menambah fungsi kecil yang sering dipakai sehari-hari
• Perbedaan Windows PowerShell 5.1 dan PowerShell 7 — panduan praktis migrasi skrip internal
• Praktik terbaik memeriksa dan menampilkan keadaan perangkat eksternal — merancang lebih dari sekadar “tersambung”
• Memanggil API Win32 dengan aman dari C# — panduan praktis P/Invoke (DllImport / LibraryImport / CsWin32)
• Apa itu TPM di Windows — penjelasan bergambar tentang “brankas yang tidak mengeluarkan kunci” dan measured boot

Area konsultasi terkait

Di KomuraSoft, kami menangani pemasukan pengambilan informasi perangkat keras, pemantauan proses, dan kueri PC jarak jauh dengan WMI/CIM ke aplikasi bisnis, migrasi skrip internal berbasis Get-WmiObject ke cmdlet CIM, serta penyelidikan penyebab jenis “berjalan di mesin pengembangan, tetapi error hak di situs pelanggan”. Konsultasi bisa dijalankan sebagai satu rangkaian, dari uji coba di PowerShell sampai implementasi penuh di C#.

• Pengembangan aplikasi Windows
• Penyelidikan bug dan analisis penyebab
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apa perbedaan WMI dan CIM?

CIM adalah model standar industri untuk merepresentasikan objek yang dikelola — sistem, perangkat, dan semacamnya — yang disusun dan dipelihara DMTF (Distributed Management Task Force). WMI adalah implementasi Microsoft atas inisiatif WBEM yang memakai standar itu, dan sudah tertanam di Windows. Singkatnya, CIM adalah spesifikasinya, WMI adalah implementasinya di Windows. Get-CimInstance di PowerShell dan Microsoft.Management.Infrastructure di C# memakai nama CIM karena API-nya mengikuti standar ini; tujuan sambungannya tetap infrastruktur WMI yang sama. Dalam pekerjaan sehari-hari, cukup dipahami sebagai meng-query kelas WMI (Win32_* dan semacamnya) lewat API keluarga CIM.

Apakah Get-WmiObject sudah tidak bisa dipakai?

Masih berjalan di Windows PowerShell 5.1, tetapi sejak PowerShell 6 (termasuk PowerShell 7 yang dipakai sekarang) lima cmdlet WMI v1 — Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Set-WmiInstance, dan Remove-WmiObject — sudah dihapus dan tidak bisa dijalankan. Fungsi yang sama disediakan modul CimCmdlets (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent, dan semacamnya). Skrip baru lebih aman ditulis dengan cmdlet CIM, termasuk jika masih dijalankan di 5.1. Dengan begitu, bagian WMI tidak perlu ditulis ulang saat migrasi ke PowerShell 7.

Untuk memakai WMI dari C#, pilih System.Management atau Microsoft.Management.Infrastructure?

Keduanya khusus Windows, dan dari .NET yang berlaku sekarang diimpor sebagai paket NuGet. System.Management adalah API klasik: cukup menyerahkan WQL ke ManagementObjectSearcher, dan itu sudah cukup jika intinya mengambil informasi lokal. ManagementDateTimeConverter untuk mengonversi tanggal DMTF juga ada di sini. Microsoft.Management.Infrastructure (API MI) memakai sistem tipe yang sama (CimSession / CimInstance) dengan cmdlet CIM PowerShell, dan menangani kueri jarak jauh lewat WSMan, metode asinkron, serta langganan peristiwa (Subscribe) dalam satu rangkaian. Jika kueri dan pemantauan PC jarak jauh akan dimasukkan ke produk secara serius, API MI adalah pilihan yang masuk akal.

Get-CimInstance tidak tersambung ke PC jarak jauh. Apa yang harus diperiksa?

Pertama, pastikan WinRM sudah dikonfigurasi di mesin tujuan. Operasi CIM dengan -ComputerName membuat sesi sementara lewat protokol WSMan (WinRM), jadi layanan WinRM dan listener harus berjalan di tujuan. winrm quickconfig menerapkan konfigurasi bawaan (menyalakan layanan, membuat listener, dan menambah pengecualian firewall). Port bawaan adalah 5985 untuk HTTP dan 5986 untuk HTTPS; periksa juga firewall di sepanjang jalur. Di lingkungan workgroup, autentikasi bersama Kerberos tidak tersedia, jadi tujuan mungkin perlu didaftarkan ke TrustedHosts di sisi klien. Jika WinRM sama sekali tidak bisa dikonfigurasi di tujuan, sambungkan lewat DCOM dengan opsi dari New-CimSessionOption -Protocol Dcom.

Mengapa tanggal WMI dikembalikan dalam format seperti 20260801100000.000000+540?

Tanggal WMI disimpan sebagai string menurut spesifikasi CIM DMTF (yyyymmddHHMMSS.mmmmmm±UUU; angka di ujung adalah offset dari UTC dalam menit). Jika nilai mentah dibaca dengan Get-WmiObject lama atau System.Management, string itu dikembalikan apa adanya. Di C# (System.Management), ManagementDateTimeConverter menyediakan konversi antara format DMTF dan DateTime / TimeSpan; pakai itu, jangan potong-tempel string sendiri. Jika data diambil lewat API keluarga CIM seperti Get-CimInstance, properti tanggal sudah dikembalikan sebagai DateTime, jadi masalah ini tidak muncul.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.