0
0
Estás tranquilo revisando el Visor de Eventos y de repente te aparece este mensajito con cara de “no es mi culpa”:
The backing-file for the real-time session «DefenderApiLogger» has reached its maximum size. As a result, new events will not be logged to this session until space becomes available.
Y vos quedás como 🤨: “¿Será que ya no me registra ningún error en el server? ¿Se murió el Event Viewer?”
Respirá, cipote. No es tan grave como suena, pero sí es algo que tenés que atender si no querés quedarte ciego en algunos logs.
📌 ¿Qué rayos significa?
Traducido al hondureño:
El DefenderApiLogger es un trace que usa Microsoft Defender para registrar eventos en tiempo real sobre lo que hace su API.
El problema es que ese “cuadernito” donde los apunta tiene un límite, y ya se llenó.
Cuando eso pasa:
- Se deja de registrar solo esa sesión de Defender, no todo el Event Viewer.
- Tus errores de w3wp.exe, ASP.NET o cualquier otra cosa seguirán apareciendo normal.
En otras palabras, si estabas debuggeando algo de Microsoft Defender (o un malware que te querías pescar en vivo), te perdiste parte de la novela.
⚠ Entonces… ¿pierdo logs importantes?
Depende:
- Sí → Si tu auditoría depende de esos eventos de Defender (por ejemplo, integraciones con un SIEM, monitoreo de malware avanzado, etc.).
- No → Si solo te importa que tu aplicación y tu IIS sigan registrando errores como el clásico Event 1309 del
w3wp.exe(que, por cierto, en GeneXus se ve así):
phpCopyEditException type: TargetInvocationException
Exception message: Exception has been thrown by the target of an invocation.
at GeneXus.Http.GXHttpHandler.DynAjaxEvent.DoInvoke(...)
Ese tipo de error no lo afecta el chisme de DefenderApiLogger.
🛠 ¿Cómo se arregla?
Si querés revivir la sesión y que siga guardando eventos, tenés opciones:
1️⃣ Reiniciar la sesión de logging
Abrí PowerShell como administrador y dale:
powershellCopyEditlogman stop DefenderApiLogger -ets
logman start DefenderApiLogger -p "{AE53722E-C863-11D2-8659-00C04FA321A1}" 0xFFFFFFFF 0xFF -o "C:\PerfLogs\DefenderApiLogger.etl" -ets
Esto limpia el archivo viejo y arranca uno nuevo.
2️⃣ Apagarlo si no lo usás
Si ni sabías que existía, podés simplemente quitarlo:
powershellCopyEditlogman delete DefenderApiLogger -ets
No se te va a apagar Defender, solo su cuaderno chismoso.
3️⃣ Revisar qué más anda escribiendo como loco
Para ver todas las sesiones ETW activas:
powershellCopyEditlogman query -ets
Capaz tenés otros “chismosos” ocupando espacio sin que nadie los lea.
💡 Pro tip: Evitá sorpresas en GeneXus/IIS
Si de paso tenés warnings de ASP.NET Event 1309 como el de la captura:
- Asegurate de manejar excepciones en todos los eventos AJAX (
try-catchsalvador). - Logueá en tu propia tabla de errores antes de que exploten hasta
w3wp.exe. - Así, aunque un trace de Defender se llene, vos igual tenés tu propio historial de metidas de pata.
📜 Conclusión
- El
DefenderApiLoggerlleno no significa que tu Event Viewer esté muerto. - Tus errores de IIS, ASP.NET, GeneXus y compañía siguen saliendo normal.
- Si necesitás esos logs de Defender, reiniciá o borra la sesión.
- Y como buen sysadmin/desarrollador precavido: tené tus propios logs. Porque un día el chismoso oficial se queda sin papel… y ahí sí, a llorar a La Dalia.
Average Rating