Méfiez-vous des filters drivers du système de fichiers !


Un pilote filter driver du système de fichiers (en anglais a File System Filter Driver) est un pilote filtre optionnel qui peut modifier le comportement d'un système de fichiers. C’est un composant Kernel qui s'exécute donc en mode ‘’noyau’’.

 Un filter driver ; comme son nom l’indique, peut filtrer les opérations d'e/s pour un ou plusieurs systèmes de fichiers ou des volumes de système de fichiers. Selon la nature du pilote, il peut consigner des informations dans un log, observer, modifier ou même bloquer des actions. Les applications typiques pour les filter drivers incluent les antivirus, programmes de cryptage et systèmes de gestion de stockage.

 La commande fltmc permet de lister les filter drivers ; ce lien fournit des informations précieuses sur la gestion de l’ordre de démarrage : https://msdn.microsoft.com/en-us/library/windows/hardware/ff549689(v=vs.85).aspx

 L’information capitale à retenir est la suivante : Dans le cadre de problèmes de gel (hang/freeze) ou lenteur ; il convient de procéder par dichotomie et tester le scénario de reproduction sans les filter drivers tiers partis (Non MS)

 Récemment, j’ai eu à traiter un problème intéressant. Je partage avec vous ici le détail de l’incident et l’analyse effectuée.

Sur un parc de plusieurs centaines de machines virtuelles, mon client avait mis en place une tâche planifiée pour rebooter les VM toutes les semaines.

Le problème est que de manière aléatoire un certain pourcentage de VM restent bloquées lors de l’arrêt de windows.

Nous avons vérifié s’il y avait des erreurs côté windows voir des actions en cours qui auraient pu empêcher l’arrêt mais aucune piste n’a été identifiée.

Lors de la phase de recherches ; il a été constaté que seuls les VM en 32bits présentent ce dysfonctionnement.

Le problème était critique, puisque les VM qui le subissent sont inopérationnelles ce qui impacte fortement la production : elles sont inaccessibles via le réseau et en mode ‘’console’’ (ici via la console de l’hyperviseur) ; le seul moyen de rétablir la situation est de forcer l’arrêt à partir de l’hyperviseur (équivalent à un reset ou Power on/off).

Afin d’accélérer les investigations, nous avions opté pour la génération d’un memory dump lors du problème : un snapshot de la VM convertit en memory.dmp permettait via le debug de faire un état des lieux des processus et threads en court d’exécution.

Assez souvent, les problèmes de shutdown sont liés au blocage d’une power Irp.

La structure de gestion d’alimentation permet de confirmer que le serveur était bien en état d’arrêt.

Toutefois, la liste des Irp (demande d’entrée/sortie) ne renvoit pas vers un blocage au niveau de la gestion d’alimentation d’un dispositif

 PopAction: 81909ae8

  State……….: 3 – Set System State

  Updates……..: 0  SHUTDOWN-set

  Action………: ShutdownReset

  Lightest State.: Shutdown

  Flags……….: c0000004 OverrideApps|DisableWakes|Critical

  Irp minor……: SetPower

  System State…: Shutdown

  Hiber Context..: 00000000 

Allocated power irps (PopIrpList – 81916fa0)  ==>  liste des Irps

  IRP: 00000000, PDO: 00000000

 Irp worker threads (PopIrpThreadList – 81916a50)

  THREAD: 84776ad0 (static)

  THREAD: 84776d78 (static)

  THREAD: 856d90e0 (dynamic)

  THREAD: 85c88338 (dynamic)

  THREAD: 853fed78 (dynamic)

  THREAD: 86bb3d78 (dynamic)

  THREAD: 89730d78 (dynamic)

  THREAD: 85d63b28 (dynamic)

De manière générale la liste des IRp actives est vide

0: kd> !poreqlist

All active Power Irps from PoRequestPowerIrp

PopReqestedPowerIrpList

FieldOffset = 00000004

 Dans ce cas, Il a fallu passer en revue l’ensemble des threads en court à la recherche du blocage

 Le thread en charge de l’arrêt de la machine est en attente d’un évent depuis plus de 8h :

 

 0: kd> !thread 8477e828

THREAD 8477e828  Cid 0004.0060  Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable

    81b77540  SynchronizationEvent

Not impersonating

DeviceMap                 8d005828

Owning Process            8473ba90       Image:         System

Attached Process          N/A            Image:         N/A

Wait Start TickCount      5514093        Ticks: 1861936 (0:08:04:52.750)

Context Switch Count      10043          IdealProcessor: 0            

UserTime                  00:00:00.000

KernelTime                00:00:00.046

00 8d38db68 81aee272 nt!KiSwapContext+0x26

01 8d38dbac 81a89f78 nt!KiSwapThread+0x44f

02 8d38dc04 81d04a4c nt!KeWaitForSingleObject+0x492

03 8d38dd2c 81d198c0 nt!CmShutdownSystem+0x59

04 8d38dd44 81ae7d8a nt!PopGracefulShutdown+0x198

05 8d38dd7c 81c18152 nt!ExpWorkerThread+0xfd

06 8d38ddc0 81a80f4e nt!PspSystemThreadStartup+0x9d

07 00000000 00000000 nt!KiThreadStartup+0x16

 L’évent devrait être positionné par le thread suivant qui est toujours en phase de vidage du cache :

 0: kd> !thread 84784580

THREAD 84784580  Cid 0004.00dc  Teb: 00000000 Win32Thread: 00000000 WAIT: (DelayExecution) KernelMode Non-Alertable

    84784608  NotificationTimer

Not impersonating

DeviceMap                 8d005828

Owning Process            8473ba90       Image:         System

Attached Process          N/A            Image:         N/A

Wait Start TickCount      7376023        Ticks: 6 (0:00:00:00.093)

Context Switch Count      1060727        IdealProcessor: 1  NoStackSwap

UserTime                  00:00:00.000

KernelTime                00:00:01.078

00 80380b40 81aee272 nt!KiSwapContext+0x26

01 80380b84 81aeb94e nt!KiSwapThread+0x44f

02 80380be4 81a6352c nt!KeDelayExecutionThread+0x472

03 80380c10 81bc68fa nt!CcPurgeCacheSection+0x13e

04 80380c34 81bba53c nt!CmpDestroyHiveViewList+0xa7

05 80380d1c 81bba6fa nt!CmpFlushBackupHive+0x374

06 80380d40 81bba773 nt!CmpSyncBackupHives+0x90

07 80380d44 81ae7d8a nt!CmpFirstBackupFlushWorker+0x8

08 80380d7c 81c18152 nt!ExpWorkerThread+0xfd

09 80380dc0 81a80f4e nt!PspSystemThreadStartup+0x9d

0a 00000000 00000000 nt!KiThreadStartup+0x16

 L’argument de la fonction CcPurgeCacheSection est l’objet qui suit : une structure de type Section

 0: kd> !dx _SECTION_OBJECT_POINTERS 854b58c4

!dx _SECTION_OBJECT_POINTERS 854b58c4

kdcom!_SECTION_OBJECT_POINTERS

   +0x000 DataSectionObject : 0x85553d50 Void

   +0x004 SharedCacheMap   : 0x8552e008 Void

   +0x008 ImageSectionObject : (null)

 Le vidage de la “control Area” : section dans le mémoire associé à l’object

 0: kd> !ca 0x85553d50  

ControlArea  @ 85553d50

  Segment      a5150890  Flink      00000000  Blink        00000000

  Section Ref         1  Pfn Ref        1b2f  Mapped Views        2

  User Ref            0  WaitForDel        0  Flush Count         0

  File Object  85a3e680  ModWriteCount     0  System Views        2

  WritableRefs        0 

  Flags (8088) NoModifiedWriting File WasPurged

       \Windows\System32\config\RegBack\SOFTWARE   è c’est la hive Software du dossier RegBack (Backup du registre effectué par l’OS)

 Segment @ a5150890

  ControlArea     85553d50  ExtendInfo    00000000

  Total Ptes          1c00

  Segment Size     1c00000  Committed            0

  Flags (c0000) ProtectionMask

 Subsection 1 @ 85553d98

  ControlArea  85553d50  Starting Sector        0  Number Of Sectors 1c00

  Base Pte     80e6f000  Ptes In Subsect     1c00  Unused Ptes          0

  Flags               d  Sector Offset          0  Protection           6

  Accessed

  Flink        00000000  Blink           851f528c  MappedViews          2

 Inspection de toutes les pages mémoire qui référencent un pointeur sur cette hive :

 0: kd> !search 85a3e680 

Searching PFNs in range 0000010C – 00107FFF for [FFFFFFFF85A3E680 – FFFFFFFF85A3E680]

Pfn      Offset   Hit      Va       Pte     

– – – – – – – – – – – – – – – – – – – – – – – – – – –

000E7E92 0000035C 85A3E680 9BF7335C C04DFB98

        9bf73000+0x35c   : CM10  — Internal Configuration manager allocations

00106C2E 00000680 85A2E680 85A2E680 C042D170

        85a2e4f8+0x188   : SNDc  : No pool tag description

00106C2E 00000684 85A2E680 85A2E684 C042D170

        85a2e4f8+0x18c   : SNDc  : No pool tag description

00106C3E 00000600 85A3E600 85A3E600 C042D1F0

        85a3e5e0+0x20    : Icp   — I/O completion packets queue on a completion ports

00106C7E 00000680 85A7E680 85A7E680 C042D3F0

        85a7e580+0x100   : SNDc  : No pool tag description

00106C7E 00000684 85A7E680 85A7E684 C042D3F0

        85a7e580+0x104   : SNDc  : No pool tag description

0010732E 0000004C 85A3E680 8552E04C C042A970

        8552e000+0x4c    : CcSc  — Cache Manager Shared Cache Map

0010732E 000000E8 85A3E680 8552E0E8 C042A970

        8552e000+0xe8    : CcSc  — Cache Manager Shared Cache Map

00107353 00000D74 85A3E680 85553D74 C042AA98

        85553d48+0x2c    : MmCa  — Mm control areas for mapped files

 En plus des tag Kernel attendus des modules Windows relatifs à la gestion de mémoire, la commande nous permet d’identifier le tag SNDc 

 Identification du pilote auquel correspond le tag SNDc  : il s’agit d’un pilote de l’antivirus

       !for_each_module s -a @#Base @#End "SNDc"

No.  MEMORY_RANGE         CheckSum  TimeStamp                           Flag Author            Image Name       Dist Version                Path

 94  93092000 – 930ee000  0005b7cb  522104cc  Fri Aug 30 22:47:08 2013   ???                   SYMTDIV          ???                        \SystemRoot\system32\Drivers\SEP\0C010FAD\0FAD.105\x86\SYMTDIV.SYS

 

 L’éditeur du filter driver a été informé du problème, en attendant d’avoir une mise à jour nous avons exclu le dossier c:\Windows\System32\config du scan pour résoudre le problème.

 

Comments (0)

Skip to main content