Tables SRUM expliquées : AppResource, Network, Energy, Push
17/05/2026
Vue d’ensemble
SRUDB.dat est une base Extensible Storage Engine (ESE). La plupart de ses
tables portent des noms GUID entre accolades, qui identifient une
extension SRUM — un fragment de télémétrie collecté périodiquement
(toutes les 60 minutes par défaut, toutes les 10 secondes lors des
changements d’alimentation).
| GUID | Nom commun |
|---|---|
{D10CA2FE-6FCF-4F6D-848E-B2E99266FA89} | Utilisation des ressources |
{D10CA2FE-6FCF-4F6D-848E-B2E99266FA89}LT | Utilisation des ressources (long terme) |
{973F5D5C-1D90-4944-BE8E-24B94231A174} | Utilisation des données réseau |
{DD6636C4-8929-4683-974E-22C046A43763} | Connectivité réseau |
{FEE4E14F-02A9-4550-B5CE-5FA2DA202E37} | Utilisation de l’énergie |
{FEE4E14F-02A9-4550-B5CE-5FA2DA202E37}LT | Utilisation de l’énergie (long terme) |
{D10CA2FE-6FCF-4F6D-848E-B2E99266FA8F} | Notifications push |
Plus deux tables de contrôle :
SruDbIdMapTable— joint les IDs entiers vers les chemins d’app ou SIDsSruDbCheckpointTable— état interne de flush
Utilisation des ressources
Activité par application échantillonnée toutes les heures. Chaque ligne indique qui a exécuté quoi, quand, et à quel coût.
Colonnes clés :
TimeStamp— borne de bucketAppId,UserId— clés étrangères versSruDbIdMapTableForegroundCycleTime,BackgroundCycleTime— cycles CPU (pas secondes)FaceTime— durée pendant laquelle l’UI était visibleForegroundBytesRead,ForegroundBytesWritten— I/O disque au premier planForegroundNumReadOperations/NumWriteOperations/NumberOfFlushes- Équivalents arrière-plan pour toutes les colonnes I/O
La variante « long terme » ({...}LT) agrège les mêmes lignes en buckets
hebdomadaires, conservée jusqu’à un an.
Utilisation des données réseau
Octets envoyés et reçus par application sur chaque profil réseau.
InterfaceLuid— LUID Windows de l’interfaceL2ProfileId— ID opaque résoluble contre la rucheSOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profilespour le nom SSID/filaire lisibleL2ProfileFlags— bitmask : 0x100 = filaire, 0x200 = sans-fil, 0x400 = WWANBytesSent,BytesRecvd— compteurs depuis le dernier échantillon
Combiné avec la résolution AppId, ceci répond à « combien de Mo
chrome.exe a-t-il envoyés sur mon Wi-Fi entre 14h00 et 15h00 ? »
Connectivité réseau
Quand le système s’est connecté et déconnecté de chaque réseau.
ConnectStartTime— FILETIME d’associationConnectedTime— durée en secondesInterfaceLuid,L2ProfileId,L2ProfileFlags— comme ci-dessus
Utile pour placer un appareil sur un réseau précis à un instant précis.
Utilisation de l’énergie
Télémétrie batterie et source d’alimentation. Échantillonnée à chaque transition d’état d’alimentation.
EventTimestamp— FILETIME de la transitionStateTransition— branchement/débranchement secteur, entrée/sortie veille, batterie faibleChargeLevel,CycleCount,ConfigurationHashDesignedCapacity,FullChargedCapacity(mWh)ActiveAcTime,CsAcTime,ActiveDcTime,CsDcTime— compteurs d’uptime par source
La variante « LT » suit la dégradation de la santé batterie sur des mois.
Notifications push
Pour les apps Modern qui utilisent le Windows Push Notification Service.
NotificationType— toast, tile, badge, rawPayloadSize— octets du corps de notificationNetworkType— interface qui l’a livrée
Résolution : SruDbIdMapTable
Chaque table de données contient AppId et UserId en petits entiers.
Pour les rendre lisibles, vous joignez contre SruDbIdMapTable :
| Colonne | Signification |
|---|---|
IdType | 0 = service, 1 = app, 2 = SID, 3 = utilisateur (varie selon la build) |
IdIndex | L’entier utilisé par les tables de données |
IdBlob | Chemin UTF-16 pour les apps, SID binaire pour les utilisateurs |
L’analyseur en page d’accueil fait cette jointure automatiquement — ouvrez
n’importe quel onglet de table SRUM et les colonnes AppId / UserId
affichent la chaîne résolue quand disponible, ou #42 quand l’IdMap n’a
pas d’entrée.
Pour aller plus loin
- Qu’est-ce que SRUM et pourquoi cela intéresse les analystes forensiques
- Investigation forensique avec SRUM
- Le format de base ESE derrière SRUDB.dat
- Déposez un fichier dans l’analyseur SRUM pour voir chaque table en direct.
Questions fréquentes
- Combien de tables contient SRUDB.dat ?
- Typiquement 11 à 14, incluant les tables système ESE (MSysObjects, MSysObjids, MSysLocales), les tables de contrôle SRUM (SruDbIdMapTable, SruDbCheckpointTable), et 6 à 8 tables de données nommées par GUID.
- Qu’est-ce que SruDbIdMapTable ?
- Elle résout les petits entiers AppId et UserId utilisés par chaque table de données vers soit un identifiant d’application (chemin complet ou AUMID pour les apps Modern), soit un SID binaire pour les comptes Windows.
- Pourquoi les tables de données sont nommées par GUID ?
- Chaque extension SRUM s’enregistre avec un GUID. Les noms sont stables d’une build à l’autre, donc tout outil qui connaît le GUID peut parser la table correspondante quel que soit le service pack ou la locale.
- Combien de temps les lignes sont-elles conservées ?
- Environ 30 jours pour les tables court-terme et jusqu’à un an pour les variantes « LT » long-terme. La rétention exacte est gouvernée par la politique registre sous HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\SRUM.
- Les timestamps sont en FILETIME ou OLE ?
- La colonne TimeStamp est un OLE variant date (flottant 8 octets). Les tables Energy et Network Connectivity utilisent du FILETIME 64-bit pour leurs timestamps d’événements.