| Previous | Next |
| STATUS_DATA_LOST_REPAIR | STATUS_CLOUD_FILE_PROPERTY_BLOB_CHECKSUM_MISMATCH |
STATUS_GPIO_INTERRUPT_ALREADY_UNMASKED
The interrupt mask transition was requested from the wrong state
STATUS_GPIO_INTERRUPT_ALREADY_UNMASKED is specific to GPIO interrupt control. Masking temporarily prevents an interrupt from being delivered while the interrupt remains configured; unmasking re-enables delivery. This status means the caller attempted the unmask transition when the line was not masked, so the problem is state tracking rather than a generic failure to connect an ISR.
Windows GPIO documentation distinguishes GPIO interrupt masking from enabling or disabling the interrupt at a broader level. A driver should therefore trace the exact mask/unmask callbacks and any concurrent interrupt handling. Reissuing unmask blindly can hide a duplicate callback, an incorrectly balanced mask operation, or a race between controller state and driver bookkeeping.
What to inspect
- The GPIO pin or interrupt identifier and the controller instance servicing it.
- The previous mask state and every mask/unmask request leading to the duplicate transition.
- Whether the interrupt is edge-triggered or level-triggered and whether the source was cleared before delivery was re-enabled.
- Synchronization between ISR/DPC work and code that changes mask state.
Do not treat the status as proof of defective GPIO hardware. First establish whether software issued an unbalanced state transition and whether the controller callback observed the same state as the caller.
References
- Microsoft: GPIO interrupt masks
- Microsoft: GPIO interrupts
- Microsoft: GPIO driver support overview
- UEFI Forum: ACPI GPIO concepts
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.