C# ও PowerShell থেকে WMI/CIM ব্যবহার — হার্ডওয়্যার তথ্য, প্রক্রিয়া নজরদারি ও দূরবর্তী অনুসন্ধানের বাস্তব নির্দেশিকা

«PC-র সিরিয়াল নম্বর ও মডেল নাম ব্যবসায়িক অ্যাপের স্ক্রিনে দেখাতে চাই।» «সার্ভারের ডিস্কের খালি জায়গা নজরদারি করে সতর্কতা দিতে চাই।» «নির্দিষ্ট প্রক্রিয়া চালু হলে ধরতে চাই।» «দূরের PC-গুলোর অবস্থা এক জায়গায় জানতে চাই।» — Windows ব্যবসায়িক অ্যাপ ও ব্যবস্থাপনা টুল গড়তে এ ধরনের চাহিদা নিয়মিত ওঠে। আর তার নিয়মিত উত্তর WMI (Windows Management Instrumentation), স্ট্যান্ডার্ড নামে CIM (Common Information Model)।

flowchart TB
    accTitle: নিয়মিত চাহিদা ও WMI/CIM
    accDescr: সিরিয়াল নম্বর ও মডেল নাম দেখানো, ডিস্কের খালি জায়গা নজরদারি, প্রক্রিয়া চালু হওয়া শনাক্ত, দূরবর্তী PC অনুসন্ধান — ব্যবসায়িক অ্যাপের এই নিয়মিত চাহিদার নিয়মিত উত্তর WMI, স্ট্যান্ডার্ড নামে CIM
    r1["সিরিয়াল নম্বর ও মডেল"] --> ans["WMI (স্ট্যান্ডার্ড নাম CIM)"]
    r2["ডিস্ক খালি জায়গা নজরদারি"] --> ans
    r3["প্রক্রিয়া চালু হওয়া শনাক্ত"] --> ans
    r4["দূরবর্তী PC অনুসন্ধান"] --> ans

চিত্র 1: ব্যবসায়িক অ্যাপের নিয়মিত চার চাহিদার নিয়মিত উত্তরই WMI/CIM।

ঝামেলা এই যে WMI-র তথ্য পুরনো-নতুন মেশানো। খুঁজলে Get-WmiObject ব্যবহার করা দশ বছর আগের নিবন্ধ ও Get-CimInstance ব্যবহার করা নিবন্ধ পাশাপাশি থাকে, C# দিকেও System.Management আর Microsoft.Management.Infrastructure দুই ধারা। কোনটা বর্তমান লেখা, কোনটা «এখনও চলে কিন্তু নতুন কোডে নেবেন না» — সেটা বোঝা কঠিন। বাস্তবে Get-WmiObject PowerShell 7-এ নেইই, আর 5.1-এর জন্য লেখা ইন-হাউস স্ক্রিপ্ট মাইগ্রেট করতে হঠাৎ ধরা পড়ে।

এই নিবন্ধ লক্ষ্য করে সেই C#/PowerShell ডেভেলপারদের যারা ব্যবসায়িক অ্যাপে হার্ডওয়্যার তথ্য আনা, প্রক্রিয়া নজরদারি ও দূরবর্তী PC অনুসন্ধান বসান। WMI/CIM-এর গঠনের ন্যূনতম বোঝা থেকে PowerShell-এর CIM কমান্ডলেট, C#-এর দুই API, ঘন ঘন ব্যবহারের রেসিপি, কর্মক্ষমতা-অধিকার-64bit-এর ফাঁদ, আর «WMI ব্যবহার করা উচিত নয় এমন পরিস্থিতি» পর্যন্ত আগস্ট 2026-এর প্রাথমিক সূত্রে সাজায়।

1. আগে সিদ্ধান্ত

• CIM DMTF প্রণীত ব্যবস্থাপনা তথ্যের শিল্প স্ট্যান্ডার্ড, WMI তার Microsoft ইমপ্লিমেন্টেশন। PowerShell ও C#-এর «CIM»-পরিবার API এই স্ট্যান্ডার্ড মেনে চলা বর্তমান প্রজন্মের API, সংযোগ একই WMI ভিত্তিতে।¹
• PowerShell-এ বর্তমান প্রজন্ম CIM কমান্ডলেট (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent)। পুরনো WMI কমান্ডলেট (Get-WmiObjectসহ পাঁচটি) PowerShell 6 থেকে সরিয়ে ফেলা, PowerShell 7-এ চলে না।²
• ডিফল্ট নেমস্পেস root/CIMV2, আর দৈনন্দিন অনুসন্ধান মূলত সেখানকার Win32_* ক্লাস WQL দিয়ে সীমাবদ্ধ করা।³
• দূরবর্তী অনুসন্ধানের ডিফল্ট WSMan (WinRM)। -ComputerName দিলে WSMan-এর অস্থায়ী সেশন তৈরি হয়। একই লক্ষ্যে বারবার অনুসন্ধান করলে CIM সেশন (New-CimSession) পুনর্ব্যবহার কর্মক্ষমতার নিয়ম, আর WinRM কনফিগার করা যায় না এমন পুরনো লক্ষ্যে DCOM প্রোটোকল অপশন আছে।³⁴
• C#-এ দুই ধারা: System.Management (ManagementObjectSearcher) ও Microsoft.Management.Infrastructure (CimSession)। দুটোই কেবল Windows, বর্তমান .NET-এ NuGet থেকে আনেন। দূরবর্তী অনুসন্ধান বা নজরদারি পণ্যে বসালে CIM কমান্ডলেটের সঙ্গে একই টাইপ ব্যবস্থার MI API মানায়।⁵⁶
• প্রক্রিয়া চালু হওয়া শনাক্ত ইভেন্ট সাবস্ক্রিপশনে করুন, পোলিংয়ে নয়। Win32_ProcessStartTrace সাবস্ক্রাইব করতে প্রশাসক অধিকার লাগে।⁷⁸
• অভ্যাসে SELECT * ব্যবহার করবেন না। -Filter / -Property / -KeyOnly দিয়ে স্থানান্তর সীমাবদ্ধ করা WMI-এর কর্মক্ষমতা সমস্যার প্রায় অর্ধেক আটকায়।³
• WMI সর্বজনীন সমাধান নয়। উচ্চ-ঘনত্বের কর্মক্ষমতা নজরদারি, নিজের অ্যাপের সেটিং পড়া-লেখা, বা একবারের OS ফাংশন কলে পারফরম্যান্স কাউন্টার, রেজিস্ট্রি, Win32 API, বা নিবেদিত কমান্ডলেট মানায় (ধারা 8-এর সিদ্ধান্ত সারণি)।

2. WMI/CIM কী — স্ট্যান্ডার্ড ও ইমপ্লিমেন্টেশন, নেমস্পেস, ক্লাস, WQL

আগে পরিভাষা একবারে গুছিয়ে নিই।

flowchart TB
    accTitle: CIM স্ট্যান্ডার্ড ও WMI ইমপ্লিমেন্টেশনের সম্পর্ক
    accDescr: DMTF যে CIM স্ট্যান্ডার্ড প্রণয়ন ও রক্ষণাবেক্ষণ করে তা WBEM উদ্যোগের কাঠামোয় ব্যবহার হয়, তার Microsoft ইমপ্লিমেন্টেশন WMI, পরবর্তী প্রজন্মের MI পুরনো WMI-এর সঙ্গে পূর্ণ সামঞ্জস্যপূর্ণ, আর CIM-পরিবার API-এর সংযোগ একই WMI ভিত্তিতে
    dmtf["DMTF প্রণয়ন ও রক্ষণাবেক্ষণ"] --> cim["CIM (শিল্প স্ট্যান্ডার্ড মডেল)"]
    wbem["WBEM (শিল্প উদ্যোগ)"] --> wmi["WMI (Microsoft ইমপ্লিমেন্টেশন)"]
    cim --> wmi
    wmi -.-> mi["MI (পরবর্তী প্রজন্ম, পূর্ণ সামঞ্জস্য)"]
    api["CIM-পরিবার API (PowerShell / C#)"] --> wmi

চিত্র 2: CIM স্পেসিফিকেশন, WMI Windows-এর ইমপ্লিমেন্টেশন। CIM-পরিবার API-এর সংযোগ একই WMI ভিত্তিতে।

ডেভেলপার হিসেবে ধরে রাখার মতো গঠন চারটি।

• নেমস্পেস: ক্লাস গোছানো স্তর। দৈনন্দিন অনুসন্ধানে প্রায় সবসময় root/CIMV2, CIM কমান্ডলেটের ডিফল্টও এটা।³ অন্যগুলোর মধ্যে root\default (রেজিস্ট্রি প্রোভাইডার ইত্যাদি)।
• ক্লাস: ব্যবস্থাপনার লক্ষ্যের টাইপ, যেমন Win32_ComputerSystem (কম্পিউটার নিজে), Win32_LogicalDisk (লজিক্যাল ড্রাইভ), Win32_Process (প্রক্রিয়া)। CIM স্ট্যান্ডার্ড ক্লাস (CIM_LogicalDisk ইত্যাদি) থেকে উত্তরাধিকার নেওয়া Windows-নির্দিষ্ট ক্লাসের উপসর্গ Win32_।⁹
• প্রোভাইডার: ক্লাসের সত্তা জোগায় এমন উপাদান। অনুসন্ধান করলে প্রোভাইডার সেখানেই OS-কে জিজ্ঞাসা করে মান তৈরি করে।
• WQL: SQL-সদৃশ অনুসন্ধান ভাষা। SELECT Name, State FROM Win32_Service WHERE StartMode = 'Auto'-এর মতো ক্লাসকে টেবিল ধরে সীমাবদ্ধ করে। CIM কমান্ডলেটের ডিফল্ট অনুসন্ধান ভাষাও WQL।³

«OS ও হার্ডওয়্যার তথ্য একসেট ক্লাস ও কুয়েরি ভাষায় পড়া যায়» — এটাই WMI-এর মূল্য। উল্টোদিকে লেখা ও নিয়ন্ত্রণ কেবল সেই ক্লাসে সীমাবদ্ধ যাদের মেথড Invoke-CimMethod দিয়ে ডাকা যায়; যা-খুশি করার ব্যবস্থা নয়।

flowchart TB
    accTitle: WMI অনুসন্ধানের গঠন
    accDescr: WQL অনুসন্ধান নেমস্পেস root/CIMV2-এর Win32_* ক্লাসের দিকে যায়, ক্লাসের সত্তা জোগানো প্রোভাইডার সেখানেই OS-কে জিজ্ঞাসা করে মান তৈরি করে, ফলাফল ফেরে
    wql["WQL দিয়ে অনুসন্ধান"] --> ns["নেমস্পেস root/CIMV2"]
    ns --> cls["Win32_* ক্লাস"]
    cls --> prov["প্রোভাইডার"]
    prov --> osq["সেখানেই OS-কে জিজ্ঞাসা"]
    osq --> res["ফলাফল ফেরায়"]

চিত্র 3: অনুসন্ধান নেমস্পেস, ক্লাস, প্রোভাইডার ক্রমে যায়, আর মান সেখানেই তৈরি হয়।

3. PowerShell থেকে ব্যবহার — CIM কমান্ডলেট বর্তমান, WMI কমান্ডলেট সরানো

3.1. ভিত্তি Get-CimInstance

# ক্লাস নামে (ডিফল্ট নেমস্পেস root/CIMV2)
Get-CimInstance -ClassName Win32_OperatingSystem

# WHERE খণ্ডের বিষয়বস্তুই -Filter-এ লিখুন (WHERE শব্দ নিজে লিখবেন না)
Get-CimInstance -ClassName Win32_Service -Filter "StartMode = 'Auto' AND State <> 'Running'"

# শুধু দরকারি প্রপার্টি নিয়ে স্থানান্তর কমান
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 কোন কলাম আনবে তা সীমাবদ্ধ করে।³ ফেরত মান CimInstance অবজেক্ট, আর তারিখ প্রপার্টি (CreationDate বা LastBootUpTime ইত্যাদি) আগেই DateTime-এ রূপান্তরিত হয়ে ফেরে। পুরনো Get-WmiObject-এর মতো নয়, আনা অবজেক্টে সরাসরি মেথড থাকে না, তাই মেথড কল Invoke-CimMethod-এ পাইপ করে হয়।

flowchart TB
    accTitle: CimInstance-এর মেথড কল
    accDescr: Get-CimInstance যে CimInstance ফেরায় তাতে তারিখ প্রপার্টি DateTime-এ রূপান্তরিত হয়ে ফেরে, কিন্তু সরাসরি মেথড নেই, তাই মেথড কল ইনস্ট্যান্স Invoke-CimMethod-এ পাঠিয়ে হয়
    gci["Get-CimInstance"] --> inst["CimInstance অবজেক্ট"]
    inst -.-> dt["তারিখ DateTime-এ রূপান্তরিত"]
    inst -.-> nom["সরাসরি মেথড নেই"]
    inst --> icm["Invoke-CimMethod-এ পাঠান"]
    icm --> call["মেথড কল"]

চিত্র 4: CimInstance-এ সরাসরি মেথড নেই, তাই মেথড কল Invoke-CimMethod-এ পাঠিয়ে হয়।

# ইনস্ট্যান্সের মেথড ডাকা: প্রতিটি প্রক্রিয়ার মালিক নিন
Get-CimInstance -ClassName Win32_Process -Filter "Name = 'notepad.exe'" |
    Invoke-CimMethod -MethodName GetOwner

# ক্লাসের স্ট্যাটিক মেথড ডাকা: প্রক্রিয়া চালু করুন
Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{ CommandLine = 'notepad.exe' }

# ক্লাস সংজ্ঞা দেখুন (প্রপার্টি ও মেথড)
Get-CimClass -ClassName Win32_Process

3.2. পুরনো WMI কমান্ডলেট থেকে মাইগ্রেশন সারণি

PowerShell 6 থেকে (বর্তমান PowerShell 7সহ) নিচের WMI v1 কমান্ডলেট সরানো হয়েছে। একই কাজ CimCmdlets মডিউল (WMI v2) দেয়।²

Windows PowerShell 5.1-এও CIM কমান্ডলেট চলে, তাই এখন থেকে যা লিখবেন, 5.1-এ চালালেও CIM দিকে লিখুন — মাইগ্রেশন খরচ পড়ে না। 5.1 ও 7 সহাবস্থান ও মাইগ্রেশনের পুরো ছবি «Windows PowerShell 5.1 ও PowerShell 7-এর পার্থক্য»-এ।

flowchart TB
    accTitle: নতুন স্ক্রিপ্ট CIM-এ লেখার কারণ
    accDescr: WMI কমান্ডলেটে লেখা স্ক্রিপ্ট 5.1-এ চলে কিন্তু PowerShell 6 থেকে সরানো তাই মাইগ্রেশনে পুনর্লিখন লাগে, CIM কমান্ডলেট 5.1-এও চলে তাই নতুন লেখা CIM দিকে রাখলে মাইগ্রেশন খরচ থাকে না
    new["নতুন লেখা স্ক্রিপ্ট"] --> q1{"কোন দিকে লিখবেন?"}
    q1 -->|WMI কমান্ডলেট| old["5.1-এ চলে"]
    q1 -->|CIM কমান্ডলেট| cur["5.1-এও চলে"]
    old --> del["PowerShell 7-এ সরানো"]
    del --> rew["মাইগ্রেশনে পুনর্লিখন"]
    cur --> norew["মাইগ্রেশন খরচ থাকে না"]

চিত্র 5: নতুন স্ক্রিপ্ট CIM কমান্ডলেটে লিখলে PowerShell 7 মাইগ্রেশনে পুনর্লিখন লাগে না।

4. দূরবর্তী অনুসন্ধান — CIM সেশন (ডিফল্ট WSMan) ও DCOM অপশন

লক্ষ্য না দিলে CIM কমান্ডলেট লোকাল WMI-তে COM দিয়ে সংযোগ করে; -ComputerName দিলে WSMan (WinRM) প্রোটোকলে অস্থায়ী সেশন তৈরি করে সংযোগ করে। একই কম্পিউটারে একাধিক অপারেশন করলে CIM সেশন তৈরি করে পুনর্ব্যবহার কর্মক্ষমতায় ভালো।³

flowchart TB
    accTitle: CIM সংযোগ পদ্ধতি বাছাই
    accDescr: নির্দিষ্ট না থাকলে লোকাল WMI-তে COM সংযোগ, ComputerName দিলে প্রতি অনুসন্ধানে WSMan অস্থায়ী সেশন তৈরি হয়, একই লক্ষ্যে একাধিক অপারেশনে New-CimSession পুনর্ব্যবহার কর্মক্ষমতায় সুবিধা, WinRM কনফিগার নেই এমন লক্ষ্যে DCOM প্রোটোকল অপশন আছে
    exec["CIM কমান্ডলেট চালানো"] --> q1{"ComputerName নির্দিষ্ট?"}
    q1 -->|না| local["লোকাল WMI-তে COM সংযোগ"]
    q1 -->|হ্যাঁ| q2{"একই লক্ষ্যে একাধিক অপারেশন?"}
    q2 -->|একবার| temp["WSMan অস্থায়ী সেশন"]
    q2 -->|একাধিক| sess["New-CimSession পুনর্ব্যবহার"]
    temp -.-> cost["প্রতি অনুসন্ধানে তৈরি হয়"]
    nowinrm["WinRM কনফিগার নেই এমন লক্ষ্য"] -.-> dcom["DCOM প্রোটোকল অপশন"]

চিত্র 6: দূরবর্তী অনুসন্ধানের ডিফল্ট WSMan, আর একই লক্ষ্যে একাধিক অপারেশনে CIM সেশন পুনর্ব্যবহারই নিয়ম।

# একবারের কুয়েরিতে -ComputerName (প্রতিবার অস্থায়ী সেশন হয়)
Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName Server01, Server02

# বারবার কুয়েরি হলে 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

WSMan দিয়ে পৌঁছানো যায় না এমন লক্ষ্যে — WinRM কনফিগার করা যায় না এমন পুরনো মেশিন ইত্যাদি — DCOM প্রোটোকল বেছে নিতে পারেন।⁴

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

দূরবর্তী অনুসন্ধানের পূর্বশর্ত নিচেরগুলো।

• লক্ষ্যে WinRM কনফিগার থাকতে হবে। winrm quickconfig সার্ভিস স্বয়ংক্রিয় চালু, HTTP লিসনার (ডিফল্ট পোর্ট 5985) তৈরি, আর ফায়ারওয়াল ব্যতিক্রম নিবন্ধন একসাথে করে।¹⁰ HTTPS (ডিফল্ট পোর্ট 5986) দিয়ে সংযোগ চাইলে এতেই হয় না — সার্ভার সার্টিফিকেট তৈরি করে winrm quickconfig -transport:https ইত্যাদি দিয়ে HTTPS লিসনার আলাদা কনফিগার করতে হয়।¹⁰
• পথের ফায়ারওয়ালে সংশ্লিষ্ট পোর্ট খোলা থাকতে হবে। ইনবাউন্ড নিয়মের নকশা ও নিবন্ধনের কাজ «Windows Firewall ও ব্যবসায়িক অ্যাপ» নিবন্ধে আছে।
• প্রমাণীকরণ। ডোমেইন পরিবেশে Kerberos পারস্পরিক প্রমাণীকরণ দেয়। ওয়ার্কগ্রুপে Kerberos নেই, তাই ক্লায়েন্টের TrustedHosts তালিকায় লক্ষ্য নিবন্ধন লাগতে পারে। তালিকা যত সংকীর্ণ রাখতে পারেন রাখুন।¹⁰
• অধিকার। ডিফল্ট কনফিগারেশনে দূরবর্তী WMI অনুসন্ধান ও অপারেশন মূলত লক্ষ্যের প্রশাসক গ্রুপের অ্যাকাউন্টে হয়। সাধারণ ব্যবহারকারীকে খুলতে WinRM ও WMI নেমস্পেস দুই দিকেই প্রবেশাধিকার কনফিগার লাগে।¹⁰
• DCOM-এর নির্দিষ্ট অপেক্ষা-পোর্ট নেই (RPC-এর গতিশীল পোর্ট ব্যবহার করে), তাই ফায়ারওয়াল পেরিয়ে নকশা কঠিন হয়। এখন থেকে যা গড়বেন তাতে ডিফল্ট WSMan ধরাই নিরাপদ।

flowchart TB
    accTitle: দূরবর্তী অনুসন্ধানের পূর্বশর্ত পরীক্ষা
    accDescr: লক্ষ্যে winrm quickconfig সার্ভিস স্বয়ংক্রিয় চালু, HTTP লিসনার তৈরি ও ফায়ারওয়াল ব্যতিক্রম নিবন্ধন একসাথে করে, HTTPS লিসনার সার্টিফিকেট তৈরি করে আলাদা কনফিগার হয়, আর ওয়ার্কগ্রুপে TrustedHosts-এ নিবন্ধন লাগতে পারে
    qc["winrm quickconfig"] --> svc["সার্ভিস স্বয়ংক্রিয় চালু"]
    qc --> lis["HTTP লিসনার তৈরি (5985)"]
    qc --> fw["ফায়ারওয়াল ব্যতিক্রম"]
    lis ~~~ https["HTTPS লিসনার (5986)"]
    https -.-> cert["সার্টিফিকেট তৈরি করে আলাদা কনফিগার"]
    fw ~~~ wg["ওয়ার্কগ্রুপ পরিবেশ"]
    wg -.-> th["TrustedHosts-এ নিবন্ধন"]

চিত্র 7: winrm quickconfig ডিফল্ট কনফিগারেশন একসাথে করে; HTTPS লিসনার ও ওয়ার্কগ্রুপ প্রমাণীকরণ আলাদা।

5. C# থেকে ব্যবহার — System.Management বনাম Microsoft.Management.Infrastructure

C# থেকে WMI ব্যবহারের API দুই ধারা। দুটোই কেবল Windows।

5.1. System.Management: ManagementObjectSearcher-এর ভিত্তি

WQL স্ট্রিং হিসেবে দিয়ে 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");
}

প্রপার্টি ইনডেক্সার দিয়ে object হিসেবে ফেরে, তাই ক্লাস ডকুমেন্টে CIM টাইপ দেখে কাস্ট করুন (এই উদাহরণে FreeSpace / Size uint64⁹)। int ভেবে কাস্ট করলে InvalidCastException — এখানকার ক্লাসিক প্রথম হোঁচট।

flowchart TB
    accTitle: প্রপার্টি আনা ও কাস্টের ফাঁদ
    accDescr: System.Management-এর প্রপার্টি ইনডেক্সার দিয়ে object হিসেবে ফেরে, তাই ক্লাস ডকুমেন্টে CIM টাইপ দেখে কাস্ট করতে হয়, int ভেবে কাস্ট করলে InvalidCastException হয়
    idx["ইনডেক্সার দিয়ে আনা"] --> obj["object হিসেবে ফেরে"]
    obj --> chk["ডকুমেন্টে CIM টাইপ দেখুন"]
    chk --> cast["সঠিক টাইপে কাস্ট"]
    obj -.-> wrong["int ভেবে কাস্ট"]
    wrong -.-> ex["InvalidCastException"]

চিত্র 8: প্রপার্টি object হিসেবে ফেরে, তাই CIM টাইপ দেখে তারপর কাস্ট করুন।

5.2. MI API: CimSession-এর ভিত্তি

CimSession লোকাল ও দূরবর্তী প্রবেশ একই আকারে সামলায়। গণনা, অনুসন্ধান, মেথড কল, ইভেন্ট সাবস্ক্রিপশন, অ্যাসিঙ্ক্রোনাস রূপ এক জায়গায়।⁶

// NuGet: Microsoft.Management.Infrastructure (কেবল Windows)
using Microsoft.Management.Infrastructure;

// স্থানীয় হলে CimSession.Create(null), দূরবর্তী হলে কম্পিউটার নাম দিন
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");
}

PowerShell-এর CIM কমান্ডলেট যে CimInstance ফেরায়, সেই একই টাইপ, তাই «আগে PowerShell-এ পরীক্ষা করে C#-এ নকল করা» ডেভেলপমেন্ট প্রবাহ স্বাভাবিকভাবেই যায়। C# ও PowerShell জোড়া নিজেই নকশা করলে «C# (CSharp) থেকে PowerShell চালিয়ে অবজেক্ট হিসেবে ফলাফল নেওয়া»ও দেখুন।

flowchart TB
    accTitle: PowerShell-এ পরীক্ষা করে C#-এ নকল করার প্রবাহ
    accDescr: PowerShell-এর CIM কমান্ডলেট ও C#-এর MI API একই CimInstance টাইপ ব্যবহার করে, তাই PowerShell-এ পরীক্ষা করে C#-এ নকল করার ডেভেলপমেন্ট প্রবাহ স্বাভাবিকভাবেই যায়
    trial["PowerShell-এ পরীক্ষা"] --> gci["CIM কমান্ডলেট"]
    impl["C#-এ মূল ইমপ্লিমেন্টেশন"] --> mi["MI API"]
    gci --> ci["একই CimInstance টাইপ"]
    mi --> ci
    ci -.-> flow["নকল স্বাভাবিকভাবেই যায়"]

চিত্র 9: CIM কমান্ডলেট ও MI API একই CimInstance টাইপ ব্যবহার করে, তাই পরীক্ষা থেকে মূল ইমপ্লিমেন্টেশনে যায়।

6. ঘন ঘন ব্যবহারের রেসিপি

6.1. নিয়মিত ক্লাসের দ্রুত সূচি

6.2. সম্পদ ব্যবস্থাপনার নিয়মিত: সিরিয়াল নম্বর, মডেল নাম, ডিস্ক খালি

# মডেল তথ্য ও সিরিয়াল নম্বর (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
}

# স্থানীয় ডিস্কের (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 মানে «লোকাল ডিস্ক», রিমুভেবল (2), নেটওয়ার্ক ড্রাইভ (4), CD (5) বাদ দেয়।⁹ নজরদারিতে এই স্ক্রিপ্ট CIM সেশন দিয়ে প্রতিটি সার্ভারে ঘোরালেই এজেন্টবিহীন ডিস্ক নজরদারির ভিত্তি হয়।

flowchart TB
    accTitle: এজেন্টবিহীন ডিস্ক নজরদারির ভিত্তি
    accDescr: DriveType 3 দিয়ে সীমাবদ্ধ করলে রিমুভেবল, নেটওয়ার্ক ড্রাইভ ও CD বাদ পড়ে শুধু লোকাল ডিস্ক থাকে, আর একই স্ক্রিপ্ট CIM সেশন দিয়ে প্রতিটি সার্ভারে ঘোরালে এজেন্টবিহীন ডিস্ক নজরদারির ভিত্তি হয়
    scr["খালি জায়গা আনার স্ক্রিপ্ট"] --> flt["DriveType = 3 দিয়ে সীমাবদ্ধ"]
    flt -.-> exc["রিমুভেবল ইত্যাদি বাদ"]
    scr --> ses["CIM সেশন দিয়ে"]
    ses --> srvs["প্রতিটি সার্ভারে ঘোরান"]
    srvs --> mon["এজেন্টবিহীন নজরদারি"]

চিত্র 10: লোকাল ডিস্কে সীমাবদ্ধ স্ক্রিপ্ট CIM সেশনে প্রতিটি সার্ভারে ঘোরানোই নজরদারির ভিত্তি।

6.3. প্রক্রিয়া চালু হওয়া শনাক্ত — ইভেন্ট সাবস্ক্রিপশন

«পোলিংয়ে Win32_Process নিয়মিত এনে পার্থক্য দেখা» নয়, ইভেন্ট সাবস্ক্রিপশন ব্যবহার করুন। প্রক্রিয়া চালু ধরার সবচেয়ে সরল উপায় Win32_ProcessStartTrace সাবস্ক্রাইব করা (কার্নেল ট্রেস প্রোভাইডারের ইভেন্ট ক্লাস, ProcessName / ProcessID / ParentProcessID ইত্যাদি প্রপার্টি⁸)।

# প্রশাসক (elevated) PowerShell সেশন থেকে চালান
$action = {
    $name = $Event.SourceEventArgs.NewEvent.ProcessName
    $id   = $Event.SourceEventArgs.NewEvent.ProcessID
    Write-Host "প্রক্রিয়া চালু: $name (PID=$id)"
}
Register-CimIndicationEvent -ClassName Win32_ProcessStartTrace `
    -SourceIdentifier ProcessStarted -Action $action

সাবস্ক্রিপশন নিবন্ধন করা PowerShell সেশন বাঁচাকালীন চালু থাকে, আর প্রক্রিয়া চালু হলেই -Action চলে। একই ব্যাচে খারিজ কমান্ড টানাটানি চালালে নজরদারি শুরুর আগেই সাবস্ক্রিপশন উধাও হয় — সেদিকে খেয়াল রাখুন। খারিজ নজরদারি শেষে চালান।

# নজরদারি শেষে: সাবস্ক্রিপশন সরিয়ে ফেলুন
Unregister-Event -SourceIdentifier ProcessStarted

Register-CimIndicationEvent ক্লাস নাম বা WQL ইভেন্ট কুয়েরি দিয়ে সাবস্ক্রিপশন নিবন্ধন করে, আর -Action স্ক্রিপ্ট ব্লক প্রতি ইভেন্টে চলে।⁷ এই ক্লাস সাবস্ক্রাইব করতে প্রশাসক অধিকার লাগে।⁷ ইভেন্ট কে পাবে তা ইভেন্ট ক্লাসের সিকিউরিটি ডেসক্রিপ্টর নিয়ন্ত্রণ করে, উন্নীত অধিকার ছাড়া সাধারণ ব্যবহারকারী প্রবেশ পায় না।⁸

sequenceDiagram
    accTitle: প্রক্রিয়া চালু ইভেন্ট সাবস্ক্রিপশনের প্রবাহ
    accDescr: প্রশাসক অধিকারের PowerShell সেশনে Register-CimIndicationEvent সাবস্ক্রিপশন নিবন্ধন করে, প্রক্রিয়া চালু হলেই ইভেন্ট এসে Action চলে, নজরদারি শেষে Unregister-Event দিয়ে খারিজ হয়
    participant ps as PowerShell সেশন
    participant wmi as WMI
    ps->>wmi: Register-CimIndicationEvent দিয়ে নিবন্ধন
    Note over ps: প্রশাসক অধিকারে চালান
    wmi-->>ps: প্রক্রিয়া চালু হলেই ইভেন্ট আসে
    ps->>ps: -Action চালান
    ps->>wmi: Unregister-Event দিয়ে খারিজ (নজরদারি শেষে)

চিত্র 11: সাবস্ক্রিপশন নিবন্ধন করা সেশন বাঁচাকালীন চালু থাকে, আর খারিজ নজরদারি শেষে হয়।

আরেক উপায় যেকোনো ক্লাসে ব্যবহারযোগ্য সাধারণ ইনস্ট্যান্স-তৈরি ইভেন্ট (__InstanceCreationEvent)। এখানে WMI WITHIN-এ দেওয়া ব্যবধানে পোলিং করে পার্থক্য ইভেন্ট করে, তাই শনাক্ত ব্যবধান ও লোডের লেনদেন নিজে স্থির করতে হয়।

flowchart TB
    accTitle: প্রক্রিয়া চালু শনাক্তের দুই সাবস্ক্রিপশন পদ্ধতি
    accDescr: Win32_ProcessStartTrace কার্নেল ট্রেস প্রোভাইডারের ইভেন্ট ক্লাস সাবস্ক্রাইব করে, সাধারণ __InstanceCreationEvent-এ WMI WITHIN-এর ব্যবধানে পোলিং করে পার্থক্য ইভেন্ট করে তাই শনাক্ত ব্যবধান ও লোডের লেনদেন নিজে স্থির করতে হয়
    goal["প্রক্রিয়া চালু হওয়া শনাক্ত"] --> t1["Win32_ProcessStartTrace"]
    goal --> t2["__InstanceCreationEvent"]
    t1 -.-> k1["কার্নেল ট্রেস সাবস্ক্রিপশন"]
    t2 -.-> w1["WITHIN ব্যবধানে পোলিং"]
    w1 -.-> tr["ব্যবধান ও লোডের লেনদেন"]

চিত্র 12: নিবেদিত ইভেন্ট ক্লাস সাবস্ক্রাইব করবেন, না কি সাধারণ ইনস্ট্যান্স-তৈরি ইভেন্ট পোলিং ব্যবধানে ব্যবহার করবেন।

# ৫ সেকেন্ড অন্তর পোলিংয়ে Win32_Process-এর নতুন ইনস্ট্যান্স নজরদারি
$query = "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_Process'"
Register-CimIndicationEvent -Query $query -SourceIdentifier ProcPoll -Action {
    Write-Host "চালু: $($Event.SourceEventArgs.NewEvent.TargetInstance.Name)"
}

C# (System.Management)-এ ManagementEventWatcher একই ভূমিকা রাখে।¹¹

using System.Management;

// প্রশাসক হিসেবে চলা প্রক্রিয়ায়
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($"প্রক্রিয়া চালু: {name} (PID={pid})");
};
watcher.Start();
// নজরদারি শেষে watcher.Stop() ও Dispose ভুলবেন না

স্থায়ী নজরদারিতে বসালে সাবস্ক্রিপশন ছিঁড়ে গেলে পুনরায় নিবন্ধন (সার্ভিস রিস্টার্ট বা ত্রুটিতে) পর্যন্ত নকশায় রাখুন। ডিভাইস নজরদারিসহ «অবস্থা পরীক্ষা ও প্রদর্শন»-এর নকশা «বাইরের ডিভাইসের অবস্থা পরীক্ষা ও প্রদর্শনের সেরা অনুশীলন»-এ আছে।

stateDiagram-v2
    accTitle: স্থায়ী নজরদারির সাবস্ক্রিপশন জীবনচক্র
    accDescr: স্থায়ী নজরদারিতে সাবস্ক্রাইব অবস্থা সার্ভিস রিস্টার্ট বা ত্রুটিতে ছিঁড়ে যেতে পারে, তাই ছিঁড়ে যাওয়া ধরে পুনরায় নিবন্ধন করে সাবস্ক্রাইব অবস্থায় ফেরার নকশা পর্যন্ত রাখুন
    s1: সাবস্ক্রাইব অবস্থা
    s2: সাবস্ক্রিপশন ছিঁড়ে গেছে
    s3: পুনরায় নিবন্ধন
    [*] --> s1
    s1 --> s2: সার্ভিস রিস্টার্ট বা ত্রুটি
    s2 --> s3
    s3 --> s1

চিত্র 13: স্থায়ী নজরদারিতে সাবস্ক্রিপশন ছিঁড়ে গেলে পুনরায় নিবন্ধন করে সাবস্ক্রাইব অবস্থায় ফেরার নকশা পর্যন্ত রাখুন।

7. ফাঁদ — কর্মক্ষমতা, অধিকার, 64bit, রিপোজিটরি, তারিখ

7.1. SELECT * ও অতিরিক্ত পোলিং

WMI অনুসন্ধান «প্রোভাইডার সেখানেই মান তৈরি করে» — বিনামূল্যে নয়। ক্লাসিক অ্যান্টিপ্যাটার্ন দুটি।

• অভ্যাসে SELECT *। Win32_Process-এর প্রতি সারির প্রতি প্রপার্টি আনলে প্রোভাইডারের কাজ ও নেটওয়ার্ক স্থানান্তর (দূরবর্তী হলে) সেই অনুপাতে ফোলে। -Filter দিয়ে সারি, -Property দিয়ে কলাম সীমাবদ্ধ করুন, পরের অপারেশনের জন্য শুধু কী লাগলে -KeyOnly ব্যবহার করুন। সবগুলোই «অবজেক্টের আকার ও নেটওয়ার্ক ট্রাফিক কমাতে» সরকারি, উদ্দেশ্য-নির্মিত উপায়।³
• স্বল্প-ব্যবধান পোলিং। «প্রতি সেকেন্ডে Get-CimInstance Win32_Process»-এর মতো নকশা ধারা 6.3-এর ইভেন্ট সাবস্ক্রিপশনে বদলান। পোলিং ধরন (WITHIN) সত্যি লাগলেও ব্যবধান চাহিদার জন্য যতটা যথেষ্ট ততটা চওড়া করুন।

দূরবর্তী লক্ষ্যে একটা করে -ComputerName পুনরাবৃত্তিও অপচয় — প্রতি অনুসন্ধানে অস্থায়ী সেশন তৈরি হয়, তাই একাধিক অপারেশনে CIM সেশন পুনর্ব্যবহার করুন।³

flowchart TB
    accTitle: কর্মক্ষমতা অ্যান্টিপ্যাটার্ন ও বদলের গন্তব্য
    accDescr: SELECT অ্যাস্টারিস্কের অভ্যাস Filter ও Property দিয়ে সারি ও কলাম সীমাবদ্ধ করে শুধু কী হলে KeyOnly ব্যবহার করুন, স্বল্প-ব্যবধান পোলিং ইভেন্ট সাবস্ক্রিপশনে বদলান, একটা করে ComputerName পুনরাবৃত্তি CIM সেশন পুনর্ব্যবহারে বদলান
    a1["SELECT * অভ্যাসে ব্যবহার"] --> f1["Filter ও Property দিয়ে সীমাবদ্ধ"]
    f1 -.-> f2["শুধু কী হলে KeyOnly"]
    a2["স্বল্প-ব্যবধান পোলিং"] --> f3["ইভেন্ট সাবস্ক্রিপশনে বদলান"]
    a3["একটা করে ComputerName"] --> f4["CIM সেশন পুনর্ব্যবহার"]

চিত্র 14: সারি-কলাম-কী সীমাবদ্ধকরণ ও ইভেন্ট সাবস্ক্রিপশনে বদল WMI-এর কর্মক্ষমতা সমস্যার অর্ধেক আটকায়।

7.2. ইভেন্ট সাবস্ক্রিপশনের অধিকার

ধারা 6.3-এর মতো, Win32_ProcessStartTrace পরিবার সাবস্ক্রাইব করতে প্রশাসক অধিকার ধরে নেওয়া।⁷ «ডেভেলপমেন্ট মেশিনে (প্রশাসক হিসেবে চালিয়ে) চলল, কিন্তু গ্রাহকের সাধারণ-ব্যবহারকারী পরিবেশে নজরদারি চলে না» — ফায়ারওয়াল নোটিফিকেশন ডায়ালগের পাশেই ক্লাসিক দুর্ঘটনা। সাধারণ ব্যবহারকারীতে চলা ব্যবসায়িক অ্যাপে নজরদারি বসালে নজরদারি অংশ Windows সার্ভিসে (যেমন LocalSystem) আলাদা করে অ্যাপ মূল অংশের সঙ্গে প্রসেস-আন্তঃ যোগাযোগে যুক্ত করার কথা ভাবুন।

flowchart TB
    accTitle: সাধারণ ব্যবহারকারী পরিবেশে নজরদারি গঠন
    accDescr: প্রশাসক অধিকার ধরে নেওয়া সাবস্ক্রিপশন সাধারণ ব্যবহারকারীতে চলা অ্যাপ মূল অংশ থেকে কেটে, LocalSystem ইত্যাদিতে চলা Windows সার্ভিসে নজরদারি আলাদা করে, অ্যাপ মূল অংশের সঙ্গে প্রসেস-আন্তঃ যোগাযোগে যুক্ত করুন
    svcm["নজরদারি Windows সার্ভিস"] --> subm["স্টার্ট ট্রেস সাবস্ক্রাইব"]
    svcm -.-> lsm["LocalSystem ইত্যাদিতে চলে"]
    appm["অ্যাপ মূল অংশ (সাধারণ ব্যবহারকারী)"] ---|প্রসেস-আন্তঃ যোগাযোগ| svcm

চিত্র 15: প্রশাসক অধিকার লাগে এমন সাবস্ক্রিপশন সার্ভিস দিকে আলাদা করুন, অ্যাপ মূল অংশের সঙ্গে প্রসেস-আন্তঃ যোগাযোগে যুক্ত করুন।

7.3. 32bit/64bit ও প্রোভাইডার

64bit Windows-এ কিছু প্রোভাইডারের 32bit ও 64bit সংস্করণ দুইই থাকে, আর ডিফল্টে কলার অ্যাপের বিটনেসের মিল থাকা দিক সাড়া দেয়।¹² ক্লাসিক উদাহরণ root\default-এর রেজিস্ট্রি প্রোভাইডার (StdRegProv): 32bit অ্যাপ থেকে পড়লে Wow6432Node দিকের (32bit ভিউ) মান ফেরে।¹² «WMI দিয়ে পড়া রেজিস্ট্রি মান regedit-এ দেখা মানের সঙ্গে মেলে না» হলে আগে এটা সন্দেহ করুন। অন্য ভিউ লাগলে সংযোগ কনটেক্সটে __ProviderArchitecture (আর জোর করতে চাইলে __RequiredArchitecture) দিয়ে স্পষ্ট অনুরোধ করা যায়।¹² বিটনেস সমস্যার পুরো ছবি «C# থেকে Win32 API নিরাপদে ডাকা — P/Invoke বাস্তব নির্দেশিকা»-এও আছে।

flowchart TB
    accTitle: 64bit পরিবেশে প্রোভাইডার বাছাই
    accDescr: ডিফল্টে কলার অ্যাপের বিটনেসের মিল থাকা প্রোভাইডার সাড়া দেয়, 32bit অ্যাপের রেজিস্ট্রি অনুসন্ধান Wow6432Node দিকের মান পায়, কিন্তু __ProviderArchitecture দিয়ে উল্টো ভিউ স্পষ্ট অনুরোধ করা যায়
    q1{"কলারের বিটনেস কী?"} -->|32bit| p32["32bit প্রোভাইডার সাড়া দেয়"]
    q1 -->|64bit| p64["64bit প্রোভাইডার সাড়া দেয়"]
    p32 -.-> wow["রেজিস্ট্রি Wow6432Node দিকের মান"]
    ctx["__ProviderArchitecture নির্দিষ্ট"] -.-> ov["উল্টো ভিউ স্পষ্ট অনুরোধ"]

চিত্র 16: ডিফল্টে কলারের বিটনেসের মিল থাকা দিক সাড়া দেয়, তাই 32bit অ্যাপ Wow6432Node দিক পড়ে।

7.4. WMI রিপোজিটরি নষ্ট হলে লক্ষণ ও প্রতিকার

WMI-এর ক্লাস সংজ্ঞা রিপোজিটরিতে থাকে (এক ফাইল নয় — Repository ফোল্ডারের ফাইলগুলো মিলে ডেটাবেস হিসেবে কাজ করে¹³)। সঙ্গতিহীন হলে «থাকার কথা এমন ক্লাস পাওয়া যায় না» বা «নেমস্পেস অবৈধ»-এর মতো ত্রুটি অ্যাপ দিকে কিছু না বদলেও উঠতে শুরু করে। নির্ণয় ও মেরামতে winmgmt.exe ব্যবহার করুন।¹³

rem সামঞ্জস্য পরীক্ষা (ফলাফল inconsistent হলে অসামঞ্জস্য আছে)
winmgmt /verifyrepository

rem সামঞ্জস্য পরীক্ষা + অসামঞ্জস্য থাকলে পুনর্নির্মাণ (পড়া যায় এমন বিষয়বস্তু মার্জ হয়)
winmgmt /salvagerepository

গুরুত্বপূর্ণ কথা, রিপোজিটরি মুছে ফেলা বা রিসেটকে প্রথম পদক্ষেপ করবেন না। WMI দিয়ে ওঠা ত্রুটি OS-এর অন্য অংশ থেকেও আসতে পারে, আর Microsoft নিজেই স্পষ্ট বলে রিপোজিটরি মুছে ফেলা প্রথম সাড়া «সিস্টেম বা ইনস্টল করা অ্যাপে ক্ষতি করতে পারে»।¹³ ক্রম রাখুন: /verifyrepository দিয়ে পরীক্ষা, তারপর /salvagerepository দিয়ে মেরামত।

flowchart TB
    accTitle: WMI রিপোজিটরি সঙ্গতিহীনতার কাটাকুটি
    accDescr: ক্লাস পাওয়া যায় না ইত্যাদি ত্রুটি উঠলে winmgmt-এর verifyrepository দিয়ে সঙ্গতি দেখুন, সঙ্গতিহীন হলে salvagerepository দিয়ে পুনর্গঠন করুন, রিপোজিটরি মুছে ফেলা বা রিসেট প্রথম পদক্ষেপ করবেন না
    sym["ক্লাস পাওয়া যায় না ইত্যাদি ত্রুটি"] --> verify["winmgmt /verifyrepository"]
    verify --> q1{"ফল inconsistent?"}
    q1 -->|হ্যাঁ| salvage["winmgmt /salvagerepository"]
    q1 -->|না| other["OS-এর অন্য অংশ সন্দেহ করুন"]
    salvage -.-> merge["পড়ার-যোগ্য বিষয়বস্তু মার্জ হয়"]
    del["রিপোজিটরি মুছে ফেলা বা রিসেট"] -.-> ng["প্রথম পদক্ষেপ করবেন না"]

চিত্র 17: verify দিয়ে নিশ্চিত করে salvage দিয়ে মেরামতের ক্রম রাখুন, মুছে ফেলা প্রথম পদক্ষেপ করবেন না।

7.5. DMTF তারিখ ফরম্যাট রূপান্তর

WMI তারিখ CIM স্পেসিফিকেশনের DMTF ফরম্যাটের স্ট্রিং হিসেবে রাখা: yyyymmddHHMMSS.mmmmmm±UUU (শেষের মান UTC থেকে মিনিটে অফসেট — উদাহরণ 20260801100000.000000+540)। কাঁচা মান স্ট্রিং কেটে-জোড়া করবেন না; রূপান্তর API ব্যবহার করুন।

• C# (System.Management): ManagementDateTimeConverter DMTF ফরম্যাট ও DateTime / TimeSpan-এর মধ্যে রূপান্তর দেয়।¹¹
• CIM-পরিবার API (Get-CimInstance / MI API): তারিখ প্রপার্টি আগেই DateTime-এ রূপান্তরিত হয়ে ফেরে, তাই এই সমস্যাই ওঠে না। (Get-CimInstance Win32_OperatingSystem).LastBootUpTime সরাসরি DateTime হিসেবে হিসাবে ব্যবহার করা যায়।

flowchart TB
    accTitle: DMTF তারিখ ফরম্যাটের ব্যবহার
    accDescr: WMI তারিখ DMTF ফরম্যাটের স্ট্রিংয়ে রাখা, System.Management দিয়ে কাঁচা মান পড়লে ManagementDateTimeConverter দিয়ে রূপান্তর করুন, CIM-পরিবার API হলে DateTime-এ রূপান্তরিত হয়ে ফেরে, তাই নিজে স্ট্রিং কেটে-জোড়া করবেন না
    dmtf["DMTF ফরম্যাটের স্ট্রিং"] --> q1{"কোন API দিয়ে আনবেন?"}
    q1 -->|System.Management| conv["ManagementDateTimeConverter"]
    q1 -->|CIM-পরিবার API| done["DateTime-এ রূপান্তরিত হয়ে ফেরে"]
    conv --> dtv["DateTime / TimeSpan-এ রূপান্তর"]
    cut["নিজে স্ট্রিং কেটে-জোড়া"] -.-> ng["ব্যবহার করবেন না"]

চিত্র 18: DMTF স্ট্রিং রূপান্তর রূপান্তর API-এর হাতে ছেড়ে দিন; CIM-পরিবার API হলে রূপান্তরিত DateTime সরাসরি ব্যবহার করুন।

8. WMI ব্যবহার করা উচিত নয় এমন পরিস্থিতি — সিদ্ধান্ত সারণি

WMI «একীভূত পড়ার মুখ» হিসেবে চমৎকার, কিন্তু সবসময় সেরা বাছাই নয়। হাতিয়ার বাছাইয়ের ব্যবহারিক নিয়ম।

নিয়ম সরল: নিবেদিত ব্যবস্থা আছে এমন এলাকায় নিবেদিত ব্যবস্থা ব্যবহার করুন, আর আড়াআড়ি অনুসন্ধান ও দূরবর্তী অনুসন্ধানে WMI/CIM রাখুন। শেষ সারির Get-NetFirewallRule ভিতরে CIM-এর উপর গড়া কমান্ডলেট সেট — «WMI/CIM সরাসরি না ছুঁয়ে তার সুবিধাই নেওয়া» রূপ।

flowchart TB
    accTitle: হাতিয়ার বাছাইয়ের অক্ষ
    accDescr: নিবেদিত ব্যবস্থা আছে এমন এলাকায় নিবেদিত ব্যবস্থা ব্যবহার করুন, নেই এমন এলাকার আড়াআড়ি অনুসন্ধান বা দূরবর্তী অনুসন্ধানে WMI ও CIM ব্যবহারই বাছাইয়ের অক্ষ, আর নিবেদিত CIM-ভিত্তিক কমান্ডলেট WMI ও CIM সরাসরি না ছুঁয়ে সুবিধাই নেয়
    q1{"নিবেদিত ব্যবস্থা আছে?"} -->|আছে| ded["নিবেদিত ব্যবস্থা ব্যবহার করুন"]
    q1 -->|নেই| wmi["WMI / CIM ব্যবহার করুন"]
    wmi -.-> use["আড়াআড়ি অনুসন্ধান ও দূরবর্তী অনুসন্ধান"]
    cmd["নিবেদিত CIM-ভিত্তিক কমান্ডলেট"] -.-> ben["শুধু সুবিধা নেওয়ার রূপ"]

চিত্র 19: নিবেদিত ব্যবস্থা আছে এমন এলাকায় নিবেদিত ব্যবস্থা নিন, আর আড়াআড়ি অনুসন্ধান ও দূরবর্তী অনুসন্ধানে WMI/CIM ব্যবহার করুন।

9. সারাংশ

• CIM DMTF-এর শিল্প স্ট্যান্ডার্ড, WMI তার Microsoft ইমপ্লিমেন্টেশন। PowerShell-এর CIM কমান্ডলেট ও C#-এর MI API দুটোই এই স্ট্যান্ডার্ড মেনে চলা বর্তমান প্রজন্মের প্রবেশপথ।
• PowerShell-এ Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent বর্তমান। Get-WmiObjectসহ WMI কমান্ডলেট PowerShell 7-এ নেই, তাই নতুন স্ক্রিপ্ট 5.1 লক্ষ্য হলেও CIM দিকে লিখুন।
• দূরবর্তী অনুসন্ধানের ডিফল্ট WSMan (WinRM), একাধিক অপারেশনে CIM সেশন পুনর্ব্যবহার করুন। WinRM কনফিগার নেই এমন লক্ষ্যে DCOM অপশন পথ আছে।
• C#-এ System.Management (সহজ, লোকাল-মুখী) ও Microsoft.Management.Infrastructure (দূরবর্তী ও নজরদারি-মুখী, CIM কমান্ডলেটের টাইপ ব্যবস্থা ভাগ)-এর মধ্যে বাছুন। দুটোই কেবল-Windows NuGet প্যাকেজ।
• প্রক্রিয়া নজরদারি পোলিং নয়, ইভেন্ট সাবস্ক্রিপশনে। Win32_ProcessStartTrace সাবস্ক্রাইব করতে প্রশাসক অধিকার লাগে।
• SELECT * ও স্বল্প-ব্যবধান পোলিং এড়িয়ে -Filter / -Property / -KeyOnly দিয়ে সীমাবদ্ধ করুন। 32bit প্রক্রিয়া থেকে অনুসন্ধান 32bit প্রোভাইডার সাড়া দেয়, DMTF তারিখে রূপান্তর API লাগে, নষ্ট রিপোজিটরি মুছে ফেলা নয় verify → salvage ক্রমে সামলান — এগুলো মনে রাখুন।
• নিবেদিত ব্যবস্থা আছে এমন এলাকায় (সেটিং, পারফরম্যান্স কাউন্টার, একবারের API কল) WMI আনবেন না — আড়াআড়ি অনুসন্ধান ও দূরবর্তী অনুসন্ধানে WMI/CIM রাখুন। জায়গা এই এক লাইনেই।

সম্পর্কিত নিবন্ধ

• C# (CSharp) থেকে PowerShell চালিয়ে অবজেক্ট হিসেবে ফলাফল নেওয়া
• PowerShell ব্যবহারিক কমান্ড রেসিপি — দৈনন্দিন ছোট সরঞ্জাম বাড়ানো
• Windows PowerShell 5.1 ও PowerShell 7-এর পার্থক্য — ইন-হাউস স্ক্রিপ্ট মাইগ্রেশনের বাস্তব নির্দেশিকা
• বাইরের ডিভাইসের অবস্থা পরীক্ষা ও প্রদর্শনের সেরা অনুশীলন — শুধু «সংযুক্ত» দিয়ে শেষ না করা নকশা
• C# থেকে Win32 API নিরাপদে ডাকা — P/Invoke বাস্তব নির্দেশিকা (DllImport / LibraryImport / CsWin32)
• Windows-এ TPM কী? — «চাবি বাইরে যায় না এমন সিন্দুক» ও মেজার্ড বুটের চিত্রিত নির্দেশিকা

সম্পর্কিত পরামর্শ ক্ষেত্র

KomuraSoft LLC WMI/CIM দিয়ে হার্ডওয়্যার তথ্য আনা, প্রক্রিয়া নজরদারি ও দূরবর্তী PC অনুসন্ধান ব্যবসায়িক অ্যাপে বসানো, Get-WmiObject-ভিত্তিক ইন-হাউস স্ক্রিপ্ট CIM কমান্ডলেটে মাইগ্রেশন, আর «ডেভেলপমেন্ট মেশিনে চলে কিন্তু গ্রাহকের সাইটে অধিকার ত্রুটিতে ব্যর্থ» ধরনের সমস্যার তদন্ত সামলায়। PowerShell-এ পরীক্ষা থেকে C#-এ মূল ইমপ্লিমেন্টেশন পর্যন্ত এক পথে সাহায্য করতে পারি।

• Windows অ্যাপ ডেভেলপমেন্ট
• বাগ ও কারণ তদন্ত
• প্রযুক্তিগত পরামর্শ ও ডিজাইন রিভিউ
• যোগাযোগ করুন

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

WMI আর CIM-এর পার্থক্য কী?

CIM হলো DMTF (Distributed Management Task Force) যে «সিস্টেম ও ডিভাইসের মতো ব্যবস্থাপনার লক্ষ্য প্রকাশের শিল্প স্ট্যান্ডার্ড মডেল» প্রণয়ন ও রক্ষণাবেক্ষণ করে। WMI সেই স্ট্যান্ডার্ড ব্যবহার করা WBEM উদ্যোগের Microsoft ইমপ্লিমেন্টেশন, Windows-এ বসানো। অর্থাৎ CIM স্পেসিফিকেশন, WMI Windows-এর ইমপ্লিমেন্টেশন। PowerShell-এর Get-CimInstance ও C#-এর Microsoft.Management.Infrastructure নিজেদের «CIM» বলে কারণ তারা এই স্ট্যান্ডার্ড মেনে চলা API, কিন্তু সংযোগ একই WMI ভিত্তিতে। দৈনন্দিন ডেভেলপমেন্টে «WMI ক্লাস (Win32_* ইত্যাদি) CIM-পরিবার API দিয়ে অনুসন্ধান» বুঝলেই কাজ চলে।

Get-WmiObject আর ব্যবহার করা যায় না?

Windows PowerShell 5.1-এ এখনও চলে, কিন্তু PowerShell 6 থেকে (বর্তমান PowerShell 7সহ) WMI v1 কমান্ডলেট — Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Set-WmiInstance, Remove-WmiObject — সরিয়ে ফেলা হয়েছে, চালানো যায় না। একই কাজ CimCmdlets মডিউল (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent ইত্যাদি) দেয়। নতুন স্ক্রিপ্ট 5.1-এ চালালেও CIM কমান্ডলেটে লেখাই নিরাপদ। তাহলে পরে PowerShell 7-এ গেলে WMI অংশ আবার লিখতে হয় না।

C# থেকে WMI ব্যবহার করতে System.Management না Microsoft.Management.Infrastructure?

দুটোই কেবল Windows, আর বর্তমান .NET থেকে NuGet প্যাকেজ হিসেবে আনেন। System.Management ক্লাসিক API, ManagementObjectSearcher-এ WQL দিলেই চলে, লোকাল তথ্যই মূল কাজ হলে এতেই হয়। DMTF তারিখ রূপান্তরের ManagementDateTimeConverterও এখানে। অন্যদিকে Microsoft.Management.Infrastructure (MI API) PowerShell-এর CIM কমান্ডলেটের সঙ্গে একই টাইপ ব্যবস্থা (CimSession / CimInstance) ভাগ করে, আর WSMan দিয়ে দূরবর্তী অনুসন্ধান, অ্যাসিঙ্ক্রোনাস মেথড, ইভেন্ট সাবস্ক্রিপশন (Subscribe) একই ধরনে সামলায়। দূরবর্তী PC অনুসন্ধান ও নজরদারি পণ্যে বসালে MI APIই যৌক্তিক বাছাই।

দূরবর্তী PC-তে Get-CimInstance সংযোগ করে না। কী দেখব?

আগে লক্ষ্য মেশিনে WinRM কনফিগার আছে কি না দেখুন। -ComputerName দেওয়া CIM অপারেশন WSMan (WinRM) প্রোটোকলে অস্থায়ী সেশন তৈরি করে, তাই লক্ষ্যে WinRM সার্ভিস ও লিসনার চলা ধরে নেয়। winrm quickconfig ডিফল্ট কনফিগারেশন (সার্ভিস চালু, লিসনার তৈরি, ফায়ারওয়াল ব্যতিক্রম) করে। ডিফল্ট পোর্ট HTTP 5985, HTTPS 5986, তাই পথের ফায়ারওয়ালও দেখুন। ওয়ার্কগ্রুপে Kerberos পারস্পরিক প্রমাণীকরণ নেই, তাই ক্লায়েন্টের TrustedHosts তালিকায় লক্ষ্য নিবন্ধন লাগতে পারে। WinRM একেবারে কনফিগার করা যায় না এমন লক্ষ্যে New-CimSessionOption -Protocol Dcom দিয়ে তৈরি অপশনে DCOM দিয়ে সংযোগ করা যায়।

WMI তারিখ কেন «20260801100000.000000+540»-এর মতো ফরম্যাটে ফেরে?

WMI তারিখ DMTF CIM স্পেসিফিকেশনের স্ট্রিং ফরম্যাটে রাখা হয় (yyyymmddHHMMSS.mmmmmm±UUU, শেষের মান UTC থেকে মিনিটে অফসেট)। পুরনো Get-WmiObject বা System.Management দিয়ে কাঁচা মান পড়লে এই স্ট্রিংই ফেরে। C# (System.Management)-এ ManagementDateTimeConverter DMTF ফরম্যাট ও DateTime / TimeSpan-এর মধ্যে রূপান্তর দেয়, তাই নিজে স্ট্রিং কেটে-জোড়া করবেন না। Get-CimInstance-এর মতো CIM-পরিবার API দিয়ে নিলে তারিখ প্রপার্টি আগেই DateTime-এ রূপান্তরিত হয়ে ফেরে, তাই এই সমস্যাই ওঠে না।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।