Bug Check 0x10D: WDF_VIOLATION
The WDF_VIOLATION bug check has a value of 0x0000010D. This indicates that Kernel-Mode Driver Framework (KMDF) detected that Windows found an error in a framework-based driver.
Important
This article is for programmers. If you're a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.
WDF_VIOLATION Parameters
Parameter 1 indicates the specific error code of the bug check. Parameter 4 is reserved.
| Parameter 1 | Parameter 2 | Parameter 3 | Cause of Error |
|---|---|---|---|
0x1 |
Pointer to a WDF_POWER_ROUTINE_TIMED_OUT_DATA structure |
Reserved |
A framework-based driver has timed out during a power operation. This typically means that the device stack did not set the DO_POWER_PAGABLE bit and a driver attempted a pageable operation after the paging device stack was powered down. |
0x2 |
Reserved |
Reserved |
An attempt is being made to acquire a lock that is currently being held. |
0x3 |
WDFREQUEST handle |
The number of outstanding references that remain on both buffers |
Windows Driver Framework Verifier has encountered a fatal error. In particular, an I/O request was completed, but a framework request object cannot be deleted because there are outstanding references to the input buffer, the output buffer, or both. |
0x4 |
Reserved |
The caller's address |
A NULL parameter was passed to a function that required a non-NULL value. |
0x5 |
The handle value passed in |
Reserved |
A framework object handle of the incorrect type was passed to a framework object method. |
0x6 |
See table below. |
||
0x7 |
The handle of the framework object |
Reserved |
A driver attempted to delete a framework object incorrectly by calling WdfObjectDereference to delete a handle instead of calling WdfObjectDelete. |
0x8 |
The handle of the DMA transaction object |
Reserved |
An operation occurred on a DMA transaction object while it was not in the correct state. |
0x9 |
Currently unused. |
||
0xA |
A pointer to a WDF_QUEUE_FATAL_ERROR_DATA structure |
Reserved |
A fatal error has occurred while processing a request that is currently in the queue. |
0xB |
See table below. |
||
0xC |
WDFDEVICE handle |
Pointer to new PnP IRP |
A new state-changing PnP IRP arrived while the driver was processing another state-changing PnP IRP. |
0xD |
WDFDEVICE handle |
Pointer to power IRP |
A device's power policy owner received a power IRP that it did not request. There might be multiple power policy owners, but only one is allowed. A KMDF driver can change power policy ownership by calling WdfDeviceInitSetPowerPolicyOwnership. |
0xE |
IRQL at which the event callback function was called. |
IRQL at which the event callback function returned. |
An event callback function did not return at the same IRQL at which it was called. The callback function changed the IRQL directly or indirectly (for example, by acquiring a spinlock, which raises IRQL to DISPATCH_LEVEL, but not releasing the spinlock). |
0xF |
Address of an event callback function. |
Reserved |
An event callback function entered a critical region, but it did not leave the critical region before returning. |
Parameter 1 is equal to 0x6
If Parameter 1 is equal to 0x6, then a fatal error was made in handling a WDF request. In this case, Parameter 2 further specifies the type of fatal error that has been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.
| Parameter 2 | Parameter 3 | Cause of Error |
|---|---|---|
0x1 |
The address of the IRP |
No more I/O stack locations are available to format the underlying IRP. |
0x2 |
The WDF request handle value |
An attempt was made to format a framework request object that did not contain an IRP. |
0x3 |
The WDF request handle value |
The driver attempted to send a framework request that has already been sent to an I/O target. |
0x4 |
A pointer to a WDR_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA structure that contains a pointer to the IRP, a WDF request handle value, an IRP major function, and the number of bytes attempted to be written |
The driver has completed a framework request, but has written more bytes to the output buffer than are specified in the IRP. |
Parameter 1 is equal to 0xB
If Parameter 1 is equal to 0xB, then an attempt to acquire or release a lock was invalid. In this case, Parameter 3 further specifies the error that has been made.
| Parameter 2 | Parameter 3 | Cause of Error |
|---|---|---|
The handle value |
0x0 |
A handle passed to WdfObjectAcquireLock or WdfObjectReleaseLock represents an object that does not support synchronization locks. |
A WDF spin lock handle |
0x1 |
The spin lock is being released by a thread that did not acquire it. |
Cause
See the description of each code in the Parameters section for an explanation of the cause.
Resolution
The !analyze debug extension displays information about the bug check and can be helpful in gathering information, such as the faulting code module.
Typically, the WDF dump file will yield further information on the driver that caused this bug check. Use this command to look at the log file.
kd> !wdfkd.wdflogdump <WDF_Driver_Name>
If Parameter 1 is equal to 0x2, examine the caller's stack to determine the lock in question.
If Parameter 1 is equal to 0x3, the driver's Kernel-Mode Driver Framework error log will include details about the outstanding references.
If Parameter 1 is equal to 0x4, use the ln debugger command with the value of Parameter 3 as its argument to determine which function requires a non-NULL parameter.
If Parameter 1 is equal to 0x7, use the !wdfkd.wdfhandleParameter 2 extension command to determine the handle type.
If Parameter 1 is equal to 0xA, then the WDF_QUEUE_FATAL_ERROR_DATA structure will indicate either the problematic request or the queue handle. It will also indicate the NTSTATUS, if not STATUS_SUCCESS, when available.