WMI/CIM מ-C# ומ-PowerShell — מדריך מעשי למידע חומרה, ניטור process ושאילתות remote

“רוצים להציג serial number ושם דגם של המחשב במסך של אפליקציה עסקית.” “רוצים לנטר דיסק פנוי בשרת ולהרים אזהרה.” “רוצים לזהות ש-process מסוים התחיל.” “רוצים לשלוף במרוכז את מצב המחשבים במקום remote.” — דרישות מהסוג הזה עולות שוב ושוב בפיתוח אפליקציות עסקיות וכלי ניהול ל-Windows. והתשובה הסטנדרטית להן היא WMI (Windows Management Instrumentation), או, בשם התקן, CIM (Common Information Model).

flowchart TB
    accTitle: דרישות קלאסיות ו-WMI/CIM
    accDescr: התשובה הקלאסית לדרישות הקלאסיות של אפליקציה עסקית — הצגת serial number ושם דגם, ניטור דיסק פנוי, זיהוי process שהתחיל ושאילתת מחשב remote — היא WMI, ובשם הסטנדרטי CIM
    r1["serial number ושם דגם"] --> ans["WMI (השם הסטנדרטי: CIM)"]
    r2["ניטור דיסק פנוי"] --> ans
    r3["זיהוי process שהתחיל"] --> ans
    r4["שאילתת מחשב remote"] --> ans

איור 1: התשובה הקלאסית לארבע הדרישות הקלאסיות של אפליקציה עסקית היא WMI/CIM.

מה שמסבך הוא שמידע על WMI מערבב ישן וחדש. חיפוש מעלה זה לצד זה מאמרים בני עשר שנים שמשתמשים ב-Get-WmiObject ומאמרים שמשתמשים ב-Get-CimInstance, ובצד C# יש שתי שושלות נפרדות: System.Management ו-Microsoft.Management.Infrastructure. קשה לדעת מהי הכתיבה הנוכחית ומה “עדיין רץ אבל לא בוחרים לקוד חדש”. בפועל Get-WmiObject כלל לא קיים ב-PowerShell 7, והעובדה הזאת צצה בבת אחת כשמגרים סקריפט פנימי שנכתב ל-5.1.

המאמר הזה מיועד למפתחי C#/PowerShell שמיישמים באפליקציה עסקית שליפת מידע חומרה, ניטור process ושאילתות מחשב remote. הוא מסדר, מעוגן במקורות ראשוניים נכון לאוגוסט 2026, את ההבנה המינימלית של מבנה WMI/CIM, את CIM cmdlets של PowerShell, את שני ה-API ב-C#, מתכונים נפוצים בפועל, מלכודות של ביצועים, הרשאות ו-64bit, ולבסוף איך לשפוט “מתי לא להשתמש ב-WMI”.

1. קודם כל, המסקנות

• CIM הוא מודל התקן התעשייתי למידע ניהול שהוגדר ב-DMTF, ו-WMI הוא המימוש של Microsoft. API ממשפחת “CIM” ב-PowerShell וב-C# הם דור נוכחי שעוקב אחרי התקן, והם מתחברים לאותה תשתית WMI.¹
• ב-PowerShell הדור הנוכחי הוא CIM cmdlets (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent). cmdlets ישנים של WMI (Get-WmiObject ועוד ארבעה) הוסרו מ-PowerShell 6 ואילך ואינם רצים ב-PowerShell 7.²
• ה-namespace שברירת המחדל הוא root/CIMV2, ושאילתה יום-יומית היא בעיקרה סינון classes מסוג Win32_* שם ב-WQL.³
• שאילתה remote ברירת המחדל שלה WSMan (WinRM). ציון -ComputerName יוצר session זמני של WSMan. אם שואלים את אותו יעד שוב ושוב, שימוש חוזר ב-CIM session (New-CimSession) הוא הנוהג המבוסס לביצועים, וליעד ישן שאי אפשר להגדיר בו WinRM יש אפשרות פרוטוקול DCOM.³⁴
• ב-C# יש שתי שושלות: System.Management (ManagementObjectSearcher) ו-Microsoft.Management.Infrastructure (CimSession). שתיהן ייעודיות ל-Windows, וב-.NET הנוכחי מביאים אותן מ-NuGet. אם בונים שאילתות remote או ניטור למוצר של ממש, MI API — שחולק את מערכת הטיפוסים עם CIM cmdlets — מתאים יותר.⁵⁶
• זיהוי process שהתחיל נעשה ב-event subscription, לא ב-polling. Subscribe ל-Win32_ProcessStartTrace חייב לרוץ בהרשאות Administrator.⁷⁸
• לא משתמשים ב-SELECT * מתוך הרגל. צמצום מה שמועבר עם -Filter / -Property / -KeyOnly מונע בערך מחצית מבעיות הביצועים של WMI.³
• WMI אינו פתרון אוניברסלי. לניטור ביצועים בתדירות גבוהה, לקריאה וכתיבה של הגדרות האפליקציה עצמה, או לקריאה חד-פעמית לפונקציית מערכת, performance counters, Registry, Win32 API או cmdlets ייעודיים מתאימים יותר (ראו טבלת ההחלטה בפרק 8).

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 26, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מהו WMI/CIM — תקן מול מימוש, namespaces, classes ו-WQL

קודם מסדרים אחת ולתמיד את יחסי המונחים.

flowchart TB
    accTitle: הקשר בין תקן CIM למימוש WMI
    accDescr: תקן CIM ש-DMTF מגדיר ומתוחזק משמש במסגרת יוזמת WBEM, המימוש של Microsoft הוא WMI, MI מהדור הבא תואם לחלוטין ל-WMI המסורתי, ו-API ממשפחת CIM מתחברים לאותה תשתית WMI
    dmtf["DMTF מגדיר ומתוחזק"] --> cim["CIM (מודל תקן תעשייתי)"]
    wbem["WBEM (יוזמה תעשייתית)"] --> wmi["WMI (מימוש Microsoft)"]
    cim --> wmi
    wmi -.-> mi["MI (דור הבא, תאימות מלאה)"]
    api["API ממשפחת CIM (PowerShell / C#)"] --> wmi

איור 2: CIM הוא המפרט, WMI הוא המימוש ב-Windows. API ממשפחת CIM מתחברים לאותה תשתית WMI.

יש ארבעה חלקי מבנה שכדאי למפתח להבין.

• namespace: היררכיה שאוספת classes. לשאילתה יום-יומית משתמשים כמעט תמיד ב-root/CIMV2, שהוא גם ברירת המחדל של CIM cmdlets.³ אחרים כוללים את root\default (Registry provider ועוד).
• class: טיפוס שמייצג יעד ניהול, כמו Win32_ComputerSystem (המחשב עצמו), Win32_LogicalDisk (כונן לוגי) או Win32_Process (process). classes ייחודיות ל-Windows שיורשות מ-classes של תקן CIM (כמו CIM_LogicalDisk) נושאות את הקידומת Win32_.⁹
• provider: הרכיב שמספק את התוכן הממשי של class. כששואלים אותו, ה-provider פונה ל-OS במקום ובונה את הערכים.
• WQL: שפת שאילתה דמוית SQL. כמו ב-SELECT Name, State FROM Win32_Service WHERE StartMode = 'Auto', מתייחסים ל-class כאל טבלה ומסננים אותה. WQL היא גם שפת השאילתה שברירת המחדל של CIM cmdlets.³

“לקרוא מידע על ה-OS ועל החומרה דרך classes ושפת שאילתה אחידות” — זה הערך ש-WMI נותן. ולהפך, כתיבה ופעולות מוגבלות ל-classes שיש להן מתודות שאפשר לקרוא ב-Invoke-CimMethod; זה לא מנגנון שיכול הכול.

flowchart TB
    accTitle: מבנה שאילתת WMI
    accDescr: שאילתת WQL מופנית ל-classes מסוג Win32_* ב-namespace root/CIMV2, ה-provider שמספק את תוכן ה-class פונה ל-OS במקום ובונה ערכים, והתוצאה חוזרת
    wql["שאילתה ב-WQL"] --> ns["namespace root/CIMV2"]
    ns --> cls["Win32_* classes"]
    cls --> prov["provider"]
    prov --> osq["פנייה ל-OS במקום"]
    osq --> res["החזרת תוצאה"]

איור 3: השאילתה עוברת ב-namespace, ב-class וב-provider, והערכים נוצרים במקום.

3. שימוש מ-PowerShell —‏ CIM cmdlets הם הנוכחיים, WMI cmdlets הוסרו

3.1. הבסיס: Get-CimInstance

# לפי שם class (namespace ברירת מחדל root/CIMV2)
Get-CimInstance -ClassName Win32_OperatingSystem

# כותבים ב-Filter רק את תוכן פסוקית WHERE (בלי מילת המפתח 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 הוא בדיוק פסוקית WHERE של WQL, ו--Property מגביל אילו עמודות נשלפות.³ ערך ההחזרה הוא אובייקט CimInstance, ומאפייני תאריך (כמו CreationDate או LastBootUpTime) חוזרים כבר מומרים ל-DateTime. בניגוד ל-Get-WmiObject הישן, האובייקט שנשלף אינו נושא מתודות ישירות, ולכן קריאות למתודה נעשות בהעברה ל-Invoke-CimMethod.

flowchart TB
    accTitle: קריאת מתודה על CimInstance
    accDescr: CimInstance ש-Get-CimInstance מחזיר מגיע עם מאפייני תאריך שכבר הומרו ל-DateTime, אבל בלי מתודות ישירות, לכן קריאת מתודה נעשית בהעברת המופע ל-Invoke-CimMethod
    gci["Get-CimInstance"] --> inst["אובייקט CimInstance"]
    inst -.-> dt["תאריכים כבר DateTime"]
    inst -.-> nom["אין מתודות ישירות"]
    inst --> icm["מעבירים ל-Invoke-CimMethod"]
    icm --> call["קריאת מתודה"]

איור 4: ל-CimInstance אין מתודות, לכן קריאת מתודה נעשית בהעברה ל-Invoke-CimMethod.

# קריאת מתודה על מופע: owner של כל process
Get-CimInstance -ClassName Win32_Process -Filter "Name = 'notepad.exe'" |
    Invoke-CimMethod -MethodName GetOwner

# קריאת מתודה סטטית של ה-class: הפעלת process
Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{ CommandLine = 'notepad.exe' }

# בדיקת הגדרת ה-class (מאפיינים ומתודות)
Get-CimClass -ClassName Win32_Process

3.2. טבלת מיגרציה מ-WMI cmdlets ישנים

מ-PowerShell 6 ואילך (כולל PowerShell 7 הנוכחי) WMI v1 cmdlets הבאים הוסרו. אותה פונקציונליות מסופקת במודול CimCmdlets (WMI v2).²

CIM cmdlets רצים גם תחת Windows PowerShell 5.1, לכן כל מה שכותבים מעתה נכתב בצד CIM גם אם ירוץ תחת 5.1 — כך לא נשארת עלות מיגרציה. לתמונה המלאה של דו-קיום ומיגרציה בין 5.1 ל-7 ראו “ההבדלים בין Windows PowerShell 5.1 ל-PowerShell 7”.

flowchart TB
    accTitle: למה לכתוב סקריפט חדש ב-CIM
    accDescr: סקריפט שנכתב ב-WMI cmdlets רץ ב-5.1 אבל הוסר מ-PowerShell 6 ואילך ולכן דורש שכתוב במיגרציה, ו-CIM cmdlets זמינים גם ב-5.1 ולכן כתיבה חדשה בצד CIM לא משאירה עלות מיגרציה
    new["סקריפט שנכתב עכשיו"] --> q1{"באיזה מהם כותבים?"}
    q1 -->|WMI cmdlets| old["רץ ב-5.1"]
    q1 -->|CIM cmdlets| cur["זמין גם ב-5.1"]
    old --> del["הוסר ב-PowerShell 7"]
    del --> rew["שכתוב במיגרציה"]
    cur --> norew["אין עלות מיגרציה"]

איור 5: כתיבה חדשה ב-CIM cmdlets חוסכת שכתוב כשמגרים ל-PowerShell 7.

4. שאילתות remote —‏ CIM session (WSMan כברירת מחדל) ואפשרות DCOM

אם לא מציינים יעד, CIM cmdlets מתחברים ל-WMI המקומי ב-COM; אם מציינים -ComputerName, הם יוצרים session זמני בפרוטוקול WSMan (WinRM) כדי להתחבר. כשמבצעים כמה פעולות מול אותו מחשב, יצירת CIM session ושימוש חוזר בו עדיפה לביצועים.³

flowchart TB
    accTitle: בחירת אופן החיבור של CIM
    accDescr: בלי ציון מתחברים ב-COM ל-WMI המקומי, עם ComputerName נוצר session זמני של WSMan בכל שאילתה, כמה פעולות לאותו יעד מרוויחות משימוש חוזר ב-New-CimSession, וליעד בלי WinRM יש אפשרות פרוטוקול DCOM
    exec["הרצת CIM cmdlet"] --> q1{"צוין ComputerName?"}
    q1 -->|אין| local["חיבור COM ל-WMI מקומי"]
    q1 -->|כן| q2{"כמה פעולות לאותו יעד?"}
    q2 -->|חד-פעמי| temp["session זמני של WSMan"]
    q2 -->|כמה| sess["שימוש חוזר ב-New-CimSession"]
    temp -.-> cost["נוצר בכל שאילתה"]
    nowinrm["יעד בלי WinRM"] -.-> dcom["אפשרות פרוטוקול DCOM"]

איור 6: שאילתה remote ברירת המחדל שלה WSMan, ולכמה פעולות מול אותו יעד שימוש חוזר ב-CIM session הוא הנוהג.

# לשאילתה חד-פעמית משתמשים ב-ComputerName (session זמני נוצר בכל פעם)
Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName Server01, Server02

# לשאילתות חוזרות משתמשים שוב ב-CIM session
$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

התנאים המוקדמים לשאילתה remote הם אלה.

• WinRM חייב להיות מוגדר ביעד. winrm quickconfig מגדיר את השירות להפעלה אוטומטית, יוצר HTTP listener (פורט ברירת מחדל 5985) ורושם חריג firewall, הכול בפעם אחת.¹⁰ אם רוצים להתחבר ב-HTTPS (פורט ברירת מחדל 5986), זה לבדו לא מספיק — צריך להכין certificate של שרת ולהגדיר בנפרד HTTPS listener, למשל ב-winrm quickconfig -transport:https.¹⁰
• הפורטים הרלוונטיים חייבים להיות פתוחים ב-firewall בדרך. עבודת התכנון והרישום של inbound rules מכוסה במאמר “Windows Firewall ואפליקציות עסקיות”.
• אימות. בסביבת domain, Kerberos מספק mutual authentication. ב-workgroup אין Kerberos, וייתכן שצריך לרשום את היעד ב-TrustedHosts של הלקוח. מצמצמים את הרשימה ככל האפשר.¹⁰
• הרשאות. בתצורת ברירת המחדל, שאילתות ופעולות WMI remote נעשות בחשבון ששייך לקבוצת Administrators של היעד. כדי לפתוח זאת למשתמשים רגילים צריך להגדיר הרשאות גישה גם ב-WinRM וגם ב-namespace של WMI.¹⁰
• שימו לב של-DCOM אין פורט האזנה קבוע (הוא משתמש בפורטים דינמיים של RPC), ולכן קשה יותר לתכנן אותו מעבר ל-firewall. בטוח להניח WSMan כברירת מחדל לכל דבר שבונים מעתה.

flowchart TB
    accTitle: אישור התנאים המוקדמים לשאילתה remote
    accDescr: ביעד winrm quickconfig מגדיר הפעלה אוטומטית של השירות, יוצר HTTP listener ורושם חריג firewall בפעם אחת, HTTPS listener מוגדר בנפרד אחרי הכנת certificate, ובסביבת workgroup לעיתים נדרש רישום ב-TrustedHosts
    qc["winrm quickconfig"] --> svc["הפעלה אוטומטית של השירות"]
    qc --> lis["יצירת HTTP listener (5985)"]
    qc --> fw["חריג firewall"]
    lis ~~~ https["HTTPS listener (5986)"]
    https -.-> cert["מכינים certificate ומגדירים בנפרד"]
    fw ~~~ wg["סביבת workgroup"]
    wg -.-> th["רישום ב-TrustedHosts"]

איור 7: winrm quickconfig מבצע את תצורת ברירת המחדל בפעם אחת; HTTPS listener ואימות ב-workgroup דורשים טיפול נפרד.

5. שימוש מ-C# — System.Management מול Microsoft.Management.Infrastructure

יש שתי שושלות API לשימוש ב-WMI מ-C#. שתיהן ייעודיות ל-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 דרך indexer, לכן צריך לבדוק בתיעוד ה-class את טיפוס CIM (בדוגמה הזאת FreeSpace / Size הם uint64⁹) ולהמיר בהתאם. להניח שזה int ולהמיר על בסיס ההנחה, עד שמקבלים InvalidCastException, היא המעידה הקלאסית הראשונה כאן.

flowchart TB
    accTitle: מלכודת שליפת מאפיין והמרה
    accDescr: מאפיינים ב-System.Management חוזרים כ-object דרך indexer, לכן צריך לאשר את טיפוס CIM בתיעוד ולהמיר, והמרה מתוך הנחה שזה int גורמת ל-InvalidCastException
    idx["שליפה ב-indexer"] --> obj["חוזר כ-object"]
    obj --> chk["אישור טיפוס CIM בתיעוד"]
    chk --> cast["המרה לטיפוס הנכון"]
    obj -.-> wrong["המרה מתוך הנחה שזה int"]
    wrong -.-> ex["InvalidCastException"]

איור 8: מאפיינים חוזרים כ-object, לכן מאשרים את טיפוס CIM לפני המרה.

5.2. MI API: היסודות של CimSession

CimSession מטפל בגישה מקומית ו-remote באותה צורה. יש בו מנייה, שאילתה, קריאת מתודה, Subscribe לאירועים וגרסאות async במקום אחד.⁶

// NuGet: Microsoft.Management.Infrastructure (Windows בלבד)
using Microsoft.Management.Infrastructure;

// CimSession.Create(null) למקומי, או שם מחשב ל-remote
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 ש-CIM cmdlets של PowerShell מחזירים, זרימת פיתוח של “מנסים ב-PowerShell ואז מעתיקים ל-C#” מתחברת באופן טבעי. אם מתכננים את שילוב C# ו-PowerShell עצמו, ראו גם “איך להריץ PowerShell מ-C# (CSharp) ולקבל את התוצאות כאובייקטים”.

flowchart TB
    accTitle: ניסוי ב-PowerShell והעתקה ל-C#
    accDescr: CIM cmdlets של PowerShell ו-MI API ב-C# מטפלים באותו טיפוס CimInstance, לכן זרימת פיתוח שמנסה ב-PowerShell ואז מעתיקה ל-C# מתחברת באופן טבעי
    trial["ניסוי ב-PowerShell"] --> gci["CIM cmdlets"]
    impl["מימוש מלא ב-C#"] --> mi["MI API"]
    gci --> ci["אותו טיפוס CimInstance"]
    mi --> ci
    ci -.-> flow["ההעתקה מתחברת באופן טבעי"]

איור 9: CIM cmdlets ו-MI API מטפלים באותו CimInstance, לכן ניסוי מוביל למימוש מלא.

6. מתכונים נפוצים בפועל

6.1. טבלת עזר ל-classes נפוצות

6.2. הקלאסיקה של ניהול נכסים: serial number, שם דגם ודיסק פנוי

# מידע דגם ו-serial number (להצלבה מול ספר נכסי מחשבים)
$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 מייצג “דיסק מקומי”, ומחריג removable (2), כונני רשת (4) ו-CD (5).⁹ לניטור, די להריץ את הסקריפט הזה לכל שרת דרך CIM session כדי לקבל את הבסיס לניטור דיסק בלי agent.

flowchart TB
    accTitle: הבסיס לניטור דיסק בלי agent
    accDescr: סינון DriveType 3 מחריג removable, כונני רשת ו-CD ומשאיר רק דיסקים מקומיים, ואותו סקריפט מועבר לכל שרת דרך CIM session וכך נוצר בסיס לניטור דיסק בלי agent
    scr["סקריפט שליפת שטח פנוי"] --> flt["מסננים ב-DriveType = 3"]
    flt -.-> exc["מחריגים removable וכדומה"]
    scr --> ses["דרך CIM session"]
    ses --> srvs["מעבירים לכל שרת"]
    srvs --> mon["ניטור בלי agent"]

איור 10: סקריפט שמסונן לדיסקים מקומיים ומועבר לכל שרת ב-CIM session הוא הבסיס לניטור.

6.3. זיהוי process שהתחיל — event subscription

במקום “לשלוף Win32_Process במחזור polling ולהשוות הפרשים”, משתמשים ב-event subscription. הדרך הפשוטה לתפוס process שהתחיל היא Subscribe ל-Win32_ProcessStartTrace (event class של kernel trace provider, עם מאפיינים כמו ProcessName / ProcessID / ParentProcessID⁸).

# להריץ מסשן PowerShell מוגבה (Administrator)
$action = {
    $name = $Event.SourceEventArgs.NewEvent.ProcessName
    $id   = $Event.SourceEventArgs.NewEvent.ProcessID
    Write-Host "process התחיל: $name (PID=$id)"
}
Register-CimIndicationEvent -ClassName Win32_ProcessStartTrace `
    -SourceIdentifier ProcessStarted -Action $action

ה-subscription נשאר חי כל עוד session PowerShell שרשם אותו חי, ו--Action רץ בכל פעם ש-process מתחיל. זהירים לא להריץ את פקודת הביטול מיד אחר כך באותה אצווה — זה פשוט גורם ל-subscription להיעלם לפני שהניטור בכלל מתחיל. את שלב הביטול מריצים רק כשמסיימים את הניטור.

# כשמסיימים את הניטור: מסירים את ה-subscription
Unregister-Event -SourceIdentifier ProcessStarted

Register-CimIndicationEvent רושם subscription לפי שם class או לפי שאילתת event ב-WQL, ובלוק הסקריפט של -Action רץ בכל הגעה של event.⁷ Subscribe ל-class הזאת דורש הרשאות Administrator.⁷ מי יכול לקבל את ה-event נשלט ב-security descriptor של ה-event class, ומשתמש רגיל בלי הרשאות מוגבהות יידחה.⁸

sequenceDiagram
    accTitle: זרימת event subscription להפעלת process
    accDescr: ב-session PowerShell בהרשאות Administrator Register-CimIndicationEvent רושם subscription, בכל process שהתחיל מגיע event ו-Action רץ, ובסיום הניטור Unregister-Event מבטל
    participant ps as session PowerShell
    participant wmi as WMI
    ps->>wmi: רישום subscription ב-Register-CimIndicationEvent
    Note over ps: הרצה בהרשאות Administrator
    wmi-->>ps: event מגיע בכל process שהתחיל
    ps->>ps: הרצת -Action
    ps->>wmi: ביטול ב-Unregister-Event (בסיום הניטור)

איור 11: ה-subscription תקף כל עוד ה-session שרשם אותו חי, והביטול נעשה כשמסיימים את הניטור.

דרך נוספת היא instance creation event הכללי (__InstanceCreationEvent), שניתן לשימוש עם כל class. כאן WMI עושה polling במרווח שמציינים ב-WITHIN והופך את ההפרש ל-event, לכן את הפשרה בין מרווח הזיהוי לעומס מחליטים בעצמכם.

flowchart TB
    accTitle: שני אופני subscription לזיהוי process שהתחיל
    accDescr: Win32_ProcessStartTrace הוא Subscribe ל-event class של kernel trace provider, ו-__InstanceCreationEvent הכללי הוא מנגנון שבו WMI עושה polling במרווח WITHIN והופך הפרש ל-event, לכן את הפשרה בין מרווח לעומס מחליטים בעצמכם
    goal["זיהוי process שהתחיל"] --> t1["Win32_ProcessStartTrace"]
    goal --> t2["__InstanceCreationEvent"]
    t1 -.-> k1["Subscribe ל-kernel trace"]
    t2 -.-> w1["polling במרווח WITHIN"]
    w1 -.-> tr["פשרה בין מרווח לעומס"]

איור 12: Subscribe ל-event class ייעודית, או instance creation event כללי עם מרווח polling.

# ניטור מופעי Win32_Process חדשים ב-polling כל 5 שניות
$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;

// מ-process שרץ כ-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($"process התחיל: {name} (PID={pid})");
};
watcher.Start();
// בסיום הניטור לא שוכחים watcher.Stop() ו-Dispose

אם בונים זאת לרכיב ניטור קבוע, התכנון צריך לכלול גם רישום מחדש כשה-subscription נופל (ב-restart של service או בשגיאה). שיקולי התכנון של “בדיקה והצגה של מצב”, כולל ניטור התקנים, מכוסים ב”שיטות עבודה מומלצות לבדיקה ולהצגה של מצב התקן חיצוני”.

stateDiagram-v2
    accTitle: מחזור חיי ה-subscription בניטור קבוע
    accDescr: בניטור קבוע מצב ה-subscription עלול להיקטע ב-restart של service או בשגיאה, לכן כוללים בתכנון זיהוי של הניתוק, רישום מחדש וחזרה ל-subscription
    s1: ב-subscription
    s2: ה-subscription נקטע
    s3: רישום מחדש
    [*] --> s1
    s1 --> s2: restart של service או שגיאה
    s2 --> s3
    s3 --> s1

איור 13: בניטור קבוע כוללים בתכנון רישום מחדש כשה-subscription נקטע, כדי לחזור למצב subscription.

7. מלכודות — ביצועים, הרשאות, 64bit, repository ותאריכים

7.1. SELECT * וסערת polling

שאילתת WMI היא “provider שבונה את הערכים במקום” — היא לא בחינם. יש שני דפוסי-נגד קלאסיים.

• שימוש ב-SELECT * מתוך הרגל. שליפת כל מאפיין של כל שורה ב-Win32_Process מנפחת בהתאם את עבודת ה-provider ואת ההעברה ברשת (כש-remote). מסננים שורות ב--Filter, עמודות ב--Property, ומשתמשים ב--KeyOnly אם כל מה שצריך הוא keys לפעולה המשך. כולם אמצעים רשמיים שנועדו “להקטין את גודל האובייקטים ואת תעבורת הרשת”.³
• polling במרווח קצר. תכנון כמו “Get-CimInstance Win32_Process כל שנייה” מחליפים ב-event subscription מסעיף 6.3. גם אם חייבים סגנון polling (WITHIN), מרחיבים את המרווח למה שבאמת מספיק לדרישה.

גם חזרה על -ComputerName יעד-יעד מול מכונות remote בזבזנית, כי session זמני נוצר בכל שאילתה — עוברים לשימוש חוזר ב-CIM session לכמה פעולות.³

flowchart TB
    accTitle: דפוסי-נגד של ביצועים ולאן מחליפים אותם
    accDescr: שימוש מתוך הרגל ב-SELECT כוכבית מסננים ב-Filter ו-Property וב-KeyOnly אם צריך רק keys, polling במרווח קצר מחליפים ב-event subscription, וחזרה על ComputerName מכונה-מכונה מחליפים בשימוש חוזר ב-CIM session
    a1["שימוש מתוך הרגל ב-SELECT *"] --> f1["מסננים ב-Filter ו-Property"]
    f1 -.-> f2["רק keys: KeyOnly"]
    a2["polling במרווח קצר"] --> f3["מחליפים ב-event subscription"]
    a3["ComputerName מכונה-מכונה"] --> f4["שימוש חוזר ב-CIM session"]

איור 14: סינון שורות, עמודות ו-keys והחלפה ב-event subscription מונעים כמחצית מבעיות הביצועים של WMI.

7.2. הרשאות ל-event subscription

כמפורט בסעיף 6.3, Subscribe למשפחת Win32_ProcessStartTrace מניח הרשאות Administrator.⁷ “עבד במכונת הפיתוח (הרצה כ-Administrator), אבל הניטור לא עובד בסביבת המשתמש הרגיל אצל הלקוח” הוא כשל קלאסי, לצד דיאלוג ההתראה של ה-firewall. אם בונים ניטור לאפליקציה עסקית שרצה כמשתמש רגיל, שוקלים להפריד את חלק הניטור ל-Windows service (שרץ כ-LocalSystem, למשל) ולחבר אותו לאפליקציה הראשית ב-IPC.

flowchart TB
    accTitle: תצורת ניטור בסביבת משתמש רגיל
    accDescr: subscription שמניח הרשאות Administrator מוצא מגוף האפליקציה שרצה כמשתמש רגיל, חלק הניטור מופרד ל-Windows service שרץ כ-LocalSystem וכדומה, והגוף מחובר אליו ב-IPC
    svcm["Windows service לניטור"] --> subm["Subscribe למעקב הפעלה"]
    svcm -.-> lsm["רץ כ-LocalSystem וכדומה"]
    appm["גוף האפליקציה (משתמש רגיל)"] ---|IPC| svcm

איור 15: subscription שדורש הרשאות Administrator מופרד לצד ה-service, וגוף האפליקציה מחובר ב-IPC.

7.3. 32bit/64bit ו-providers

ב-Windows 64bit חלק מה-providers קיימים גם בגרסת 32bit וגם בגרסת 64bit, וכברירת מחדל הגרסה שתואמת לביטיות של הקורא עונה.¹² הדוגמה הקלאסית היא Registry provider (StdRegProv) תחת root\default: קריאה מאפליקציית 32bit מחזירה ערכים מצד Wow6432Node (תצוגת 32bit).¹² אם “ערך Registry שנקרא דרך WMI לא תואם למה ש-regedit מראה”, זה הדבר הראשון לחשוד בו. אם צריך את התצוגה השנייה, אפשר לבקש אותה במפורש בהגדרת __ProviderArchitecture (ואם רוצים לכפות, __RequiredArchitecture) בהקשר החיבור.¹² התמונה הכללית של בעיות ביטיות מכוסה גם ב”קריאה בטוחה ל-Win32 API מ-C# — מדריך מעשי ל-P/Invoke”.

flowchart TB
    accTitle: בחירת provider בסביבת 64bit
    accDescr: כברירת מחדל עונה ה-provider שתואם לביטיות של האפליקציה הקוראת, שאילתת Registry מאפליקציית 32bit מקבלת ערכים מצד Wow6432Node, אבל ציון __ProviderArchitecture מבקש במפורש את התצוגה השנייה
    q1{"מה ביטיות הקורא?"} -->|32bit| p32["provider 32bit עונה"]
    q1 -->|64bit| p64["provider 64bit עונה"]
    p32 -.-> wow["Registry הוא ערך מצד Wow6432Node"]
    ctx["ציון __ProviderArchitecture"] -.-> ov["בקשה מפורשת לתצוגה השנייה"]

איור 16: כברירת מחדל עונה הצד שתואם לביטיות הקורא, ולכן אפליקציית 32bit קוראת את צד Wow6432Node.

7.4. תסמינים וטיפול כש-WMI repository פגום

הגדרות ה-class של WMI מאוחסנות ב-repository (לא קובץ יחיד — הקבצים בתיקיית Repository יחד מתפקדים כמסד נתונים¹³). כשהוא הופך ללא-עקבי, מתחילות להופיע שגיאות כמו “class שאמורה להתקיים לא נמצאת” או “ה-namespace אינו תקף”, אף שמצד האפליקציה לא השתנה דבר. משתמשים ב-winmgmt.exe לאבחון ולתיקון.¹³

rem בדיקת עקביות (תוצאה inconsistent פירושה שיש בעיה)
winmgmt /verifyrepository

rem בדיקת עקביות, ובנייה מחדש אם יש בעיה (תוכן קריא ממוזג)
winmgmt /salvagerepository

החשוב הוא לא להפוך מחיקה או איפוס של ה-repository למהלך הראשון. שגיאות שעולות דרך WMI יכולות לנבוע ממקום אחר במערכת, ו-Microsoft עצמה אומרת במפורש שמחיקת ה-repository כתגובה ראשונה “עלולה לגרום לנזק למערכת או לאפליקציות מותקנות”.¹³ שומרים על הסדר: בדיקה ב-/verifyrepository, ואז תיקון ב-/salvagerepository.

flowchart TB
    accTitle: הליך הבירור לחוסר עקביות ב-WMI repository
    accDescr: כשעולה שגיאה כמו class שלא נמצאת מאשרים עקביות ב-verifyrepository של winmgmt, אם אין עקביות בונים מחדש ב-salvagerepository, ולא הופכים מחיקה או איפוס של ה-repository למהלך הראשון
    sym["שגיאה כמו class שלא נמצאת"] --> verify["winmgmt /verifyrepository"]
    verify --> q1{"התוצאה inconsistent?"}
    q1 -->|כן| salvage["winmgmt /salvagerepository"]
    q1 -->|לא| other["חשודים בגורם אחר במערכת"]
    salvage -.-> merge["תוכן קריא ממוזג"]
    del["מחיקה או איפוס של ה-repository"] -.-> ng["לא המהלך הראשון"]

איור 17: שומרים על הסדר verify ואז salvage, ולא הופכים מחיקה למהלך הראשון.

7.5. המרת פורמט תאריך DMTF

תאריכי WMI מאוחסנים כמחרוזות בפורמט DMTF שמוגדר במפרט CIM: yyyymmddHHMMSS.mmmmmm±UUU (הסיומת היא offset מ-UTC בדקות — למשל 20260801100000.000000+540). לא חותכים ומרכיבים את הערך הגולמי בעיבוד מחרוזות; משתמשים ב-API ההמרה.

• C# (System.Management): ManagementDateTimeConverter מספק המרה בין פורמט DMTF ל-DateTime / TimeSpan.¹¹
• API ממשפחת CIM (Get-CimInstance / MI API): מאפייני תאריך חוזרים כבר מומרים ל-DateTime, ולכן הבעיה הזאת כלל לא מתעוררת. אפשר להשתמש ב-(Get-CimInstance Win32_OperatingSystem).LastBootUpTime ישירות כ-DateTime בחישובים.

flowchart TB
    accTitle: טיפול בפורמט תאריך DMTF
    accDescr: תאריכי WMI מאוחסנים כמחרוזת בפורמט DMTF, אם קוראים ערך גולמי ב-System.Management ממירים ב-ManagementDateTimeConverter, וב-API ממשפחת CIM חוזר DateTime שכבר הומר, לכן לא חותכים ומדביקים מחרוזות ביד
    dmtf["מחרוזת בפורמט DMTF"] --> q1{"באיזה API נשלף?"}
    q1 -->|System.Management| conv["ManagementDateTimeConverter"]
    q1 -->|API ממשפחת CIM| done["חוזר כבר כ-DateTime"]
    conv --> dtv["המרה ל-DateTime / TimeSpan"]
    cut["חיתוך והדבקה ביד"] -.-> ng["לא משתמשים"]

איור 18: המרת מחרוזת DMTF מושארת ל-API ההמרה, וב-API ממשפחת CIM משתמשים ב-DateTime שכבר הומר.

8. מתי לא להשתמש ב-WMI — טבלת החלטה

WMI מצוין כ”ממשק קריאה אחיד”, אבל הוא לא תמיד הבחירה המיטבית. כלל אצבע מעשי לבחירה בין כלים.

כלל האצבע פשוט: משתמשים במנגנון הייעודי במקום שיש אחד, ושומרים את WMI/CIM לשאילתות רוחביות ולשאילתות remote. הדוגמה Get-NetFirewallRule בשורה האחרונה היא, פנימית, סט cmdlets שנבנה מעל CIM — מקרה של “לקבל את התועלת של WMI/CIM בלי לגעת בו ישירות”.

flowchart TB
    accTitle: ציר ההחלטה בין האמצעים
    accDescr: במקום שיש מנגנון ייעודי משתמשים במנגנון הייעודי, ובמקום שאין — בשאילתה רוחבית או remote — משתמשים ב-WMI וב-CIM, ו-CIM cmdlets ייעודיים הם צורה שמקבלת את התועלת בלי לגעת ב-WMI וב-CIM ישירות
    q1{"יש מנגנון ייעודי?"} -->|יש| ded["משתמשים במנגנון הייעודי"]
    q1 -->|אין| wmi["משתמשים ב-WMI / CIM"]
    wmi -.-> use["שאילתה רוחבית או remote"]
    cmd["CIM cmdlets ייעודיים"] -.-> ben["צורה שמקבלת רק את התועלת"]

איור 19: במקום שיש מנגנון ייעודי משתמשים בייעודי, ולשאילתה רוחבית ו-remote משתמשים ב-WMI/CIM.

9. סיכום

• CIM הוא תקן התעשייה של DMTF, ו-WMI הוא המימוש של Microsoft. גם CIM cmdlets של PowerShell וגם MI API ב-C# הם נקודות כניסה מדור נוכחי שעוקבות אחרי התקן.
• ב-PowerShell, Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent הם הנוכחיים. Get-WmiObject ו-WMI cmdlets האחרים אינם קיימים ב-PowerShell 7, לכן סקריפטים חדשים נכתבים בצד CIM גם אם היעד הוא 5.1.
• שאילתה remote ברירת המחדל שלה WSMan (WinRM), ולכמה פעולות משתמשים שוב ב-CIM session. ליעד שבו WinRM אינו מוגדר, DCOM הוא נתיב מילוט זמין.
• ב-C# בוחרים בין System.Management (נוח, מוכוון מקומי) ל-Microsoft.Management.Infrastructure (מוכוון remote וניטור, עם מערכת הטיפוסים של CIM cmdlets). שתיהן חבילות NuGet ייעודיות ל-Windows.
• מנטרים processes ב-event subscription, לא ב-polling. Subscribe ל-Win32_ProcessStartTrace דורש הרשאות Administrator.
• נמנעים מ-SELECT * ומ-polling במרווח קצר — מסננים ב--Filter / -Property / -KeyOnly. זוכרים ששאילתה מ-process 32bit נענית על ידי provider 32bit, שתאריכי DMTF צריכים את API ההמרה, וש-repository פגום מטופל בסדר verify → salvage, לא במחיקה.
• לא מכניסים WMI לתחום שכבר יש לו מנגנון ייעודי (הגדרות, performance counters, קריאות API חד-פעמיות) — שומרים את WMI/CIM לשאילתות רוחביות ולשאילתות remote. המשפט הזה מסכם את מקומו.

מאמרים קשורים

• איך להריץ PowerShell מ-C# (CSharp) ולקבל את התוצאות כאובייקטים
• מתכוני פקודות PowerShell מעשיים — להרחיב את הכלים הקטנים שבשימוש יום-יומי
• ההבדלים בין Windows PowerShell 5.1 ל-PowerShell 7 — מדריך מעשי למיגרציית סקריפטים פנימיים
• שיטות עבודה מומלצות לבדיקה ולהצגה של מצב התקן חיצוני - תכנון שלא מסתפק ב”מחובר”
• קריאה בטוחה ל-Win32 API מ-C# — מדריך מעשי ל-P/Invoke (DllImport / LibraryImport / CsWin32)
• מהו TPM ב-Windows? — מדריך מאויר ל”כספת שלא מוציאה מפתחות” ול-Measured Boot

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בבניית שליפת מידע חומרה, ניטור process ושאילתות מחשב remote עם WMI/CIM לתוך אפליקציות עסקיות, במיגרציית סקריפטים פנימיים מבוססי Get-WmiObject ל-CIM cmdlets, ובחקירת הבעיה מהסוג “עובד במכונת הפיתוח ונכשל בשגיאת הרשאות אצל הלקוח”. אפשר ללוות את כל הנתיב מניסוי ב-PowerShell עד מימוש מלא ב-C#.

• פיתוח אפליקציות Windows
• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה ההבדל בין WMI ל-CIM?

CIM הוא מודל התקן התעשייתי לייצוג יעדי ניהול כמו מערכות והתקנים, ש-DMTF (Distributed Management Task Force) מגדיר ומתחזק. WMI הוא המימוש של Microsoft ל-WBEM — יוזמה שמשתמשת בתקן הזה — והוא מובנה ב-Windows. כלומר CIM הוא המפרט, ו-WMI הוא המימוש ב-Windows. Get-CimInstance ב-PowerShell ו-Microsoft.Management.Infrastructure ב-C# נקראים CIM כי הם API שעוקבים אחרי התקן, אבל הם מתחברים לאותה תשתית WMI. בפיתוח יום-יומי מספיק להבין ששואלים classes של WMI (Win32_* וכדומה) דרך API ממשפחת CIM.

אפשר עדיין להשתמש ב-Get-WmiObject?

ב-Windows PowerShell 5.1 הוא עדיין רץ, אבל מ-PowerShell 6 ואילך (כולל PowerShell 7 הנוכחי) cmdlets של WMI v1 —‏ Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Set-WmiInstance ו-Remove-WmiObject — הוסרו ואי אפשר להריץ אותם. אותה פונקציונליות מגיעה ממודול CimCmdlets (Get-CimInstance / Invoke-CimMethod / Register-CimIndicationEvent וכדומה). בסקריפטים חדשים בטוח יותר לכתוב ב-CIM cmdlets גם אם הם ירוצו תחת 5.1. כך אין צורך לשכתב את חלק ה-WMI כשמגרים אחר כך ל-PowerShell 7.

כדי לגשת ל-WMI מ-C#, להשתמש ב-System.Management או ב-Microsoft.Management.Infrastructure?

שניהם ייעודיים ל-Windows, ומה-.NET הנוכחי מביאים אותם כחבילות NuGet. System.Management הוא ה-API הקלאסי: מעבירים WQL ל-ManagementObjectSearcher, והוא מספיק אם עיקר העבודה היא שליפת מידע מקומי. גם ManagementDateTimeConverter להמרת תאריכי DMTF נמצא שם. Microsoft.Management.Infrastructure (MI API), לעומת זאת, חולק את אותה מערכת טיפוסים (CimSession / CimInstance) עם CIM cmdlets של PowerShell, ומטפל באופן עקבי בשאילתות remote דרך WSMan, בגרסאות async של מתודות וב-Subscribe לאירועים. אם בונים שאילתות וניטור של מחשבים remote למוצר של ממש, הבחירה ב-MI API היא ההחלטה הסבירה.

Get-CimInstance לא מתחבר למחשב remote. מה לבדוק?

קודם בודקים אם WinRM מוגדר במכונת היעד. פעולת CIM עם -ComputerName יוצרת session זמני בפרוטוקול WSMan (WinRM), ולכן מניחה ששירות WinRM ו-listener רצים ביעד. winrm quickconfig מבצע את תצורת ברירת המחדל (הפעלת השירות, יצירת listener וחריג firewall). פורטים ברירת המחדל הם 5985 ל-HTTP ו-5986 ל-HTTPS, לכן בודקים גם firewall בדרך. בסביבת workgroup אין mutual authentication ב-Kerberos, וייתכן שצריך לרשום את היעד ב-TrustedHosts של הלקוח. ליעד שאי אפשר בכלל להגדיר בו WinRM אפשר במקום זאת להתחבר ב-DCOM עם option שנוצרה ב-New-CimSessionOption -Protocol Dcom.

למה תאריך WMI חוזר בפורמט כמו 20260801100000.000000+540?

תאריכי WMI מאוחסנים במחרוזת שמוגדרת במפרט CIM של DMTF (yyyymmddHHMMSS.mmmmmm±UUU, והסיומת היא offset מ-UTC בדקות). אם קוראים את הערך הגולמי עם Get-WmiObject הישן או עם System.Management, מקבלים את המחרוזת כמו שהיא. ב-C# (System.Management) מספק ManagementDateTimeConverter מתודות המרה בין פורמט DMTF ל-DateTime / TimeSpan, לכן משתמשים בהן במקום לחתוך את המחרוזת ביד. כששולפים דרך API ממשפחת CIM כמו Get-CimInstance, מאפייני תאריך כבר חוזרים מומרים ל-DateTime, ולכן הבעיה הזאת כלל לא מתעוררת.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.