⌚ About 2 min read
This guide provides a structured method for diagnostics ID 129 and 153.
Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.
Étapes à suivre
-
1
Collect
To identify the exact error, time time and context.
-
2
Limit
Identify the systems and users involved.
-
3
Test
Use appropriate tools or commands to confirm cause.
-
4
Correct
Apply a targeted and reversible correction.
-
5
Validate
Play the full screenplay and check the logs.
À retenir
- Keep the initial state.
- Avoid multiple simultaneous changes.
- Document the final result.
Event ID 129 / 153: correlate resets and retries with the storage path
Technical checkpoints
- Event 129 typically indicates a storage miniport reset after timeout; Event 153 indicates an I/O operation was retried.
- The cause can be disk, controller/HBA, firmware, driver, cable, SAN or saturation; do not conclude “failed disk” from the event number alone.
- Timestamp should be correlated with disk latency, backup, snapshot, MPIO and vendor errors.
Correlation
Export events with device name and compare with storage counters/SMART or SAN logs.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=129,153}Topic-specific pitfalls
- chkdsk does not fix HBA/SAN timeouts and can add load.
- Updating a driver during active degradation without rollback planning can worsen outage.
How to validate
- No new 129/153 event appears during representative load.
- Latency, firmware/driver and health of each storage layer are coherent.