מעמקי הקלט/פלט ב-Windows (פרק 6, אחרון) — מנהלי מסנן ומיניפילטר: למה Procmon וסורקי אנטי-וירוס יכולים להתערב בקלט/פלט

זה הפרק האחרון בסדרה «מעמקי הקלט/פלט ב-Windows».

מאז שפרק 1 צייר בתיבה «מסנני מערכת קבצים (אנטי-וירוס, הצפנה, Procmon וכדומה)» בתרשים מחסנית ההתקנים, אלה שיושבים באמצע הופיעו שוב ושוב לאורך הסדרה: למה Procmon יכול לרשום כל פעולת קלט/פלט (פרק 1); «גישה לקבצים איטית רק בסביבה אחת» (פרק 2); נקודת ה-reparse שגורמת ל-OneDrive להתחיל הורדה ברגע שקובץ נפתח (פרק 5). הפרק הזה סוף סוף פונה חזיתית למנגנון ההתערבות עצמו — מנהלי מסנן של מערכת קבצים ומיניפילטר — וסוגר כל חוט שהסדרה השאירה תלוי.

1. השורה התחתונה קודם

• «התערבות בקלט/פלט» היא נקודת הרחבה שמערכת ההפעלה מאשרת רשמית. מסנן מערכת קבצים יכול לראות, לשכתב, לדחות או לטפל במקום מערכת הקבצים בקשה שנעשית למערכת הקבצים (פרק 2).¹
• התקן הנוכחי הוא המיניפילטר. כדי לפתור את בעיות הגישה הישנה שהתערבה ישירות במחסנית ההתקנים (סדר בלתי ניתן לניבוי, אין דרך לפרוק), המודל החליף דור לאחד שרושם קריאות חוזרות אצל מנהל המסננים (FltMgr) שמגיע עם Windows (פרק 2).²³
• המכניקה היא קריאות חוזרות pre/post. לפני ואחרי כל פעולה, מסננים נקראים לפי סדר הרישום — כלומר סדר הגובה. העברה, השלמה, דחייה, שכתוב — «הבחירות שיש למנהל» מפרק 1 חלות ישירות (פרק 3).²
• הגובה (altitude) קובע את הסדר. לכל קבוצה לפי ייעוד מוקצה טווח מספרי (Activity Monitor 360000–389999, Anti-Virus 320000–329999 וכו’), ולכל מופע שמחובר לכרך ניתן מספר ייחודי בתוכו (פרק 4).⁴⁵
• אפשר לראות מי גר במחשב שלכם ב-fltmc. Procmon (רק בזמן שהוא רץ), תוכנת אנטי-וירוס, מסנן הענן של OneDrive — כולם עומדים כאן בתור (פרק 5).
• הגדרת החרגה באנטי-וירוס פירושה «דילוג על הסריקה של המוצר עצמו» — אין לה השפעה על מיניפילטרים אחרים. החרגות מוותרות על הגנה, ולכרכי פיתוח יש אפשרות בטוחה יותר: Dev Drive (סריקה אסינכרונית) (פרק 6).⁶⁷
• חקירת «למה רק הסביבה הזו איטית» מתחילה בעמודת Duration של Procmon ובהשוואת תצורות fltmc (פרק 7).

מפת הידע של המאמר

הסטנדרט הנוכחי של מסנן מערכת קבצים הוא המיני-מסנן: בניגוד למסנן מדור קודם שמניח ישירות אובייקט התקן על מחסנית ההתקנים, הוא רושם callback מסוג pre/post אצל מנהל המסננים (FltMgr) שמגיע עם Windows. סדר הקריאה נקבע באופן דטרמיניסטי לפי האלטיטוד ש-Microsoft מקצה ומנהלת, ובפקודה fltmc אפשר לצפות בתצורה בפועל. אנטי-וירוס, ‏Procmon וסנכרון הענן של OneDrive הם כולם דיירים של אותו מנגנון; הגדרת החרגה מדלגת רק על הסריקה של המוצר עצמו ונושאת פשרה של החלשת ההגנה, ולכרכי פיתוח יש חלופה בטוחה יותר — Dev Drive.

flowchart LR
    accTitle: מפת הידע של מנהלי התקן מסנן ומיני-מסננים
    accDescr: תרשים שמראה את הקשרים בין מנהל התקן מסנן של מערכת הקבצים, חילופי הדורות ממסנן מדור קודם למיני-מסנן, מנהל המסננים (FltMgr), callback מסוג pre/post, אלטיטוד וקבוצות סדר טעינה, תצפית באמצעות fltmc, מיני-מסנן אנטי-וירוס והגדרות החרגה ו-Dev Drive, והמנגנון שבו Procmon כמיני-מסנן רושם את כל הקלט/פלט
    minifilter["מיני-מסנן"]
    filter_manager["מנהל המסננים (FltMgr)"]
    legacy_filter_driver["מסנן מדור קודם"]
    filesystem_filter_driver["מנהל התקן מסנן של מערכת הקבצים"]
    device_stack["מחסנית התקנים"]
    load_order_instability["אי-יציבות בסדר הטעינה"]
    minifilter_callback["callback מסוג pre/post"]
    altitude["אלטיטוד (altitude)"]
    load_order_group["קבוצת סדר טעינה"]
    fltmc["fltmc"]
    altitude_request["בקשת אלטיטוד"]
    procmon["Process Monitor(procmon.exe)"]
    antivirus_minifilter["מיני-מסנן של אנטי-וירוס"]
    cloud_filter["מסנן קבצי ענן (cldflt)"]
    onedrive_files_on_demand["קבצים לפי דרישה של OneDrive"]
    fast_io["Fast I/O"]
    scan_performance_cost["עלות ביצועים עקב סריקה"]
    exclusion_setting["הגדרת החרגה (החרגת תיקייה)"]
    reduced_protection["ירידה ברמת ההגנה"]
    dev_drive["Dev Drive"]
    frame["מסגרת FltMgr"]
    driver_object["אובייקט מנהל התקן"]
    legacy_filter_driver -->|"מממש את"| filesystem_filter_driver
    minifilter -->|"מממש את"| filesystem_filter_driver
    minifilter -->|"יורש את"| legacy_filter_driver
    legacy_filter_driver -->|"מחייב"| device_stack
    legacy_filter_driver -->|"עלול לגרום ל"| load_order_instability
    minifilter -.->|"מונע"| load_order_instability
    minifilter -->|"מחייב"| filter_manager
    filter_manager -->|"משתמש ב"| minifilter_callback
    minifilter -->|"משתמש ב"| minifilter_callback
    minifilter -->|"מוגדר באמצעות"| altitude
    altitude -->|"מוגדר באמצעות"| load_order_group
    altitude -->|"נבדק באמצעות"| fltmc
    altitude -.->|"מחייב"| altitude_request
    altitude_request -->|"צריך לקדום ל"| minifilter
    minifilter -->|"נבדק באמצעות"| fltmc
    legacy_filter_driver -->|"נבדק באמצעות"| fltmc
    procmon -->|"משתמש ב"| minifilter
    procmon -->|"משתמש ב"| minifilter_callback
    antivirus_minifilter -->|"משתמש ב"| minifilter_callback
    antivirus_minifilter -->|"מוגדר באמצעות"| altitude
    cloud_filter -->|"מאוטמט את"| onedrive_files_on_demand
    minifilter -.->|"משתמש ב"| fast_io
    antivirus_minifilter -.->|"עלול לגרום ל"| scan_performance_cost
    exclusion_setting -->|"מצמצם"| scan_performance_cost
    exclusion_setting -->|"עלול לגרום ל"| reduced_protection
    antivirus_minifilter -->|"מוגדר באמצעות"| exclusion_setting
    dev_drive -->|"מצמצם"| scan_performance_cost
    dev_drive -->|"מצמצם"| reduced_protection
    antivirus_minifilter -->|"מענה מומלץ ל"| dev_drive
    filter_manager -->|"משתמש ב"| frame
    frame -->|"נבדק באמצעות"| fltmc
    legacy_filter_driver -->|"משתמש ב"| driver_object
    minifilter -->|"משתמש ב"| driver_object
    filter_manager -->|"מחייב"| device_stack
    filter_manager -->|"משתמש ב"| driver_object

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 35, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. ההיסטוריה של אלה שמתערבים — ממסננים ישנים ל-FltMgr

מנהל מסנן של מערכת קבצים הוא מנהל שיכול לחטוף בקשות שפונות למערכת הקבצים (או לכרך שמתחתיה). הוא יכול לרשום בקשות, לנטר, לשנות תוכן, ואפילו לדחות או לטפל במקום — הבסיס לתוכנות אנטי-וירוס, הצפנה, גיבוי וזיכרון היררכי.¹

שיטת המימוש הישנה (מסנן ישן, legacy filter) הייתה לערם את אובייקט ההתקן שלה ישירות על מחסנית ההתקנים שראינו בפרק 1. כמנגנון זה ישר, אבל בפועל היה מלא בעיות — הסדר שבו ערמים תלוי בסדר הטעינה וקשה להבטיח, ואחרי שערמים אי אפשר לצאת בבטחה (אי אפשר לפרוק), וזה הפך לחממה לבאגים של תאימות בין מסננים.

לכן Windows הציג את מנהל המסננים (FltMgr). FltMgr עצמו עומד במחסנית כמסנן שמגיע עם מערכת ההפעלה, וכל פונקציית מסנן נרשמת כמיניפילטר אצל FltMgr בקריאות חוזרות.²

flowchart TB
    subgraph OLD["שיטה ישנה"]
        L1["מסנן ישן A"]
        L2["מסנן ישן B"]
        LFS1["מערכת קבצים"]
        L1 --> L2
        L2 --> LFS1
        NOTE1["הסדר תלוי בסדר הטעינה<br/>פריקה בטוחה אינה אפשרית"]
    end
    subgraph NEW["שיטת מיניפילטר（התקן הנוכחי）"]
        FM["מנהל המסננים（FltMgr）<br/>מצורף ל-OS. רק הוא עומד במחסנית"]
        M1["מיניפילטר A（גובה גבוה）"]
        M2["מיניפילטר B（גובה נמוך）"]
        LFS2["מערכת קבצים"]
        FM -. "רישום קריאות חוזרות" .- M1
        FM -. "רישום קריאות חוזרות" .- M2
        FM --> LFS2
        NOTE2["הסדר דטרמיניסטי לפי גובה<br/>טעינה בכל עת אפשרית<br/>（מסננים תומכים ניתנים גם לפריקה）"]
    end

איור 1: החלפת דור. לא «לערם» במחסנית, אלא «לרשום» אצל FltMgr

היתרונות של שיטת המיניפילטר מנויים רשמית — אפשר לטעון בכל עת, לשלוט בסדר, ומסנן שמממש קריאת חוזרת לפריקה יכול גם לפרוק בזמן ריצה (מסנן שלא מממש או שמסרב אי אפשר להסיר).³ לצורך דו-קיום עם מסננים ישנים FltMgr יכול לעמוד בכמה מקומות במחסנית ככמה «מסגרות» (frames), ולמיניפילטר מובטח שיחזור לאותו מיקום (אותו גובה) גם בטעינה מחדש אחרי פריקה.² אנטי-וירוס, ניטור וסנכרון מודרניים הם כמעט כולם המיניפילטר הזה.

3. תנועת המיניפילטר — קריאות חוזרות pre/post

מיניפילטר מכריז ל-FltMgr «באילו פעולות הוא מעוניין». למשל, מעוניין רק ב-IRP_MJ_CREATE (פתיחה) וב-IRP_MJ_WRITE (כתיבה). אז, בכל פעם שהפעולה הזו זורמת, נקראות לפני הפעולה (קריאת חוזרת pre) ואחרי הפעולה (קריאת חוזרת post).

sequenceDiagram
    participant IOM as מנהל הקלט/פלט
    participant FM as FltMgr
    participant A as מיניפילטר A<br/>（גובה גבוה）
    participant B as מיניפילטר B<br/>（גובה נמוך）
    participant FS as NTFS

    IOM->>FM: בקשה（IRP_MJ_CREATE וכו'. עולם פרק 1）
    FM->>A: קריאת חוזרת pre
    FM->>B: קריאת חוזרת pre
    FM->>FS: למערכת הקבצים
    FS-->>FM: תוצאת העיבוד
    FM-->>B: קריאת חוזרת post
    FM-->>A: קריאת חוזרת post
    FM-->>IOM: השלמה（לזרימת ההשלמה של פרק 1）

איור 2: קריאות חוזרות pre/post. בדרך הלוך לפי גובה גבוה קודם, בחזרה בסדר הפוך

מה אפשר לעשות בכל קריאת חוזרת. אותו מבנה של «שלוש הבחירות של מנהל» מפרק 1 סעיף 4.3 מסופק ב-API בטוח יותר.

flowchart TB
    PRE["נקראה קריאת חוזרת pre"]
    Q{"מה לעשות עם הפעולה הזו"}
    PASS["להעביר כמו שהיא<br/>（ואם אין צורך ב-post, גם מכריזים על זה）"]
    DENY["לדחות<br/>מחזירים מיד דחיית גישה וכו'<br/>דוגמה: זיהוי וירוס, איסור כתיבה"]
    DONE["להשלים בעצמם<br/>דוגמה: מסנן ענן<br/>משיג את הישות ומגיש אותה"]
    MOD["נוגעים בפרמטרים או בתוכן ומעבירים<br/>דוגמה: מסנן הצפנה"]
    PRE --> Q
    Q --> PASS
    Q --> DENY
    Q --> DONE
    Q --> MOD

איור 3: הבחירות בקריאת חוזרת pre. «לראות, לעצור, לקחת על עצמם, לשכתב» — הכול אפשרי רשמית

וכאן נסגר שיעורי הבית מפרק 4 — מיניפילטר יכול להיות נוכח גם ב-Fast I/O (קיצור שלא יוצר IRP). FltMgr מעביר את מנגנון הקריאות החוזרות גם בנתיב Fast I/O, כך שאין «לא רואים אם עוברים בקיצור» כמו בעידן הישן. הסיבה ששורות FASTIO_ עומדות גם ביומן Procmon היא בזכות המיקום הזה.

4. גובה — «הגובה מעל פני הים» קובע את הסדר

כשכמה מסננים מעוניינים באותה פעולה, מי רואה קודם היא שאלה חמורה. אם אנטי-וירוס לא רואה לפני הצפנה, הוא נאלץ לסרוק טקסט מוצפן, וכלי ניטור חייב להיות מעל כולם כדי לצפות בכול.

מה שקובע את הסדר הזה הוא גובה (altitude). לכל סוג מסנן מוגדרות קבוצת סדר טעינה וטווח מספרים. בדיוק, היחידה שמקבלת גובה אינה המנהל כולו אלא «המופע» של המיניפילטר שמחובר לכרך. המספר ייחודי, וככל שהוא גדול יותר כך המיקום גבוה יותר במחסנית (קרוב יותר ליישום).⁴ מנהל אחד יכול להחזיק כמה הגדרות מופע ולהופיע בגבהים שונים, ולכן רשימת fltmc instances היא לפי מופע.

flowchart TB
    APP["קרוב ליישום（מספר גדול）"]
    G1["FSFilter Activity Monitor: 360000〜389999<br/>תצפית ורישום קלט/פלט（Procmon כאן）"]
    G2["FSFilter Undelete: 340000〜349999<br/>שחזור קבצים שנמחקו"]
    G3["FSFilter Anti-Virus: 320000〜329999<br/>זיהוי וסילוק וירוסים"]
    G4["FSFilter Replication: 300000〜309999<br/>שכפול למרוחק"]
    G5["FSFilter Continuous Backup: 280000〜289999<br/>גיבוי מתמשך"]
    G6["עוד למטה: Content Screener /<br/>Quota Management / System Recovery /<br/>טווחי הצפנה, דחיסה וכו' ממשיכים"]
    FS["קרוב למערכת הקבצים（מספר קטן）"]
    APP --> G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> FS

איור 4: טווחי גובה (קטע). לכל ייעוד נקבע «הגובה שבו צריך לעמוד»

החשוב הוא שהמספר הזה מוקצה ומנוהל בידי Microsoft.⁵ ספקים אינם מכריזים על עצמם אלא מגישים בקשה ומקבלים — לכן בכל מחשב נשמר הסדר «ניטור מעל אנטי-וירוס, אנטי-וירוס מעל הצפנה». זה היה המענה ל«הגרלת סדר טעינה» של עידן ה-legacy.

לאן מגישים בקשה כשבונים מיניפילטר בחברה. למפתחים, רק הצעד הבא. גובה מגישים לפי הנוהל ב-Request a Filter Altitude Identifier, שולחים דוא״ל באנגלית ל-fsfcomm@microsoft.com עם נושא «Filter altitude request». צריך למלא הכול: שם חברה, פרטי קשר (כינוי חברה לטווח ארוך, לא אישי), שם מוצר, URL מוצר, תיאור המסנן, שם קובץ המנהל, סוג מסנן, סוג התחלה, קבוצת סדר הטעינה הרצויה והגובה הרצוי. מצוין גם שיש לצפות ל-30 ימי עבודה לעיבוד, שאין חלון טיפול דחוף, ושהמספר שיוקצה עשוי להיות שונה מהמבוקש.⁸ בנוסף, חברה שכבר יש לה גובה שלם באותה קבוצת סדר טעינה רשאית לקבוע בעצמה ערך עם שבר אחרי המספר הזה (למשל 325000.3), ואז די בדיווח בדוא״ל אחרי מעשה.⁸

5. היכרות עם הדיירים — המחשב שלכם דרך fltmc

די בתיאוריה. נראה את הדבר עצמו. בשורת פקודה עם הרשאות מנהל:

:: List of registered minifilters (with altitudes)
fltmc

:: Which filter is attached to which volume
fltmc instances

:: From the volume side
fltmc volumes

fltmc בלי ארגומנטים מוציא את אותה רשימה כמו fltmc filters. הפלט הוא 4 עמודות, וגם בתיעוד של Microsoft יש דוגמה באותה צורה.⁹

C:\Windows\system32>fltmc

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
bindflt                                 1        409800         0
cldflt                                  1        409500         0
WdFilter                                4        328010         0
luafv                                   1        135000         0
FileInfo                                4         45000         0

למעלה זה קטע להסבר. הרכב הפנים ומספר המופעים משתנים לפי סביבה, אבל ערכי הגובה הם ערכים קבועים ש-Microsoft הקצתה, ולכן אפשר להצליב מול הרשימה הציבורית שנגענו בה בפרק 4.

משמעות העמודות היא כך.

גם בחמש השורות האלה אפשר לקרוא ש-bindflt ו-cldflt נמצאים בטווח העליון FSFilter Top (400000–409999), WdFilter בטווח Anti-Virus (320000–329999), ו-FileInfo בטווח התחתון FSFilter Bottom (40000–49999). המבנה שראינו בפרק 4, «לכל ייעוד נקבע הגובה שבו צריך לעמוד», מאושר כאן במספרים. ואם מריצים fltmc שוב אחרי שהפעלתם Procmon, נוספת שורה שמתחילה ב-PROCMON בטווח Activity Monitor (360000–389999).

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

• WdFilter — המיניפילטר של Microsoft Defender. בטווח Anti-Virus. במחשבים רבים זה מחסום שכל קלט/פלט קבצים חייב לעבור.
• cldflt — מסנן קובצי ענן. יחידת הביצוע של קבצים לפי דרישה ב-OneDrive, ומכין את הישות כשנפתחת נקודת reparse (מציין מיקום) שראינו בפרק 5.¹⁰
• PROCMON24 (וכו’) — מיניפילטר זמני בטווח Activity Monitor שמופיע רק בזמן ש-Process Monitor רץ. זה סוד הקסם של למה Procmon רואה את כל הקלט/פלט.¹¹ נסו להריץ fltmc לפני ואחרי ההפעלה ולהשוות.
• מלבד אלה, תוכנות גיבוי, מוצרי הצפנה (מניעת דליפת מידע), EDR, אחסון וירטואלי — ככל שהמחשב עסקי יותר, כך הדיירים מתרבים.

כשמביטים מבחוץ על כלי Procmon שהשתמשנו בו מפרק 1, בפרק האחרון, מתקבל מעגל נקי: «גם הצופה היה דייר באותו מנגנון של מושא התצפית».

6. איפה אנטי-וירוס מבזבז זמן

ההשפעה המעשית הגדולה ביותר של מסננים היא עלות סריקת האנטי-וירוס. נצייר איפה הזמן נוצר (הפרטים משתנים לפי מוצר. להלן הצורה הטיפוסית).

sequenceDiagram
    participant App as יישום
    participant AV as מיניפילטר AV
    participant FS as NTFS

    App->>AV: פותח קובץ
    Note over AV: pre-create: שיפוט מוקדם של נתיב ומדיניות
    AV->>FS: מעביר（ביצוע הפתיחה）
    FS-->>AV: הפתיחה הצליחה（post-create）
    Note over AV: אם הקובץ טרם נסרק<br/>סורקים כאן את התוכן<br/>ואם יש בעיה מבטלים את הפתיחה<br/>── הסיבה העיקרית שפתיחה מתעכבת
    AV-->>App: אם אין בעיה, מוחזר handle
    App->>AV: כתיבה / סגירה
    Note over AV: קבצים ששונו<br/>הופכים ליעד לסריקה מחדש בסגירה וכו'
    Note over App,FS: בקבצים קטנים רבים（תוצרי ביניים של בנייה וכו'）<br/>ההלוך-ושוב הזה מצטבר לפי מספר הקבצים

איור 5: נקודות יצירת עלות הסריקה. לקובץ אחד זה זניח, אבל בעשרות אלפי קבצים זה הופך לשולט

מתוך זה אפשר להבין בדיוק שני נושאים מעשיים.

המשמעות הטכנית של הגדרת החרגה. בקלט/פלט בנתיב שתואם לרשימת ההחרגה, עיבוד הסריקה של המסנן מדולג. המסנן אינו נעלם מהמחסנית; המציאות היא שההחלטה «לא לבדוק» מתקבלת מוקדם יותר. ויש עוד מגבלה חשובה — ההחרגה חלה רק על המסנן של המוצר שמחזיק את ההגדרה. הגדרת החרגה של Microsoft Defender משנה את הסריקה של WdFilter, ואין לה שום השפעה על התנהגות מיניפילטרים אחרים שגרים יחד (אנטי-וירוס של חברה אחרת, EDR, גיבוי, הצפנה וכו’). כש«הוספתי החרגה ועדיין איטי», חשדו שאולי דייר אחר מבזבז זמן (השוואת fltmc בפרק 7). האפקט גדול, אבל החרגה מחלישה בוודאות את ההגנה במקום הזה. גם התיעוד של Microsoft מזהיר שוב ושוב שהחרגה מפחיתה הגנה ולכן צריך מינימום אחרי הערכת סיכון.⁶ הטיפול המעשי בזיהוי שגוי ובהשפעת ביצועים טופל ב«כשיישום Windows שפיתחתם מטופל כוירוס».

המענה החדש שנקרא Dev Drive. כרך ייעודי שתוכנן לעומסי פיתוח (קבצים קטנים רבים), שבו Microsoft Defender פועל במצב ביצועים (סריקה אסינכרונית). הוא ממוקם כחלופה בטוחה יותר להחרגת תיקייה, וכברירת מחדל מסננים נוספים אינם מתחברים, מצד שני מצוינת גם אזהרה חזקה מול תפעול שמסיר את כל המסננים.⁷ זה הפתרון המומלץ הנוכחי של Microsoft ל«רוצים להאיץ בנייה אבל החרגה מפחידה».

7. נוהל החקירה ל«רק הסביבה הזו איטית»

את הכלים שהצטברו בסדרה נסגור לבסוף לנוהל אחד.

flowchart TB
    S["תסמין: אותו יישום אבל רק בסביבה מסוימת<br/>גישה לקבצים איטית"]
    P1["מסתכלים בעמודת Duration ב-Procmon<br/>לאיזו פעולה（IRP_MJ_CREATE? WRITE?）<br/>הזמן נעלם"]
    Q1{"פעולה מסוימת איטית באופן אחיד?"}
    F1["משווים fltmc instances לסביבה המהירה<br/>רואים את הפרש תצורת המסננים"]
    Q2{"המסנן בהפרש הוא הסיבה?"}
    A1["הגדרת החרגה（עם הערכת סיכון）או<br/>בחינת Dev Drive / התייעצות עם הספק"]
    A2["חושדים במשהו שאינו מסנן:<br/>מטמון（פרק 4）· פיצול או MFT（פרק 5）·<br/>יעד רשת（UNC）· ההתקן עצמו"]
    S --> P1 --> Q1
    Q1 -->|"כן"| F1 --> Q2
    Q2 -->|"כן"| A1
    Q2 -->|"לא"| A2
    Q1 -->|"לא（מזדמן）"| A2

איור 6: הפרדת איטיות שמקורה במסנן. המפתח הוא «זמן לפי פעולה» ו«הפרש תצורת מסננים בין סביבות»

שתי נקודות. ראשית, ל-Procmon יש זמן לכל פעולה (Duration). אם אפשר לפרק «איטי» ל«איזו פעולה איטית», חיפוש האשם בחצי הדרך. שנית, הפרש סביבות הוא לעיתים קרובות הפרש תצורת מסננים. מכונת פיתוח מול מכונת ייצור, מחשב החברה מול מחשב הלקוח — רק לשים את פלט fltmc זה לצד זה כבר מראה מועמדים לחשד.

שלושת הצעדים הראשונים אם מעולם לא נגעתם ב-Procmon. עמודת Duration אינה מוצגת כברירת מחדל, אז נכתוב רק את הפעולה כדי לא להיתקע כאן.

1. מפעילים Procmon.exe כמנהל.
2. פותחים Options menu > Select Columns…, ומסמנים Duration ברשימת העמודות.
3. ב-Filter menu > Filter… (Ctrl+L) מזינים Process Name / is / שם ה-exe היעד / Include, ולוחצים Add ואז OK (בלי Add התנאי אינו נכנס).

אחרי זה לחיצה על עמודת Duration למיון מרכזת למעלה את הפעולות שאוכלות זמן. לסיכום לפי תהליך או לפי קובץ אפשר גם Tools menu > File Summary. התפעול הכללי של ProcMon מסודר ב«מדריך מעשי ל-Process Monitor (ProcMon)».

8. סיום הסדרה — מפת ששת הפרקים

בזה פתחנו את כל התיבות במפה שציירנו בפרק 1. נשים את הכול בדף אחד.

flowchart TB
    APP["יישום<br/>ReadFile / WriteFile / async-await"]
    API["פרק 2: קלט/פלט סינכרוני ואסינכרוני<br/>מצב ה-handle ו-OVERLAPPED"]
    IOCP["פרק 3: IOCP ומאגר התהליכונים של .NET<br/>קבלת ההשלמה והרצת ההמשך"]
    IOM["פרק 1: מנהל הקלט/פלט ו-IRP<br/>פתרון שמות · שלושה אובייקטים · מחסנית התקנים"]
    FLT["פרק 6: מסננים ומיניפילטר<br/>FltMgr · גובה · pre/post"]
    CACHE["פרק 4: מנהל המטמון<br/>תצוגת 256KB · lazy writer · Fast I/O<br/>（עובד בתיאום עם NTFS）"]
    NTFS["פרק 5: NTFS<br/>MFT · זרמים · קישורים · שני יומנים"]
    HW["מחסנית האחסון וההתקן"]
    APP --> API
    API --> IOM
    IOCP -. "ההשלמה חוזרת לכאן" .-> APP
    IOM --> FLT
    FLT --> NTFS
    NTFS -. "קלט/פלט עם מטמון בתיאום<br/>（מערכת הקבצים קוראת לפונקציית המטמון）" .- CACHE
    NTFS --> HW
    HW -. "הפרעה→השלמה（פרק 1）" .-> IOCP

איור 7: מפת הסדרה כולה. מנהל המטמון אינו «שכבה שעוברים בה» אלא שותף שמתואם עם מערכת הקבצים, ובפספוס מטמון יוצאת בקשה מ-NTFS לאחסון

• פרק 1: התמונה הכללית — כל קריאה וכתיבה הופכות ל-IRP
• פרק 2: סינכרוני/אסינכרוני — המשמעות האמיתית של OVERLAPPED
• פרק 3: IOCP — המרתף של async/await
• פרק 4: מטמון — מתי ה-WriteFile שלכם מגיע לדיסק
• פרק 5: NTFS — מערכת קבצים מתוך הבנת MFT
• פרק 6: מסננים ומיניפילטר (המאמר הזה) — למה Procmon וסריקת אנטי-וירוס יכולים להתערב בקלט/פלט

9. סיכום — לסיום הסדרה

סיכום הפרק האחרון.

• התערבות בקלט/פלט היא נקודת הרחבה שמערכת ההפעלה מאשרת, והתקן הנוכחי הוא רישום קריאות חוזרות אצל FltMgr (מיניפילטר). הסדר נקבע באופן דטרמיניסטי לפי גובה, ו-Microsoft מקצה ומנהלת את המספרים.²⁴⁵
• התנועה היא קריאות חוזרות pre/post. אפשר להעביר, לדחות, לקחת על עצמם, לשכתב, ולהיות נוכחים גם ב-Fast I/O. Procmon, Defender ו-OneDrive כולם דיירים באותו מנגנון.¹¹¹¹⁰
• הגדרת החרגה = דילוג על סריקה, וזה פשרה מול הגנה. לכרכי פיתוח יש אפשרות בטוחה יותר: Dev Drive (סריקה אסינכרונית).⁶⁷
• «רק הסביבה הזו איטית» מפרידים מDuration של Procmon ומהפרש תצורת fltmc — כלי הסדרה הופכים כמו שהם לנוהל חקירה.

ואת מסקנת הסדרה כולה בשורה אחת אפשר לומר כך — הקלט/פלט ב-Windows הוא תכנון עקבי שבו קובעים יעד במרחב השמות, הופכים בקשה לחבילה (IRP) ומזרימים אותה בין שכבות, וכל שכבה יכולה לבחור «לראות, לקבל, לקחת על עצמה». מתחת לשורת File.ReadAllText אחת, מבנה ששת הפרקים האלה רץ בכל פעם. במקום לשנן התנהגות API, לגזור מתוך המפה הזו «כך זה אמור להיות» — זה הכוח שרצינו שתקבלו בסדרה. תודה שהתלוויתם למסע הארוך.

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

• מעמקי הקלט/פלט ב-Windows (פרק 1) — כל קריאה וכתיבה הופכות ל-IRP: התמונה הכללית של מערכת הקלט/פלט
• מעמקי הקלט/פלט ב-Windows (פרק 4) — מנהל המטמון: מתי ה-WriteFile שלכם מגיע לדיסק
• מעמקי הקלט/פלט ב-Windows (פרק 5) — המבנה הפנימי של NTFS: מערכת קבצים מתוך הבנת MFT
• מדריך מעשי ל-Process Monitor (ProcMon) — לאתר ב-10 דקות «ההגדרה לא נקראת» ו«ACCESS DENIED»
• כשיישום Windows שפיתחתם מטופל כוירוס — טיפול בזיהוי שגוי של Microsoft Defender וההתמודדות עם השפעת ביצועים
• Process Explorer / Handle / VMMap בפועל — לעקוב אחרי תקיעה, דליפה ו«הקובץ בשימוש» ממצב הרגע הזה
• רשימת בדיקה מינימלית לאבטחה בפיתוח יישומי Windows

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

KomuraSoft LLC מטפלת בחקירת בעיות ביצועים ותקלות ביישומים עסקיים ל-Windows שקשורים למנהלי מסנן, כמו «איטי רק בסביבה מסוימת» או «תוכנת אבטחה מתנגשת ביישום שלנו».

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

מקורות

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

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

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

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

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

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

שאלות נפוצות

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

מה ההבדל בין מנהל מסנן של מערכת קבצים למיניפילטר?

שניהם «מנהלים שמתערבים בבקשות קלט/פלט למערכת הקבצים», אבל הם נבדלים בדור שיטת ההתערבות. גישת המסנן הישן (legacy) ערמה את אובייקט ההתקן שלה ישירות על מחסנית ההתקנים של מערכת הקבצים, כך שהמיקום נקבע לפי סדר הטעינה והיה קשה להבטיח, והיו בעיות כמו חוסר יכולת לפרוק בבטחה אחרי טעינה. התקן הנוכחי, המיניפילטר, רושם קריאות חוזרות אצל מנהל המסננים (FltMgr) שמגיע עם Windows, במובן «תקרא לי לפני ואחרי הפעולה הזו». המיקום נקבע באופן דטרמיניסטי במספר שנקרא גובה (altitude), אפשר לטעון בכל עת, ומסנן שמממש קריאת חוזרת לפריקה יכול אפילו להיות מוסר בזמן ריצה. כמעט כל המסננים המודרניים — אנטי-וירוס, הצפנה, כלי ניטור, סנכרון ענן — ממומשים כמיניפילטר.

למה תוכנת אנטי-וירוס יכולה לבדוק כל גישה לקובץ?

כי מערכת ההפעלה מספקת רשמית נקודת הרחבה בדיוק למטרה הזו. מיניפילטר יכול לרשום אצל מנהל המסננים קוד שייקרא לפני (קריאת חוזרת pre) ואחרי (קריאת חוזרת post) פעולות כמו פתיחה, קריאה או כתיבה של קובץ. מסנן אנטי-וירוס יושב בטווח הגובה השמור לאנטי-וירוס (320000–329999), ויכול למשל לסרוק את התוכן מיד אחרי שפתיחת קובץ מצליחה (post-create), ואם יש בעיה, לבטל את הפתיחה כדי שהגישה תיכשל. כפי שראינו בפרק 1 של הסדרה, כל פעולת קלט/פלט לקובץ זורמת במחסנית ההתקנים, כך שההיגיון הוא שעמידה במיקום קבוע לאורך הנתיב מאפשרת לבדוק כל גישה. זה אינו פריצה — זה מנגנון בנוי בתכנון מערכת ההפעלה.

מה הגדרת החרגה באנטי-וירוס (החרגת תיקייה) עושה בפועל, טכנית?

לקלט/פלט בנתיב שתואם לרשימת ההחרגה, היא גורמת למסנן של המוצר הזה לדלג על הסריקה שהיה מבצע אחרת. המסנן עצמו אינו נעלם מהמחסנית; ההבנה הקרובה יותר לאמת היא שההחלטה «אל תבדוק את הנתיב הזה» מתקבלת מוקדם יותר. מגבלה חשובה היא שהחרגה עובדת רק למוצר שמחזיק את ההגדרה הזו. למשל, הגדרת החרגה של Microsoft Defender משנה את הסריקה שעושה המסנן של Defender (WdFilter), ואין לה השפעה על התנהגות מיניפילטרים אחרים שיושבים לצידה — מוצר אנטי-וירוס מתחרה, EDR, תוכנת גיבוי וכו'. לכל מוצר נדרשת הגדרת החרגה משלו, וכש«עדיין איטי גם אחרי שהוספתי החרגה», מסנן אחר יכול להיות הסיבה. וכפי שהתיעוד של Microsoft מזהיר שוב ושוב, החרגה מחלישה את ההגנה במקום הזה, ולכן צריך לשמור אותה למינימום יחד עם הערכת סיכון. לשימוש בפיתוח, שווה גם לשקול Dev Drive (מצב ביצועים, כלומר סריקה אסינכרונית), שתוכנן כחלופה בטוחה להחרגות תיקייה.

איך Process Monitor רושם כל פעולת קלט/פלט בלי להחמיץ?

כי Procmon עצמו רושם את עצמו אצל מנהל המסננים בהפעלה, כמיניפילטר בטווח הגובה של Activity Monitor. אם מריצים fltmc משורת פקודה מוגבהת בזמן ש-Procmon רץ, אפשר לאשר שמסנן ששמו מתחיל ב-PROCMON מופיע ברשימה. מכיוון שהוא נוכח בשלבי pre ו-post של פעולות קלט/פלט בכל כרך כמיניפילטר, הוא יכול לרשום בלי השמטה איזה תהליך ביצע איזו פעולה על איזה קובץ. הסיבה שמונחי IRP ו-Fast I/O שעקבנו אחריהם לאורך הסדרה מופיעים ישירות בתצוגת Procmon היא בדיוק כי הוא צופה ממיקום שעומד על הנתיב שהקלט/פלט עצמו עובר.

כשבניות במכונת פיתוח איטיות, כדאי לחשוד במנהלי מסנן?

שווה מאוד לחשוד. בנייה היא גוש של יצירה, קריאה, כתיבה ומחיקה של מספר עצום של קבצים קטנים, וכל אחד מהם הופך ליעד לבדיקה של המסננים (במיוחד סריקת אנטי-וירוס), וזה הופך אותה לעומס העבודה שבו עלות המסנן הכי סבירה לעלות לפני השטח. נוהל החקירה הבסיסי הוא לבדוק את עמודת Duration ב-Procmon כדי לראות לאיזו פעולה הזמן הולך, ולהשוות את ההבדל בתצורת המסננים בין סביבות ב-fltmc instances. כאמצעי נגד, לצד הגדרת החרגה שאומצה אחרי הערכת סיכון, יש גם שימוש ב-Dev Drive, שתוכנן במיוחד לכרכי פיתוח. ב-Dev Drive האנטי-וירוס רץ במצב ביצועים (סריקה אסינכרונית), ו-Microsoft ממקמת את זה כחלופה בטוחה יותר להגדרת החרגה.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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