C# और PowerShell से WMI/CIM का उपयोग — Hardware जानकारी, process monitoring और remote query की practical guide

«PC का serial number और model नाम business app की screen पर दिखाना है।» «Server के disk खाली स्थान की monitoring कर चेतावनी देनी है।» «किसी खास process के start होने का पता लगाना है।» «दूर बैठे PC की अवस्था एक जगह query करनी है।» — Windows के business apps और management tools के निर्माण में ये ज़रूरतें बार-बार आती हैं। और उनका आम उत्तर WMI (Windows Management Instrumentation) है, या standard नाम से CIM (Common Information Model)।

flowchart TB
    accTitle: आम ज़रूरतें और WMI/CIM
    accDescr: Serial number और model नाम दिखाना, disk खाली स्थान की monitoring, process start होने का पता, remote PC की query जैसी business app की आम ज़रूरतों का आम उत्तर WMI है, और standard नाम से CIM
    r1["Serial number・model नाम"] --> ans["WMI（standard नाम CIM）"]
    r2["Disk खाली स्थान की monitoring"] --> ans
    r3["Process start होने का पता"] --> ans
    r4["Remote PC की query"] --> ans

चित्र 1: Business app की चार आम ज़रूरतों का आम उत्तर WMI/CIM है।

कठिनाई यह है कि WMI की जानकारी पुरानी और नई मिली-जुली है। खोजें तो Get-WmiObject वाले दस वर्ष पुराने लेख Get-CimInstance वाले लेखों के साथ बैठे मिलते हैं, और C# पक्ष पर System.Management तथा Microsoft.Management.Infrastructure दो वंश हैं। कौन वर्तमान लिखने का तरीका है और कौन «अभी चलता है पर नए code के लिए नहीं चुनना» — यह साफ नहीं। वास्तव में Get-WmiObject PowerShell 7 में है ही नहीं, और 5.1 के लिए लिखा internal script migrate करते यह अचानक सतह पर आता है।

यह लेख उन C#/PowerShell developers के लिए है जो business apps में hardware जानकारी प्राप्ति, process monitoring और remote PC query लागू करते हैं। WMI/CIM की संरचना की minimum समझ से PowerShell के CIM cmdlets, C# के दो API, अक्सर काम आने वाली recipes, performance・rights・64-bit के pitfalls, और अंत में «जहाँ WMI उपयोग नहीं करना चाहिए» का निर्णय — August 2026 तक के primary sources पर व्यवस्थित है।

1. पहले निष्कर्ष

• CIM DMTF का management जानकारी का industry standard है, और WMI उसका Microsoft implementation। PowerShell और C# के CIM-परिवार API इस standard के वर्तमान पीढ़ी के API हैं, और जुड़ते वही underlying WMI से हैं।¹
• PowerShell में वर्तमान पीढ़ी CIM cmdlets हैं (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent)। पुराने WMI cmdlets (Get-WmiObject और चार अन्य) PowerShell 6 से हटा दिए गए हैं और PowerShell 7 में नहीं चलते।²
• Default namespace root/CIMV2 है, और रोज़ की query मूलतः वहाँ की Win32_* classes को WQL से छानना है।³
• Remote query का default WSMan (WinRM) है। -ComputerName देने से अस्थायी WSMan session बनता है। उसी target पर बार-बार query करें तो CIM session (New-CimSession) का reuse performance का established तरीका है, और पुराने target जहाँ WinRM configure न हो वहाँ DCOM protocol option है।³⁴
• C# में दो वंश हैं: System.Management (ManagementObjectSearcher) और Microsoft.Management.Infrastructure (CimSession)। दोनों केवल Windows हैं, और वर्तमान .NET पर NuGet से आते हैं। Remote query या monitoring को product में जोड़ रहे हों तो CIM cmdlets जैसा type तंत्र रखने वाला MI API बेहतर बैठता है।⁵⁶
• Process start होने का पता event subscription से लगाएँ, polling से नहीं। Win32_ProcessStartTrace की subscription admin rights से चलानी होती है।⁷⁸
• SELECT * आदत से न लिखें। -Filter / -Property / -KeyOnly से स्थानांतरित data छानना WMI के performance मुद्दों का लगभग आधा रोकता है।³
• WMI सार्वभौमिक हल नहीं। High-frequency performance monitoring, अपने app की settings पढ़ना-लिखना, या एकमुश्त OS function call के लिए performance counters, registry, Win32 API, या dedicated cmdlets बेहतर बैठते हैं (अध्याय 8 की decision table)।

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 26, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. WMI/CIM क्या है — Standard बनाम implementation, namespace, class और WQL

पहले शब्दावली एक बार साफ कर लें।

flowchart TB
    accTitle: CIM standard और WMI implementation का संबंध
    accDescr: DMTF तय और रखे CIM standard को WBEM पहल के ढाँचे में उपयोग करते हैं, उसका Microsoft implementation WMI है, अगली पीढ़ी MI पुराने WMI से पूर्ण compatible है, और CIM-परिवार API उसी WMI आधार से जुड़ते हैं
    dmtf["DMTF तय और रखता है"] --> cim["CIM（industry standard model）"]
    wbem["WBEM（industry पहल）"] --> wmi["WMI（Microsoft implementation）"]
    cim --> wmi
    wmi -.-> mi["MI（अगली पीढ़ी・पूर्ण compatible）"]
    api["CIM-परिवार API（PowerShell / C#）"] --> wmi

चित्र 2: CIM specification है, WMI Windows पर implementation। CIM-परिवार API उसी WMI आधार से जुड़ते हैं।

Developer के रूप में चार संरचनात्मक टुकड़े समझने लायक हैं।

• Namespace: Classes बाँधने वाला hierarchy। रोज़ की query में लगभग हमेशा root/CIMV2 उपयोग होता है, और CIM cmdlets का default भी यही है।³ अन्य में root\default (registry provider आदि) है।
• Class: Management target का प्रकार, जैसे Win32_ComputerSystem (computer स्वयं), Win32_LogicalDisk (logical drive), या Win32_Process (process)। CIM-standard classes (CIM_LogicalDisk आदि) से inheritance लेने वाली Windows-specific classes Win32_ prefix रखती हैं।⁹
• Provider: वह component जो class का पदार्थ देता है। Query करने पर provider वहीं OS से पूछकर मान बनाता है।
• WQL: SQL-जैसी query language। SELECT Name, State FROM Win32_Service WHERE StartMode = 'Auto' की तरह class को तालिका मानकर छानती है। CIM cmdlets की default query language भी WQL है।³

«OS और hardware की जानकारी एक समान class और query language से पढ़ना» — यही WMI का मूल्य है। उलटा, लिखना और operations उन कुछ classes तक सीमित है जिनके methods Invoke-CimMethod से बुलाए जा सकें; यह ऐसा mechanism नहीं जो सब कुछ कर सके।

flowchart TB
    accTitle: WMI query की संरचना
    accDescr: WQL query namespace root/CIMV2 की Win32_* classes की ओर जाती है, class का पदार्थ देने वाला provider वहीं OS से पूछकर मान बनाता है, और परिणाम लौटता है
    wql["WQL से query"] --> ns["Namespace root/CIMV2"]
    ns --> cls["Win32_* class"]
    cls --> prov["Provider"]
    prov --> osq["वहीं OS से पूछता है"]
    osq --> res["परिणाम लौटाता है"]

चित्र 3: Query namespace, class, provider के क्रम से चलती है, और मान वहीं बनते हैं।

3. PowerShell से उपयोग — CIM cmdlets वर्तमान हैं, WMI cmdlets हटाए गए हैं

3.1. मूल बात: Get-CimInstance

# Class नाम से (default namespace root/CIMV2)
Get-CimInstance -ClassName Win32_OperatingSystem

# WHERE खंड की सामग्री ही -Filter में लिखें (WHERE शब्द स्वयं न लिखें)
Get-CimInstance -ClassName Win32_Service -Filter "StartMode = 'Auto' AND State <> 'Running'"

# केवल आवश्यक properties लेकर स्थानांतरित मात्रा घटाएँ
Get-CimInstance -ClassName Win32_Process -Property Name, ProcessId, CreationDate

# कच्चा WQL लिखना हो तो -Query
Get-CimInstance -Query "SELECT * FROM Win32_Process WHERE Name LIKE 'p%'"

-Filter ठीक WQL का WHERE खंड है, और -Property प्राप्त columns सीमित करता है।³ लौटा मान CimInstance object है, और date properties (CreationDate या LastBootUpTime आदि) पहले से DateTime में convert लौटते हैं। पुराने Get-WmiObject से भिन्न, प्राप्त object पर methods सीधे नहीं होते, इसलिए method call Invoke-CimMethod को pipe करके करते हैं।

flowchart TB
    accTitle: CimInstance पर method call
    accDescr: Get-CimInstance का CimInstance date properties DateTime में convert लौटाता है पर methods सीधे नहीं रखता, इसलिए method call instance को Invoke-CimMethod को देकर करते हैं
    gci["Get-CimInstance"] --> inst["CimInstance object"]
    inst -.-> dt["Dates DateTime में convert"]
    inst -.-> nom["Methods सीधे नहीं होते"]
    inst --> icm["Invoke-CimMethod को दें"]
    icm --> call["Method call"]

चित्र 4: CimInstance पर methods सीधे नहीं होते, इसलिए method call Invoke-CimMethod को देकर करते हैं।

# Instance के methods बुलाना: प्रत्येक process का owner प्राप्त करें
Get-CimInstance -ClassName Win32_Process -Filter "Name = 'notepad.exe'" |
    Invoke-CimMethod -MethodName GetOwner

# Class का static method बुलाना: process शुरू करें
Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{ CommandLine = 'notepad.exe' }

# Class definition जाँचें (properties और methods)
Get-CimClass -ClassName Win32_Process

3.2. पुराने WMI cmdlets से migration तालिका

PowerShell 6 से आगे (वर्तमान PowerShell 7 सहित) निम्न WMI v1 cmdlets हटा दिए गए हैं। वही कार्य CimCmdlets module (WMI v2) देता है।²

Windows PowerShell 5.1 पर भी CIM cmdlets चलते हैं, इसलिए अब जो लिखें, 5.1 पर चलाना हो तब भी CIM पक्ष पर लिखें — इससे migration cost पीछे नहीं रहती। 5.1 और 7 के सह-अस्तित्व व migration का पूरा चित्र «Windows PowerShell 5.1 और PowerShell 7 के अंतर» में है।

flowchart TB
    accTitle: नया script CIM में लिखने का कारण
    accDescr: WMI cmdlets से लिखा script 5.1 पर चलता है पर PowerShell 6 से हटाया जा चुका है इसलिए migration पर दोबारा लिखना पड़ता है, CIM cmdlets 5.1 पर भी चलते हैं इसलिए नया CIM पक्ष पर लिखें तो migration cost नहीं रहती
    new["नया script लिख रहे हैं"] --> q1{"किसमें लिखें?"}
    q1 -->|WMI cmdlets| old["5.1 पर चलता है"]
    q1 -->|CIM cmdlets| cur["5.1 पर भी चलता है"]
    old --> del["PowerShell 7 में हटाए गए"]
    del --> rew["Migration पर दोबारा लिखना"]
    cur --> norew["Migration cost नहीं रहती"]

चित्र 5: नया CIM cmdlets से लिखें तो PowerShell 7 migration पर दोबारा लिखना नहीं पड़ता।

4. Remote query — CIM session (default WSMan) और DCOM option

CIM cmdlets, target न दें तो local WMI से COM पर जुड़ते हैं; -ComputerName दें तो WSMan (WinRM) protocol पर अस्थायी session बनाकर जुड़ते हैं। उसी computer पर कई operations करने हों तो CIM session बनाकर उसका reuse performance के लिए बेहतर है।³

flowchart TB
    accTitle: CIM connection तरीके का चुनाव
    accDescr: Specified न हो तो local WMI से COM connection, ComputerName देने पर हर query पर WSMan अस्थायी session बनता है, उसी target पर कई operations के लिए New-CimSession का reuse performance में लाभदायक है, और WinRM बिना target के लिए DCOM protocol option है
    exec["CIM cmdlets चलाएँ"] --> q1{"ComputerName दिया?"}
    q1 -->|नहीं| local["Local WMI से COM connection"]
    q1 -->|हाँ| q2{"उसी target पर कई operations?"}
    q2 -->|एक बार| temp["WSMan अस्थायी session"]
    q2 -->|कई| sess["New-CimSession reuse"]
    temp -.-> cost["हर query पर बनता है"]
    nowinrm["WinRM बिना target"] -.-> dcom["DCOM protocol option"]

चित्र 6: Remote query का default WSMan है, और उसी target पर कई operations के लिए CIM session का reuse established तरीका है।

# एक बार की query के लिए -ComputerName (हर बार अस्थायी session बनता है)
Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName Server01, Server02

# बार-बार query हो तो CIM session reuse करें
$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

जिन targets तक WSMan से न पहुँच सकें — जैसे पुरानी machine जहाँ WinRM configure न हो — वहाँ DCOM protocol चुन सकते हैं।⁴

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

Remote query की पूर्वापेक्षाएँ निम्न हैं।

• Target पर WinRM configure होना चाहिए। winrm quickconfig service को automatic start करता है, HTTP listener (default port 5985) बनाता है, और firewall exception register करता है — सब एक साथ।¹⁰ HTTPS (default port 5986) से जुड़ना हो तो अकेले यह काफी नहीं — server certificate तैयार कर winrm quickconfig -transport:https जैसे से HTTPS listener अलग configure करना पड़ता है।¹⁰
• मार्ग के firewall पर संबंधित ports खुले हों। Inbound rules design और register करने का practical काम «Windows firewall और business apps» लेख में है।
• Authentication। Domain environment में Kerberos mutual authentication देता है। Workgroup में Kerberos नहीं होता, इसलिए client की TrustedHosts सूची में target register करना पड़ सकता है। वह सूची यथासंभव संकीर्ण रखें।¹⁰
• Rights। Default configuration में remote WMI query और operations मूलतः target के Administrators group वाले account से होते हैं। सामान्य users के लिए खोलना हो तो WinRM और WMI namespace दोनों पर पहुँच permission configure करनी पड़ती है।¹⁰
• ध्यान दें कि DCOM का कोई स्थिर प्रतीक्षा port नहीं (RPC के dynamic ports उपयोग होते हैं), इसलिए firewall पार design कठिन हो जाता है। अब जो mechanism बनाएँ उसके लिए WSMan को default मानना सुरक्षित है।

flowchart TB
    accTitle: Remote query की पूर्वापेक्षा जाँचना
    accDescr: Target पर winrm quickconfig service automatic start, HTTP listener बनाना और firewall exception registration एक साथ करता है, HTTPS listener certificate तैयार कर अलग configure होता है, और workgroup में TrustedHosts registration आवश्यक हो सकता है
    qc["winrm quickconfig"] --> svc["Service automatic start"]
    qc --> lis["HTTP listener बनाना（5985）"]
    qc --> fw["Firewall exception"]
    lis ~~~ https["HTTPS listener（5986）"]
    https -.-> cert["Certificate तैयार कर अलग configure"]
    fw ~~~ wg["Workgroup environment"]
    wg -.-> th["TrustedHosts में registration"]

चित्र 7: winrm quickconfig default configuration एक साथ करता है, HTTPS listener और workgroup authentication अलग सँभालने पड़ते हैं।

5. C# से उपयोग — System.Management और Microsoft.Management.Infrastructure

C# से WMI के API दो वंश हैं। दोनों केवल Windows हैं।

5.1. System.Management: ManagementObjectSearcher की मूल बातें

WQL string के रूप में देते हैं और Get() से परिणाम संग्रह पाते हैं।⁵

// NuGet: System.Management (केवल 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"]} खाली {freeGb:F1} GB / कुल {sizeGb:F1} GB");
}

Properties indexer से object के रूप में लौटते हैं, इसलिए class documentation में CIM type जाँचें (इस उदाहरण में FreeSpace / Size uint64 हैं⁹) और तदनुसार cast करें। इसे int मानकर cast करना, जिससे InvalidCastException आए, यहाँ का classic पहला ठोकर है।

flowchart TB
    accTitle: Property प्राप्ति और cast का pitfall
    accDescr: System.Management के properties indexer से object के रूप में लौटते हैं इसलिए class documentation में CIM type जाँचकर cast करना पड़ता है, int मानकर cast करें तो InvalidCastException आता है
    idx["Indexer से प्राप्त"] --> obj["object के रूप में लौटता है"]
    obj --> chk["Documentation में CIM type जाँचें"]
    chk --> cast["सही type में cast"]
    obj -.-> wrong["int मानकर cast"]
    wrong -.-> ex["InvalidCastException"]

चित्र 8: Properties object के रूप में लौटते हैं, इसलिए cast से पहले CIM type जाँचें।

5.2. MI API: CimSession की मूल बातें

CimSession local और remote पहुँच एक ही आकार में सँभालता है। Enumeration, query, method call, event subscription और async form सब एक जगह हैं।⁶

// NuGet: Microsoft.Management.Infrastructure (केवल Windows)
using Microsoft.Management.Infrastructure;

// Local के लिए CimSession.Create(null), remote के लिए computer नाम दें
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} खाली {free / 1024.0 / 1024 / 1024:F1} GB");
}

क्योंकि यह वही CimInstance सँभालता है जो PowerShell के CIM cmdlets लौटाते हैं, «पहले PowerShell में आज़माएँ, फिर C# में उतारें» वाला development flow सहज जुड़ता है। C# और PowerShell के एकीकरण को स्वयं design कर रहे हों तो «C# (CSharp) से PowerShell चलाकर परिणाम object के रूप में पाना» भी देखें।

flowchart TB
    accTitle: PowerShell में आज़माकर C# में उतारने का flow
    accDescr: PowerShell के CIM cmdlets और C# का MI API वही CimInstance type सँभालते हैं, इसलिए PowerShell में prototype कर C# में उतारने का development flow सहज जुड़ता है
    trial["PowerShell में prototype"] --> gci["CIM cmdlets"]
    impl["C# में वास्तविक implementation"] --> mi["MI API"]
    gci --> ci["वही CimInstance type"]
    mi --> ci
    ci -.-> flow["उतारना सहज जुड़ता है"]

चित्र 9: CIM cmdlets और MI API वही CimInstance type सँभालते हैं, इसलिए prototype से वास्तविक implementation तक जुड़ता है।

6. अक्सर काम आने वाली recipes

6.1. आम classes की त्वरित तालिका

6.2. संपत्ति management का आम काम: Serial number, model नाम और disk खाली स्थान

# Model जानकारी और serial number (PC asset register से मिलान के लिए)
$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
}

# Local disk (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 «local disk» का मान है, और removable (2), network drive (4), तथा CD (5) हटाता है।⁹ Monitoring के लिए यही script CIM session से प्रत्येक server पर घुमाना agent-less disk monitoring की नींव देता है।

flowchart TB
    accTitle: Agent-less disk monitoring की नींव
    accDescr: DriveType 3 से छानकर removable, network drive और CD हटा local disk ही target बनाते हैं, और वही script CIM session से प्रत्येक server पर घुमाने से agent-less disk monitoring की नींव बनती है
    scr["खाली स्थान प्राप्ति script"] --> flt["DriveType = 3 से छानें"]
    flt -.-> exc["Removable आदि हटाएँ"]
    scr --> ses["CIM session के ज़रिए"]
    ses --> srvs["प्रत्येक server पर घुमाएँ"]
    srvs --> mon["Agent-less monitoring"]

चित्र 10: Local disk तक छानी script CIM session से प्रत्येक server पर घुमाना monitoring की नींव है।

6.3. Process start होने का पता — Event subscription

«Polling से Win32_Process समय-समय पर लाकर अंतर देखना» के बजाय event subscription लें। Process start पकड़ने का सरल तरीका Win32_ProcessStartTrace की subscription है (kernel trace provider की event class, properties ProcessName / ProcessID / ParentProcessID आदि⁸)।

# Admin (elevated) PowerShell session से चलाएँ
$action = {
    $name = $Event.SourceEventArgs.NewEvent.ProcessName
    $id   = $Event.SourceEventArgs.NewEvent.ProcessID
    Write-Host "Process start: $name (PID=$id)"
}
Register-CimIndicationEvent -ClassName Win32_ProcessStartTrace `
    -SourceIdentifier ProcessStarted -Action $action

Subscription उस PowerShell session के जीवित रहने तक चालू रहती है जिसने उसे register किया, और हर process start पर -Action चलता है। Subscription-हटाने का आदेश इसके तुरंत बाद उसी batch में न चलाएँ — ऐसा करने से monitoring शुरू होने से पहले subscription गायब हो जाती है। हटाना monitoring समाप्त करते समय चलाएँ।

# Monitoring समाप्त करते समय: subscription हटाएँ
Unregister-Event -SourceIdentifier ProcessStarted

Register-CimIndicationEvent class नाम या WQL event query से subscription register करता है, और -Action script block हर आगमन पर चलता है।⁷ इस class की subscription के लिए admin rights आवश्यक हैं।⁷ Event कौन प्राप्त कर सकता है यह event class के security descriptor से नियंत्रित है, और बिना elevated rights के सामान्य user को पहुँच denied होती है।⁸

sequenceDiagram
    accTitle: Process-start event subscription का flow
    accDescr: Admin rights वाले PowerShell session में Register-CimIndicationEvent subscription register करता है, हर process start पर event आता है और Action चलता है, monitoring समाप्त करते Unregister-Event से हटाते हैं
    participant ps as PowerShell session
    participant wmi as WMI
    ps->>wmi: Register-CimIndicationEvent से subscription registration
    Note over ps: Admin rights से चलाएँ
    wmi-->>ps: हर process start पर event आता है
    ps->>ps: -Action चलाएँ
    ps->>wmi: Unregister-Event से हटाएँ（monitoring समाप्त पर）

चित्र 11: Subscription register सत्र के जीवित रहने तक चालू रहती है, और हटाना monitoring समाप्त करते समय करते हैं।

दूसरा तरीका किसी भी class पर चलने वाला सामान्य instance-creation event (__InstanceCreationEvent) है। यहाँ WMI WITHIN से दिया interval पर polling कर अंतर को event बनाता है, इसलिए पता लगाने के interval और भार का समझौता स्वयं तय करना पड़ता है।

flowchart TB
    accTitle: Process start पकड़ने के दो subscription तरीके
    accDescr: Win32_ProcessStartTrace kernel trace provider की event class की subscription है, सामान्य __InstanceCreationEvent में WMI WITHIN दिए interval पर polling कर अंतर को event बनाता है इसलिए पता interval और भार का समझौता स्वयं तय करते हैं
    goal["Process start होने का पता"] --> t1["Win32_ProcessStartTrace"]
    goal --> t2["__InstanceCreationEvent"]
    t1 -.-> k1["Kernel trace की subscription"]
    t2 -.-> w1["WITHIN interval पर polling"]
    w1 -.-> tr["Interval और भार का समझौता"]

चित्र 12: Dedicated event class की subscription लें, या polling interval सहित सामान्य instance-creation event उपयोग करें।

# 5 सेकंड interval की polling से Win32_Process के नए instances की monitoring
$query = "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_Process'"
Register-CimIndicationEvent -Query $query -SourceIdentifier ProcPoll -Action {
    Write-Host "Start: $($Event.SourceEventArgs.NewEvent.TargetInstance.Name)"
}

C# (System.Management) में ManagementEventWatcher वही भूमिका निभाता है।¹¹

using System.Management;

// Administrator के रूप में चल रहे process में
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($"Process start: {name} (PID={pid})");
};
watcher.Start();
// Monitoring समाप्त पर watcher.Stop() और Dispose न भूलें

स्थायी monitoring में जोड़ते समय, subscription टूटने पर फिर registration (service फिर start पर・error पर) तक design में शामिल करें। Device monitoring सहित «अवस्था जाँचना और दिखाना» का design «बाहरी उपकरणों की अवस्था जाँचने और दिखाने की सर्वोत्तम प्रथाएँ» में है।

stateDiagram-v2
    accTitle: स्थायी monitoring की subscription lifecycle
    accDescr: स्थायी monitoring में subscription चालू अवस्था service फिर start या error से टूट सकती है, इसलिए टूटना पकड़कर फिर registration कर subscription चालू पर लौटाने तक design में शामिल करें
    s1: Subscription चालू
    s2: Subscription टूटी अवस्था
    s3: फिर registration
    [*] --> s1
    s1 --> s2: Service फिर start・error
    s2 --> s3
    s3 --> s1

चित्र 13: स्थायी monitoring में, subscription टूटने पर फिर registration कर subscription चालू पर लौटाने तक design शामिल करें।

7. Pitfalls — Performance, rights, 64-bit, repository और dates

7.1. SELECT * और polling की अधिकता

WMI query «provider वहीं मान बनाता है» वाला काम है — मुफ़्त नहीं। दो classic anti-patterns हैं।

• SELECT * की आदत। Win32_Process के हर property की हर पंक्ति लें तो provider का काम और network transfer (remote पर) उसी अनुपात में बढ़ता है। पंक्तियाँ -Filter से, columns -Property से छानें, और आगे के operations के लिए केवल key चाहिए तो -KeyOnly उपयोग करें। ये सभी «object आकार और network traffic घटाने» के आधिकारिक साधन हैं।³
• कम interval polling। «हर सेकंड Get-CimInstance Win32_Process» जैसा design अध्याय 6.3 की event subscription से बदलें। Polling रूप (WITHIN) लेना ही पड़े तो interval आवश्यकता के लिए यथेष्ट तक बढ़ाएँ।

साथ ही, remote पर एक-एक target -ComputerName से दोहराना भी बहुत व्यर्थ है। हर query पर अस्थायी session बनता है, इसलिए कई operations CIM session के reuse पर ले जाएँ।³

flowchart TB
    accTitle: Performance anti-patterns और उनके स्थान
    accDescr: SELECT तारांकन की आदत Filter और Property से पंक्ति और column छानकर केवल key हो तो KeyOnly से बदलें, कम interval polling event subscription से, एक-एक ComputerName दोहराना CIM session reuse से बदलें
    a1["SELECT * की आदत"] --> f1["Filter और Property से छानें"]
    f1 -.-> f2["केवल key हो तो KeyOnly"]
    a2["कम interval polling"] --> f3["Event subscription से बदलें"]
    a3["एक-एक ComputerName"] --> f4["CIM session reuse"]

चित्र 14: पंक्ति・column・key छानना और event subscription पर जाना WMI के performance मुद्दों का लगभग आधा रोकता है।

7.2. Event subscription के rights

अध्याय 6.3 के अनुसार, Win32_ProcessStartTrace परिवार की subscription admin rights मानती है।⁷ «Development machine (admin से चला) पर चला, पर ग्राहक के सामान्य-user environment में monitoring नहीं चलती» firewall सूचना dialog के साथ classic दुर्घटना है। सामान्य user से चलने वाले business app में monitoring जोड़ें तो monitoring भाग Windows service (LocalSystem आदि) में अलग करें, और app मुख्य भाग से inter-process communication से जोड़ने का ढाँचा सोचें।

flowchart TB
    accTitle: सामान्य-user environment में monitoring ढाँचा
    accDescr: Admin rights वाली subscription सामान्य user से चलने वाले app मुख्य भाग से काटें, monitoring LocalSystem आदि से चलने वाली Windows service में अलग करें, और app मुख्य भाग से inter-process communication से जोड़ें
    svcm["Monitoring Windows service"] --> subm["Start trace की subscription"]
    svcm -.-> lsm["LocalSystem आदि से चलाएँ"]
    appm["App मुख्य भाग（सामान्य user）"] ---|Inter-process communication| svcm

चित्र 15: Admin rights वाली subscription service पक्ष पर अलग करें, और app मुख्य भाग से inter-process communication से जोड़ें।

7.3. 32-bit/64-bit और provider

64-bit Windows पर कुछ providers 32-bit और 64-bit दोनों रूप में साथ रहते हैं, और default से caller app की bit संख्या से मेल खाने वाला पक्ष उत्तर देता है।¹² Classic उदाहरण root\default का registry provider (StdRegProv) है: 32-bit app से पढ़ने पर Wow6432Node पक्ष (32-bit view) के मान लौटते हैं।¹² «WMI से पढ़ा registry मान regedit में दिखे मान से भिन्न है» हो तो पहले यही संदेह करें। दूसरा view चाहिए तो connection context में __ProviderArchitecture (और बाध्य करना हो तो __RequiredArchitecture) देकर स्पष्ट माँग सकते हैं।¹² Bit-संख्या समस्या का पूरा चित्र «C# से Win32 API सुरक्षित बुलाना — P/Invoke practical guide» में भी है।

flowchart TB
    accTitle: 64-bit environment में provider चुनाव
    accDescr: Default से caller app की bit संख्या से मेल खाने वाला provider उत्तर देता है, 32-bit app की registry query Wow6432Node पक्ष का मान पाती है, पर __ProviderArchitecture से उलटा view स्पष्ट माँग सकते हैं
    q1{"Caller की bit संख्या?"} -->|32-bit| p32["32-bit provider उत्तर देता है"]
    q1 -->|64-bit| p64["64-bit provider उत्तर देता है"]
    p32 -.-> wow["Registry Wow6432Node पक्ष का मान"]
    ctx["__ProviderArchitecture specified"] -.-> ov["उलटा view स्पष्ट माँगें"]

चित्र 16: Default से caller की bit संख्या से मेल खाने वाला पक्ष उत्तर देता है, इसलिए 32-bit app Wow6432Node पक्ष पढ़ता है।

7.4. WMI repository क्षति के लक्षण और उपाय

WMI की class definitions repository में stored हैं (एक file नहीं — Repository folder की files मिलकर database का काम करती हैं¹³)। Inconsistency हो तो «जो class होनी चाहिए वह नहीं मिलती» या «namespace invalid है» जैसी errors app पक्ष कुछ बदले बिना शुरू हो जाती हैं। Diagnostics और मरम्मत के लिए winmgmt.exe उपयोग करें।¹³

rem Consistency जाँच (परिणाम inconsistent हो तो inconsistency है)
winmgmt /verifyrepository

rem Consistency जाँच + inconsistency हो तो rebuild (पढ़ने योग्य सामग्री merge होती है)
winmgmt /salvagerepository

ध्यान यह है कि repository delete करना या initialize करना पहला कदम न बनाएँ। WMI से आने वाली error OS के अन्य भाग से भी हो सकती है, और Microsoft स्पष्ट कहता है कि repository delete करना पहला उपाय बनाने से «system या स्थापित apps को क्षति पहुँच सकती है»।¹³ क्रम रखें: /verifyrepository से जाँच → /salvagerepository से मरम्मत।

flowchart TB
    accTitle: WMI repository inconsistency छाँटने की प्रक्रिया
    accDescr: Class नहीं मिलती जैसी error आए तो winmgmt के verifyrepository से consistency जाँचें, inconsistency हो तो salvagerepository से rebuild करें, और repository delete करना या initialize करना पहला कदम न बनाएँ
    sym["Class नहीं मिलती आदि error"] --> verify["winmgmt /verifyrepository"]
    verify --> q1{"परिणाम inconsistent?"}
    q1 -->|हाँ| salvage["winmgmt /salvagerepository"]
    q1 -->|नहीं| other["OS के अन्य भाग का कारण सोचें"]
    salvage -.-> merge["पढ़ने योग्य सामग्री merge होती है"]
    del["Repository delete・initialize करना"] -.-> ng["पहला कदम न बनाएँ"]

चित्र 17: verify से जाँचकर salvage से मरम्मत का क्रम रखें, delete करना पहला कदम न बनाएँ।

7.5. DMTF date रूप का conversion

WMI dates CIM specification के DMTF रूप yyyymmddHHMMSS.mmmmmm±UUU (अंत UTC से मिनटों में offset। उदाहरण: 20260801100000.000000+540) की string में stored हैं। कच्चे मान को string processing से काट-छाँटना बंद करें; conversion API उपयोग करें।

• C# (System.Management): ManagementDateTimeConverter DMTF रूप और DateTime / TimeSpan का पारस्परिक conversion देता है।¹¹
• CIM-परिवार API (Get-CimInstance / MI API): Date properties पहले से DateTime में convert लौटते हैं, इसलिए यह समस्या उठती ही नहीं। (Get-CimInstance Win32_OperatingSystem).LastBootUpTime सीधे DateTime के रूप में गणना में उपयोग हो सकता है।

flowchart TB
    accTitle: DMTF date रूप का व्यवहार
    accDescr: WMI dates DMTF रूप की string में stored हैं, System.Management से कच्चा मान पढ़ें तो ManagementDateTimeConverter से convert करें, CIM-परिवार API DateTime में पहले से convert लौटाता है, इसलिए खुद string काट-छाँट न करें
    dmtf["DMTF रूप की string"] --> q1{"किस API से प्राप्त?"}
    q1 -->|System.Management| conv["ManagementDateTimeConverter"]
    q1 -->|CIM-परिवार API| done["DateTime में पहले से convert"]
    conv --> dtv["DateTime / TimeSpan में conversion"]
    cut["खुद string काट-छाँट"] -.-> ng["उपयोग न करें"]

चित्र 18: DMTF string का conversion conversion API पर छोड़ें, CIM-परिवार API हो तो convert DateTime ज्यों का त्यों उपयोग करें।

8. जहाँ WMI उपयोग नहीं करना चाहिए — साधन की decision table

WMI «एक समान पढ़ने का मुख» के रूप में उत्तम है, पर हमेशा सर्वोत्तम हल नहीं। Practical चुनाव का अनुमान यह है।

निर्णय की धुरी सरल है: «जहाँ dedicated mechanism है वहाँ dedicated mechanism उपयोग करें, cross-cutting query और remote query के लिए WMI/CIM रखें»। अंतिम पंक्ति का Get-NetFirewallRule आदि internal रूप से CIM पर बने cmdlet समूह हैं — «WMI/CIM को सीधे छुए बिना केवल उसका लाभ लेना» वाला रूप।

flowchart TB
    accTitle: साधन निर्णय की धुरी
    accDescr: जहाँ dedicated mechanism है वहाँ dedicated mechanism उपयोग करें, जहाँ नहीं वहाँ cross-cutting query और remote query के लिए WMI और CIM उपयोग करना निर्णय की धुरी है, और dedicated CIM-based cmdlets WMI और CIM को सीधे छुए बिना केवल लाभ लेने का रूप हैं
    q1{"Dedicated mechanism है?"} -->|है| ded["Dedicated mechanism उपयोग करें"]
    q1 -->|नहीं| wmi["WMI / CIM उपयोग करें"]
    wmi -.-> use["Cross-cutting query・remote query"]
    cmd["Dedicated CIM-based cmdlets"] -.-> ben["केवल लाभ लेने का रूप"]

चित्र 19: जहाँ dedicated mechanism है वहाँ dedicated उपयोग करें, cross-cutting query और remote query के लिए WMI/CIM रखें।

9. सारांश

• CIM DMTF का industry standard है, WMI उसका Microsoft implementation। PowerShell के CIM cmdlets और C# का MI API दोनों इस standard के वर्तमान पीढ़ी के प्रवेश हैं।
• PowerShell में Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent वर्तमान हैं। Get-WmiObject जैसे WMI cmdlets PowerShell 7 में नहीं हैं, इसलिए नया script 5.1 के लिए हो तब भी CIM पक्ष पर लिखें।
• Remote query का default WSMan (WinRM) है, और कई operations CIM session का reuse करें। WinRM बिना target के लिए DCOM option बच निकलने का मार्ग है।
• C# में System.Management (सहज, local-उन्मुख) और Microsoft.Management.Infrastructure (remote・monitoring-उन्मुख, CIM cmdlets जैसा type तंत्र) में से चुनें। दोनों केवल-Windows NuGet packages हैं।
• Process monitoring polling नहीं, event subscription से। Win32_ProcessStartTrace की subscription के लिए admin rights आवश्यक हैं।
• SELECT * और कम interval polling से बचें, -Filter / -Property / -KeyOnly से छानें। 32-bit process की query 32-bit provider की ओर जाती है, DMTF date conversion API से बदलें, repository क्षति हटाने से नहीं verify → salvage के क्रम से सँभालें — यह याद रखें।
• जहाँ dedicated mechanism है (settings, performance counters, एकमुश्त API call) वहाँ WMI न लाएँ, cross-cutting query और remote query के लिए WMI/CIM उपयोग करें — यही उपयोग की एक पंक्ति है।

संबंधित लेख

• C# (CSharp) से PowerShell चलाकर परिणाम object के रूप में पाना
• PowerShell practical command recipes — रोज़ के छोटे औज़ार बढ़ाना
• Windows PowerShell 5.1 और PowerShell 7 के अंतर — Internal script migration की practical guide
• बाहरी उपकरणों की अवस्था जाँचने और दिखाने की सर्वोत्तम प्रथाएँ - केवल «connected» पर न रुकने वाला design
• C# से Win32 API सुरक्षित बुलाना — P/Invoke practical guide (DllImport / LibraryImport / CsWin32)
• Windows में TPM क्या है — «key बाहर न निकलने वाला तिजोरी» और measured boot का चित्रण

संबंधित परामर्श क्षेत्र

KomuraSoft LLC WMI/CIM से hardware जानकारी प्राप्ति, process monitoring और remote PC query को business apps में जोड़ने, Get-WmiObject पर आधारित internal scripts को CIM cmdlets पर migrate करने, और «development machine पर चलता है पर ग्राहक स्थल पर rights error आती है» जैसी समस्याओं की जाँच सँभालता है। PowerShell में prototype से C# में वास्तविक implementation तक एक ही धारा में परामर्श ले सकते हैं।

• Windows app development
• बग और कारणों की जाँच
• Technical consulting और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

WMI और CIM में क्या अंतर है?

CIM वह industry-standard model है जिससे systems और devices जैसे management targets को व्यक्त किया जाता है, और इसे DMTF (Distributed Management Task Force) तय और रखता है। WMI उस standard का उपयोग करने वाली WBEM पहल का Microsoft implementation है, और वह Windows में बना होता है। अर्थात CIM specification है, WMI Windows पर implementation। PowerShell का Get-CimInstance और C# का Microsoft.Management.Infrastructure स्वयं को CIM कहते हैं क्योंकि वे इस standard के API हैं, पर जुड़ते वही underlying WMI से हैं। रोज़ के development में इतना काफी है कि WMI classes (Win32_* आदि) को CIM-परिवार API से query करते हैं।

क्या Get-WmiObject अब उपयोग नहीं हो सकता?

Windows PowerShell 5.1 में अभी चलता है, पर PowerShell 6 से आगे (वर्तमान PowerShell 7 सहित) WMI v1 cmdlets — Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Set-WmiInstance, और Remove-WmiObject — हटा दिए गए हैं और चल नहीं सकते। वही कार्य CimCmdlets module (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent आदि) देता है। नए scripts लिखते समय, 5.1 पर चलाने हों तब भी CIM cmdlets से लिखना सुरक्षित है। ऐसा करने पर बाद में PowerShell 7 पर migrate करते WMI भाग दोबारा नहीं लिखना पड़ता।

C# से WMI के लिए System.Management लें या Microsoft.Management.Infrastructure?

दोनों केवल Windows हैं, और वर्तमान .NET से NuGet package के रूप में आते हैं। System.Management classic API है — ManagementObjectSearcher को WQL दे देना काफी है — और local जानकारी लेना मुख्य काम हो तो अकेले पर्याप्त है। DMTF dates बदलने वाला ManagementDateTimeConverter भी इसी में है। दूसरी ओर Microsoft.Management.Infrastructure (MI API) PowerShell के CIM cmdlets जैसा ही type तंत्र (CimSession / CimInstance) रखता है, और WSMan पर remote query, async methods, और event subscription (Subscribe) एक ही ढाँचे में सँभालता है। Remote PC query और monitoring को product में सचमुच जोड़ रहे हों तो MI API चुनना तर्कसंगत है।

Get-CimInstance remote PC से जुड़ता नहीं। क्या जाँचें?

पहले target machine पर WinRM configure है या नहीं जाँचें। -ComputerName वाला CIM operation WSMan (WinRM) protocol पर अस्थायी session बनाता है, इसलिए target पर WinRM service और listener चलना पूर्वापेक्षा है। winrm quickconfig default configuration (service शुरू करना, listener बनाना, firewall exception) एक साथ करता है। Default ports HTTP 5985 और HTTPS 5986 हैं, इसलिए मार्ग के firewall भी देखें। Workgroup में Kerberos से mutual authentication नहीं होता, इसलिए client की TrustedHosts सूची में target register करना पड़ सकता है। जिस target पर WinRM बिलकुल configure न कर सकें, वहाँ New-CimSessionOption -Protocol Dcom से बना option लेकर DCOM पर जुड़ सकते हैं।

WMI date 20260801100000.000000+540 जैसे रूप में क्यों लौटती है?

WMI dates DMTF CIM specification की string रूप (yyyymmddHHMMSS.mmmmmm±UUU, अंत UTC से मिनटों में offset) में stored होती हैं। पुराने Get-WmiObject या System.Management से कच्चा मान पढ़ें तो यही string ज्यों की त्यों मिलती है। C# (System.Management) में ManagementDateTimeConverter DMTF रूप और DateTime / TimeSpan के बीच conversion देता है, इसलिए string खुद काट-छाँटने के बजाय उसे उपयोग करें। ध्यान दें कि Get-CimInstance जैसे CIM-परिवार API से लेने पर date properties पहले से DateTime में convert लौटते हैं, इसलिए यह समस्या उठती ही नहीं।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।