¿Dónde está Windows.edb? Ubicación y adquisición
Ubicación de Windows.edb y Windows.db en Windows 10 y 11, qué archivos adjuntos recoger y cómo copiar el índice de Windows Search bloqueado en un sistema vivo.
En resumen. El índice de Windows Search está en C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. Windows 10 y anteriores: Windows.edb (ESE) más MSS*.log, MSS.chk y *.jrs. Windows 11: Windows.db y Windows-gather.db (SQLite), cada uno con un archivo -wal. Adquiere la carpeta entera. En un sistema vivo, el servicio WSearch bloquea los archivos: usa una herramienta de copia en bruto, una instantánea de volumen o esentutl /y /vss. No copies nunca la base SQLite sin su -wal, y cuenta con que un Windows.edb copiado en caliente estará en estado de dirty shutdown.
La carpeta
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\
ProgramData está oculta por defecto, y %ProgramData% (o el antiguo %AllUsersProfile%) apunta a ella. El artículo de solución de problemas de Windows Search de Microsoft sitúa Windows.edb (Windows 10) y Windows.db (Windows 11) en esa carpeta. La ubicación del índice se puede mover desde Opciones de indización (Opciones avanzadas, «Ubicación del índice»), así que si la carpeta está vacía en una máquina donde la búsqueda claramente funcionaba, revisa ese ajuste en el subárbol SOFTWARE con un analizador del registro antes de sacar conclusiones.
Qué contiene en Windows 10 y anteriores
| Archivo | Función | ¿Necesario para el análisis? |
|---|---|---|
Windows.edb | La base ESE: almacén de propiedades, tablas gather, catálogo | Sí |
MSS.log, MSSxxxxx.log | Registros de transacciones ESE | Sí, para reproducir una base en estado dirty |
MSS.chk | Checkpoint: hasta qué posición de los registros se ha aplicado ya a la base | Sí, para la reproducción |
MSSres*.jrs / *.jrs | Registros de reserva | Consérvalos, no molestan |
tmp.edb | Base temporal | No |
Subcarpeta GatherLogs\ | Registros del rastreo | A veces útil; recógela igualmente |
Qué contiene en Windows 11
| Archivo | Función | ¿Necesario para el análisis? |
|---|---|---|
Windows.db | Almacén de propiedades (SystemIndex_1_PropertyStore + _Metadata) | Sí |
Windows.db-wal | Registro WAL: las últimas transacciones confirmadas aún no consolidadas | Sí, siempre junto con Windows.db |
Windows-gather.db + -wal | Tablas gather (SystemIndex_Gthr, SystemIndex_GthrPth) | Sí: rutas y comprobación de «¿borrado?» |
Windows-usn.db, otros *.db | Bases auxiliares (seguimiento USN y otras) | Recógelas; rara vez hacen falta |
*.db-shm | Índice en memoria compartida del WAL | No: SQLite lo reconstruye |
El artículo de Kaspersky sobre artefactos de Windows 11 enumera Windows-gather.db, Windows.db y Windows-usn.db en esta carpeta.
Por qué los archivos están bloqueados
El servicio Windows Search (WSearch, que ejecuta SearchIndexer.exe) mantiene las bases abiertas. ESE abre sus archivos en modo exclusivo. Como muestra una entrada archivada del blog de Microsoft sobre ESE, acceder a una base en uso falla con JET_errFileAccessDenied (-1032). Los archivos SQLite también se mantienen abiertos. Una copia desde el Explorador o con copy falla o, con algunas herramientas, produce un archivo lleno de ceros. Por eso el analizador marca los archivos que empiezan por ceros.
Cuatro formas de adquirirlo
1. Equipo apagado o imagen montada
Monta la imagen en solo lectura y copia la carpeta. Nada está bloqueado, nada cambia. Es la vía preferida siempre que ya tengas una imagen completa del disco.
2. KAPE o Velociraptor en un sistema vivo
El target de KAPE WindowsIndexSearch recoge C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ (más GatherLogs) mediante acceso NTFS en bruto. También recoge carpetas por usuario bajo AppData\Roaming\Microsoft\Search\Data\Applications\S-1*\ cuando existen.
kape.exe --tsource C: --target WindowsIndexSearch --tdest D:\case\kape
Velociraptor puede recoger la misma carpeta con su accesor NTFS. Los autores de SIDR también publican un artefacto de Velociraptor que ejecuta su analizador en el equipo.
3. esentutl con una instantánea de volumen (solo ESE)
Windows incluye esentutl.exe. Desde Windows 10 puede leer una base en uso a través de una instantánea de volumen (Volume Shadow Copy):
esentutl /y C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb /vss /d D:\case\Windows.edb
La copia resultante es una instantánea de una base abierta, así que normalmente estará en estado de dirty shutdown. La misma entrada describe /vssrec, que reproduce los registros dentro de la instantánea. También advierte de que las transacciones no confirmadas en el momento de la instantánea se revierten. Para evidencias prefiero copiar en bruto y reproducir después sobre una copia de trabajo, como se explica en la guía de dirty shutdown.
4. Detener el servicio (solo si puedes modificar el sistema)
En una máquina que tengas permiso para modificar (laboratorio, equipo que se va a reinstalar):
net stop wsearch
robocopy "C:\ProgramData\Microsoft\Search\Data\Applications\Windows" D:\case\search /E /COPY:DAT
net start wsearch
Detener WSearch cierra las bases limpiamente: Windows.edb queda en clean shutdown y el WAL de SQLite suele consolidarse. Es cómodo, pero has modificado la evidencia: el checkpoint vuelca el WAL en Windows.db y lo reinicia, y lo que contenían las tramas WAL antiguas puede perderse. Documéntalo, o evítalo.
Windows 11: mantén el WAL con su base
Windows.db-wal contiene transacciones confirmadas que aún no se han vuelto a escribir en Windows.db. La documentación WAL de SQLite es explícita: los lectores buscan primero la copia más reciente de cada página en el WAL. Sin el WAL estás viendo un estado anterior del índice, al que a menudo le falta justo la actividad más reciente. Con un WAL copiado en un momento distinto que su base, obtienes páginas incoherentes. Copia ambos en una sola operación. El analizador comprueba que el WAL corresponde a la base e ignora, con un aviso, uno que no encaja. Los detalles están en análisis forense de Windows.db: SQLite y el WAL.
Windows 10: cuenta con un dirty shutdown
Un Windows.edb copiado desde un sistema en marcha casi siempre está marcado como dirty shutdown: la cabecera indica que no se cerró limpiamente, y algunos cambios solo existen en los archivos MSS*.log. Aun así se puede leer. El Windows Search Index Parser lo analiza y lo indica. Para una vista coherente, reproduce los registros sobre una copia con esentutl /r MSS. Paso a paso en reparar un Windows.edb en dirty shutdown.
Calcula el hash y trabaja sobre copias
- Calcula el hash de la carpeta adquirida antes de tocar nada.
- Ejecuta la recuperación de
esentutl,sqlite3o cualquier herramienta que pueda escribir (¡SQLite consolida al cerrar!) solo sobre una copia de trabajo. - Abrir el
Windows.dboriginal en un cliente SQLite normal puede volcar el WAL en él. El análisis en el navegador en solo lectura no escribe nada, pero una copia no cuesta nada.
Después, analízalo
Suelta la carpeta, o el ZIP de KAPE / Velociraptor tal cual, en el Windows Search Index Parser. Empareja Windows.db con su -wal y con Windows-gather.db, reconoce los registros ESE y explica por qué no se analizan, y todo se ejecuta localmente en el navegador. La guía paso a paso recorre el resultado.
Preguntas frecuentes
¿Puedo copiar Windows.edb sin más mientras Windows está en marcha?
No. El servicio Windows Search mantiene los archivos abiertos y una copia normal falla. Usa una herramienta de copia NTFS en bruto, una instantánea de volumen (VSS), esentutl /y /vss, o detén el servicio en una máquina que tengas permiso para modificar.
¿Es seguro borrar Windows.edb?
En tu propio equipo, borrarlo (con el servicio detenido) fuerza una reconstrucción. En una máquina bajo investigación, nunca: destruyes la evidencia y la reconstrucción sobrescribe el espacio libre.