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

זה הפרק האחרון בסדרה “מעמקי ה-I/O ב-Windows”.

מאז שפרק 1 צייר בתיבה “file system filters (אנטי-וירוס, הצפנה, Procmon וכדומה)” בתרשים מחסנית ההתקנים, אלה שיושבים באמצע הופיעו שוב ושוב לאורך הסדרה: למה Procmon יכול לרשום כל פעולת I/O (פרק 1); “גישה לקבצים איטית רק בסביבה אחת” (פרק 2); נקודת ה-reparse שגורמת ל-OneDrive להתחיל הורדה ברגע שקובץ נפתח (פרק 5). הפרק הזה פונה סוף סוף חזיתית למנגנון ההתערבות עצמו: file system filter drivers ו-minifilter, וסוגר כל חוט שהסדרה השאירה פתוח.

1. קודם המסקנה

• “להתערב ב-I/O” הוא נקודת הרחבה רשמית של ה-OS. file system filter יכול לראות, לשכתב, לדחות, ולטפל במקום בקשות למערכת הקבצים (פרק 2).¹
• התקן הנוכחי הוא minifilter. כדי לפתור בעיות של שיטת ה-legacy שמתערבת ישירות במחסנית ההתקנים (סדר לא יציב, אי אפשר לפרוק), עברו לשיטה שרושמת callbacks אצל Filter Manager (FltMgr) שמגיע עם Windows (פרק 2).²³
• התנועה היא pre/post callbacks. לפני ואחרי כל פעולה קוראים לפי סדר הרישום = סדר altitude. pass-through, השלמה, דחייה, שכתוב: אותן “בחירות של נהג” מפרק 1 זמינות כמו שהן (פרק 3).²
• altitude (גובה) קובע סדר. לכל סוג שימוש מוקצה טווח מספרים (Activity Monitor 360000–389999, Anti-Virus 320000–329999 וכו’), ולכל instance שמתחבר ל-volume מספר ייחודי (פרק 4).⁴⁵
• את הדיירים במחשב שלכם רואים ב-fltmc. Procmon (רק בזמן שהוא רץ), אנטי-וירוס, cloud filter של OneDrive: כולם עומדים כאן (פרק 5).
• הגדרת החרגה באנטי-וירוס היא דילוג על הסריקה של אותו מוצר, ולא משפיעה על minifilters אחרים. החרגה היא trade-off שמחליש הגנה, ול-volumes של פיתוח יש אפשרות בטוחה יותר: Dev Drive (סריקה אסינכרונית) (פרק 6).⁶⁷
• חקירה של “רק הסביבה הזו איטית” מתחילה מעמודת Duration ב-Procmon ומהשוואת תצורה ב-fltmc (פרק 7).

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

2. ההיסטוריה של אלה שמתערבים: מ-legacy filter ל-FltMgr

file system filter driver הוא נהג שיכול לחטוף בקשות שפונות למערכת הקבצים (או ל-volume שמתחתיה). הוא יכול לרשום בקשות, לנטר, לשנות תוכן, ואפילו לדחות או לטפל במקום: הבסיס לתוכנות אנטי-וירוס, הצפנה, גיבוי ו-hierarchical storage.¹

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

לכן Windows הציג את Filter Manager (FltMgr). FltMgr עצמו עומד במחסנית כ-filter שמגיע עם ה-OS, וכל פונקציית filter נרשמת כminifilter אצל FltMgr ב-callbacks.²

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

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

היתרונות של שיטת minifilter מנויים רשמית: אפשר לטעון בכל עת, אפשר לשלוט בסדר, ו-filter שמממש unload callback אפשר לפרוק גם בזמן ריצה (filter שלא מממש או שמסרב אי אפשר להסיר).³ כדי לדור בכפיפה אחת עם legacy filters, FltMgr יכול לעמוד בכמה מקומות במחסנית ככמה “frames”, ו-minifilter שפורקים וטוענים מחדש חוזר לאותו מקום (אותו altitude).² תוכנות אנטי-וירוס, ניטור וסנכרון מודרניות הן כמעט כולן minifilter.

3. איך minifilter זז: pre/post callbacks

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

sequenceDiagram
    participant IOM as I/O Manager
    participant FM as FltMgr
    participant A as minifilter A<br/>(altitude גבוה)
    participant B as minifilter B<br/>(altitude נמוך)
    participant FS as NTFS

    IOM->>FM: בקשה (IRP_MJ_CREATE וכו'. העולם של פרק 1)
    FM->>A: pre callback
    FM->>B: pre callback
    FM->>FS: אל מערכת הקבצים
    FS-->>FM: תוצאת הטיפול
    FM-->>B: post callback
    FM-->>A: post callback
    FM-->>IOM: השלמה (זרימת ההשלמה מפרק 1)

איור 2: pre/post callbacks. בדרך הלוך לפי altitude יורד, בדרך חזור בסדר הפוך

מה אפשר לעשות בכל callback. אותו מבנה של “שלוש הבחירות של נהג” מסעיף 4.3 בפרק 1, עם API בטוח יותר.

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

איור 3: הבחירות ב-pre callback. לראות, לעצור, לקחת במקום, ולשכתב: הכול רשמי

וכאן נסגר שיעורי הבית מפרק 4: minifilter נוכח גם ב-Fast I/O (הדרך הקצרה בלי IRP). FltMgr מעביר גם את נתיב Fast I/O דרך מנגנון ה-callbacks, ולכן אין יותר את מצב ה-legacy שבו “עברו בדרך הקצרה ולא ראינו”. לכן בלוג של Procmon מופיעות גם שורות FASTIO_.

4. altitude: הגובה קובע סדר

כמה filters מעוניינים באותה פעולה, מי רואה קודם זו שאלה כבדה. אם אנטי-וירוס רואה אחרי הצפנה, הוא סורק ciphertext; כלי ניטור צריך להיות מעל כולם כדי לראות את התמונה המלאה.

את הסדר הזה קובע altitude (גובה). לכל סוג filter מוגדרות load order groups וטווחי מספרים. בדיוק, altitude לא מצורף לנהג כולו אלא ל-instance של minifilter שמתחבר ל-volume. המספר ייחודי, וככל שהוא גדול יותר המיקום גבוה יותר במחסנית (קרוב לאפליקציה).⁴ נהג אחד יכול להחזיק כמה הגדרות instance ולהופיע בגבהים שונים, ולכן הרשימה של fltmc instances היא לפי instance.

flowchart TB
    APP["קרוב לאפליקציה (מספר גדול)"]
    G1["FSFilter Activity Monitor: 360000-389999<br/>תצפית ורישום I/O (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: טווחי altitude (מקטע). לכל שימוש יש גובה שבו צריך לעמוד

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

לאן מגישים בקשה אם אתם בונים minifilter. למפתחים, רק הצעד הבא. altitude מגישים לפי Request a Filter Altitude Identifier, במייל באנגלית ל-fsfcomm@microsoft.com עם הנושא “Filter altitude request”. צריך למלא שם חברה, פרטי קשר (alias חברה לטווח ארוך, לא אישי), שם מוצר, URL מוצר, תיאור ה-filter, שם קובץ הנהג, סוג filter, סוג start, load order group רצוי ו-altitude רצוי. ממתינים ל-30 ימי עסקים, אין מסלול דחוף, והמספר שמוקצה עשוי להיות שונה מהמבוקש.⁸ אם לחברה כבר יש altitude שלם באותה load order group, אפשר לבחור לבד ערך עם נקודה עשרונית על אותו מספר (למשל 325000.3) ולדווח אחר כך במייל.⁸

5. היכרות עם הדיירים: ה-PC שלכם ב-fltmc

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

:: רשימת minifilters רשומים (עם altitude)
fltmc

:: איזה filter מחובר לאיזה volume
fltmc instances

:: מבט מצד ה-volume
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

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

משמעות העמודות:

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

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

• WdFilter: minifilter של Microsoft Defender. יושב בטווח Anti-Virus. בהרבה מחשבים זה מחסום שכל I/O לקבצים חייב לעבור.
• cldflt: filter של קבצי ענן. יחידת הביצוע של Files On-Demand ב-OneDrive; כשנפתח reparse point (placeholder) מפרק 5, הוא מכין את הישות.¹⁰
• PROCMON24 (וכו’): minifilter זמני בטווח Activity Monitor שמופיע רק בזמן ש-Process Monitor רץ. זו הסיבה ש-Procmon רואה את כל ה-I/O.¹¹ הריצו fltmc לפני ואחרי ההפעלה והשוו.
• בנוסף: תוכנת גיבוי, מוצר הצפנה (מניעת דליפת מידע), EDR, אחסון וירטואלי. ככל שהמחשב עסקי יותר, יש יותר דיירים.

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

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

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

sequenceDiagram
    participant App as אפליקציה
    participant AV as AV minifilter
    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: בהמון קבצים קטנים (תוצרי ביניים של build וכו')<br/>ההלוך-חזור הזה מצטבר כמספר הקבצים

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

מכאן מבינים בדיוק שני נושאים מעשיים.

המשמעות הטכנית של הגדרת החרגה. ב-I/O לנתיב שתואם לרשימת ההחרגה, סריקת ה-filter מדולגת. ה-filter לא נעלם מהמחסנית; מה שקורה באמת קרוב יותר לכך שההחלטה “לא לבדוק” מתקבלת מוקדם. ועוד מגבלה חשובה: החרגה עובדת רק ל-filter של המוצר שמחזיק את ההגדרה. החרגה של Microsoft Defender משנה את הסריקה של WdFilter, ואין לה שום השפעה על minifilters אחרים שיושבים לידה (אנטי-וירוס אחר, EDR, גיבוי, הצפנה). “הוספתי החרגה ועדיין איטי” צריך לחשוד שדייר אחר אוכל את הזמן (השוואת fltmc בפרק 7). האפקט גדול, ומצד שני החרגה מחלישה בוודאות את ההגנה במקום הזה. גם התיעוד של Microsoft חוזר ומזהיר שהחרגה מורידה הגנה ולכן צריך להגדיר במינימום אחרי הערכת סיכון.⁶ הפרקטיקה של false positive והשפעת ביצועים מכוסה ב”כשאפליקציית Windows שפיתחתם מזוהה כוירוס”.

Dev Drive כתשובה חדשה. volume ייעודי שתוכנן לעומסי פיתוח (המון קבצים קטנים), שבו Microsoft Defender רץ ב-מצב ביצועים (סריקה אסינכרונית). הוא ממוקם כ-חלופה בטוחה יותר להחרגת תיקייה. כברירת מחדל לא מתחברים filters נוספים, ויש גם אזהרה חזקה מפני תפעול בלי filter אנטי-וירוס בכלל.⁷ זו ההמלצה הנוכחית של Microsoft ל”רוצים build מהיר אבל מפחדים מהחרגה”.

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

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

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

איור 6: הפרדת איטיות שמקורה ב-filter. המפתח הוא זמן לפי פעולה, והפרש תצורת filters בין סביבות

שתי נקודות. ראשית, ל-Procmon יש Duration לכל פעולה. אם מפרקים “איטי” ל”איזו פעולה איטית”, חיפוש האשם בחצי הדרך. שנית, הפרש סביבות הוא לעיתים קרובות הפרש תצורת filters. מכונת פיתוח מול ייצור, מחשב פנימי מול מחשב לקוח: מספיק לשים פלט fltmc זה לצד זה כדי לראות מועמדים.

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

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

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

8. סגירת הסדרה: המפה של שישה פרקים

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

flowchart TB
    APP["אפליקציה<br/>ReadFile / WriteFile / async-await"]
    API["פרק 2: I/O סינכרוני ואסינכרוני<br/>מצב ה-handle ו-OVERLAPPED"]
    IOCP["פרק 3: IOCP ו-thread pool של .NET<br/>קבלת השלמה והרצת continuation"]
    IOM["פרק 1: I/O Manager ו-IRP<br/>פתרון שמות, שלושה אובייקטים, מחסנית התקנים"]
    FLT["פרק 6: filters ו-minifilter<br/>FltMgr, altitude, pre/post"]
    CACHE["פרק 4: Cache Manager<br/>view של 256KB, lazy writer, Fast I/O<br/>(עובד בשיתוף עם NTFS)"]
    NTFS["פרק 5: NTFS<br/>MFT, streams, links, שני journals"]
    HW["מחסנית אחסון והתקן"]
    APP --> API
    API --> IOM
    IOCP -. "ההשלמה חוזרת לכאן" .-> APP
    IOM --> FLT
    FLT --> NTFS
    NTFS -. "I/O עם מטמון דלוק רץ בשיתוף<br/>(מערכת הקבצים קוראת ליכולת המטמון)" .- CACHE
    NTFS --> HW
    HW -. "interrupt ואז השלמה (פרק 1)" .-> IOCP

איור 7: המפה של כל הסדרה. Cache Manager הוא לא שכבה שעוברים בה אלא שותף שעובד עם מערכת הקבצים, וב-cache miss יוצאת בקשה מ-NTFS לאחסון

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

9. סיכום: סגירת הסדרה

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

• התערבות ב-I/O היא נקודת הרחבה רשמית של ה-OS, והתקן הנוכחי הוא רישום callbacks אצל FltMgr (minifilter). הסדר דטרמיניסטי לפי altitude, ו-Microsoft מקצה ומנהלת את המספרים.²⁴⁵
• התנועה היא pre/post callbacks. אפשר pass-through, דחייה, לקחת במקום, ולשכתב, וגם Fast I/O נצפה. Procmon, Defender ו-OneDrive כולם דיירים של אותו מנגנון.¹¹¹¹⁰
• החרגה = דילוג על סריקה, וזה trade-off מול הגנה. ל-volumes של פיתוח יש אפשרות בטוחה יותר: Dev Drive (סריקה אסינכרונית).⁶⁷
• “רק הסביבה הזו איטית” מפרידים מ-Duration ב-Procmon ומהפרש תצורה ב-fltmc. כלי הסדרה הופכים ישר לנוהל חקירה.

ואת מסקנת הסדרה כולה בשורה אחת אפשר לומר כך: I/O ב-Windows הוא עיצוב עקבי שבו קובעים יעד במרחב שמות, הופכים בקשה ל-packet (IRP) ומזרים אותה בין שכבות, וכל שכבה יכולה לבחור לראות, לשמור אצלה, או לקחת במקום. מתחת לשורה אחת של File.ReadAllText רץ בכל פעם המבנה של ששת הפרקים האלה. במקום לשנן התנהגות API, אפשר לגזור מהמפה “ככה זה אמור להיות”. זו היכולת שהסדרה רצתה לתת. תודה שהלכתם איתנו בדרך הארוכה.

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

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

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

ב-KomuraSoft LLC מטפלים בחקירת בעיות ביצועים ותקלות באפליקציות Windows עסקיות שקשורות ל-filter drivers: “איטי רק בסביבה מסוימת”, או “תוכנת אבטחה מתערבת באפליקציה שלנו”.

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

מקורות

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

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

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

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

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

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

שאלות נפוצות

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

מה ההבדל בין file system filter driver ל-minifilter?

שניהם נהגים שמתערבים בבקשות I/O למערכת הקבצים, אבל דור שיטת ההתערבות שונה. גישת ה-legacy filter ערמה את device object שלה ישירות על מחסנית ההתקנים של מערכת הקבצים, כך שהמיקום נקבע לפי סדר הטעינה והיה קשה להבטיח, והיו בעיות כמו חוסר יכולת לפרוק בבטחה אחרי טעינה. התקן הנוכחי, minifilter, רושם callbacks אצל Filter Manager (FltMgr) שמגיע עם Windows, במובן תקרא לי לפני ואחרי הפעולה הזו. המיקום נקבע באופן דטרמיניסטי במספר שנקרא altitude, אפשר לטעון בכל עת, ו-filter שמממש unload callback יכול אפילו להיות מוסר בזמן ריצה. כמעט כל ה-filters המודרניים (אנטי-וירוס, הצפנה, כלי ניטור, סנכרון ענן) ממומשים כ-minifilter.

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

כי מערכת ההפעלה מספקת רשמית נקודת הרחבה בדיוק למטרה הזו. minifilter יכול לרשום אצל Filter Manager קוד שייקרא לפני (pre callback) ואחרי (post callback) פעולות כמו פתיחה, קריאה או כתיבה של קובץ. filter של אנטי-וירוס יושב בטווח ה-altitude השמור לאנטי-וירוס (320000–329999), ויכול למשל לסרוק את התוכן מיד אחרי שפתיחת קובץ מצליחה (post-create), ואם יש בעיה, לבטל את הפתיחה כדי שהגישה תיכשל. כמו שראינו בפרק 1 של הסדרה, כל פעולת I/O לקובץ זורמת במחסנית ההתקנים, כך שההיגיון הוא שעמידה במיקום קבוע לאורך הנתיב מאפשרת לבדוק כל גישה. זה אינו פריצה: זה מנגנון בנוי בתכנון מערכת ההפעלה.

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

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

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

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

כשבניות במכונת פיתוח איטיות, כדאי לחשוד ב-filter drivers?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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