WDF_VIOLATION (10d) on IRP Completion (with status != STATUS_SUCCESS)

OSR_Community_User · October 3, 2006, 9:38am

I’m encountering a WDF_VIOLATION (10d) which appears to be being triggered within one of my IOCTL handlers due to an IRP being completed with its Info field set > than the supplied OutputBufferLength. If it was being completed with a STATUS_SUCCESS status then I would expect this trap. However, in this case, it was being completed with STATUS_BUFFER_TOO_SMALL. So no data was going to be copied into the output buffer anyway.

If I determine that the supplied buffer is not large enough, can I really not just set Status to STATUS_BUFFER_TOO_SMALL and the Info field to the required size? i.e. Is WDF really correct in trapping on this when Status != STATUS_SUCCESS?

Here’s the related (annotated) windbg output

// start processing request

kd> !wdfrequest 0x7e81f300
!IRP 0x81b27008
!WDFQUEUE 0x7e7b2ad8
State: Pending, Allocated by WDF for incoming IRP

kd> !irp 0x81b27008 e
Irp is active with 5 stacks 5 is current (= 0x81b27108)
Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 81859230
ThreadListEntry.Blink = 81859230
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 010afef4
UserEvent = 819f8d48
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 010afef4
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 81b27048
Tail.Overlay.Thread = 81859020
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 8184d580
Tail.Overlay.ListEntry.Blink = 8184d580
Tail.Overlay.CurrentStackLocation = 81b27108
Tail.Overlay.OriginalFileObject = 81abfe38
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
\Driver\mydriver
Args: 00000028 00000000 00000632 00000000

// So in this case OutputBufferLength is 0x28

// now check whether the buffer is big enough

// status = WdfRequestRetrieveOutputBuffer(Request,
// pFrameInfo->uFrameLen,
// &buffer,
// NULL);// BufferLength

// determine that it is not (pFrameInfo->uFrameLen = 0x30) so status is now
// STATUS_BUFFER_TOO_SMALL
.
.
.
// complete the request with error: status=STATUS_BUFFER_TOO_SMALL and
// bytesReturned = 0x30

// WdfRequestCompleteWithInformation(Request, status, bytesReturned);

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework has detected that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000006, 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.
Arg2: 00000004, The driver has completed a framework request, but has
written more bytes to the output buffer than are specified
in the IRP.
Arg3: f6b2b968, A pointer to a
WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA
structure, which contains a pointer to the IRP, a WDF
request handle value, an IRP major function, and the
number of bytes attempted to be written.
Arg4: 81a735a8, Reserved.

kd> d f6b2b968
f6b2b968 00 f3 81 7e 08 70 b2 81-28 00 00 00 30 00 00 00 …~.p…(…0…
f6b2b978 0e b9 b2 f6 00 00 00 00-28 00 00 00 ac b9 b2 f6 …(…
f6b2b988 5f 5d 50 f6 ec e8 53 f6-f8 0c 7e 81 00 00 00 00 _]P…S…~…
f6b2b998 05 00 00 00 0d 00 00 00-0e 00 00 00 ec e8 53 f6 …S.
f6b2b9a8 a8 35 a7 81 c8 b9 b2 f6-a4 7f 50 f6 23 00 00 c0 .5…P.#…
f6b2b9b8 00 00 00 00 a8 35 a7 81-18 d6 53 f6 60 36 a7 81 …5…S.`6…
f6b2b9c8 d8 b9 b2 f6 c8 7f 50 f6-23 00 00 c0 00 00 00 00 …P.#…
f6b2b9d8 f4 b9 b2 f6 a2 24 4f f6-23 00 00 c0 30 00 00 00 …$O.#…0…

// WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA :
// WDFREQUEST Request; = 0x7e81f300
// PIRP Irp; = 0x81b27008
// ULONG OutputBufferLength; = 0x00000028
// ULONG_PTR Information; = 0x00000030
// UCHAR MajorFunction;

kd> !irp 0x81b27008 e
Irp is active with 5 stacks 5 is current (= 0x81b27108)
Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 81859230
ThreadListEntry.Blink = 81859230
IoStatus.Status = 00000000 // !!! why is this 0 when I defintely set it to
// STATUS_BUFFER_TOO_SMALL
IoStatus.Information = 00000030 // !!! the status value must be being ignored in this case
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 010afef4
UserEvent = 819f8d48
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 010afef4
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 81b27048
Tail.Overlay.Thread = 81859020
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 8184d580
Tail.Overlay.ListEntry.Blink = 8184d580
Tail.Overlay.CurrentStackLocation = 81b27108
Tail.Overlay.OriginalFileObject = 81abfe38
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
\Driver\mydriver
Args: 00000028 00000000 00000632 00000000

// the stack trace shows me completing the IRP with the error code :

f6b2b4dc 804f780d 00000003 f6b2b838 00000000 nt!RtlpBreakWithStatusInstruction
f6b2b528 804f83fa 00000003 81b27108 817e0cf8 nt!KiBugCheckDebugBreak+0x19
f6b2b908 804f8925 0000010d 00000006 00000004 nt!KeBugCheck2+0x574
f6b2b928 f6502c3b 0000010d 00000006 00000004 nt!KeBugCheckEx+0x1b
f6b2b944 f6505d2a 81a735a8 00000006 00000004 Wdf01000!FxVerifierBugCheck+0x24
f6b2b984 f6505d5f f653e8ec 817e0cf8 00000000 Wdf01000!FxRequest::VerifierValidateCompletedRequest+0x1b3
f6b2b9ac f6507fa4 c0000023 00000000 81a735a8 Wdf01000!FxRequest::CompleteInternal+0x21
f6b2b9c8 f6507fc8 c0000023 00000000 f6b2b9f4 Wdf01000!FxRequest::Complete+0xb3
f6b2b9d8 f64f24a2 c0000023 00000030 8184d520 Wdf01000!FxRequest::CompleteWithInformation+0x18
f6b2b9f4 f65a31ed 817e0cf8 7e81f300 c0000023 Wdf01000!imp_WdfRequestCompleteWithInformation+0x7f
f6b2ba0c f65aa57b 7e81f300 c0000023 00000030 mydriver!WdfRequestCompleteWithInformation+0x1d

Scott_Noone_OSR · October 3, 2006, 9:49am

I’ve bumped into this before also. The problem is that when you use
WdfRequestCompleteWithInformation WDF Verifier checks the bytes returned
parameter against the status in the IRP *before* the status in the IRP is
set. Since the default status in the IRP is STATUS_SUCCESS (as you can see
in your output), it thinks that you’re trying to complete the IRP with
success and a buffer that is too large.

You can quickly work around it by manually updating the status in the IRP
before completing:

WdfRequestWdmGetIrp(Request)->IoStatus.Status
= STATUS_BUFFER_TOO_SMALL;
WdfRequestCompleteWithInformation(Request,
STATUS_BUFFER_TOO_SMALL,
sizeof(IOCTL_STRUCTURE));

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> I’m encountering a WDF_VIOLATION (10d) which appears to be being triggered
> within one of my IOCTL handlers due to an IRP being completed with its
> Info field set > than the supplied OutputBufferLength. If it was being
> completed with a STATUS_SUCCESS status then I would expect this trap.
> However, in this case, it was being completed with
> STATUS_BUFFER_TOO_SMALL. So no data was going to be copied into the output
> buffer anyway.
>
> If I determine that the supplied buffer is not large enough, can I really
> not just set Status to STATUS_BUFFER_TOO_SMALL and the Info field to the
> required size? i.e. Is WDF really correct in trapping on this when Status
> != STATUS_SUCCESS?
>
> Here’s the related (annotated) windbg output
>
> --------------------------------------------
>
> // start processing request
>
> kd> !wdfrequest 0x7e81f300
> !IRP 0x81b27008
> !WDFQUEUE 0x7e7b2ad8
> State: Pending, Allocated by WDF for incoming IRP
>
> kd> !irp 0x81b27008 e
> Irp is active with 5 stacks 5 is current (= 0x81b27108)
> Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
> Flags = 00000000
> ThreadListEntry.Flink = 81859230
> ThreadListEntry.Blink = 81859230
> IoStatus.Status = 00000000
> IoStatus.Information = 00000000
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 010afef4
> UserEvent = 819f8d48
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 010afef4
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = 81b27048
> Tail.Overlay.Thread = 81859020
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 8184d580
> Tail.Overlay.ListEntry.Blink = 8184d580
> Tail.Overlay.CurrentStackLocation = 81b27108
> Tail.Overlay.OriginalFileObject = 81abfe38
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
> \Driver\mydriver
> Args: 00000028 00000000 00000632 00000000
>
> // So in this case OutputBufferLength is 0x28
>
> // now check whether the buffer is big enough
>
> // status = WdfRequestRetrieveOutputBuffer(Request,
> // pFrameInfo->uFrameLen,
> // &buffer,
> // NULL);// BufferLength
>
> // determine that it is not (pFrameInfo->uFrameLen = 0x30) so status is
> now
> // STATUS_BUFFER_TOO_SMALL
> .
> .
> .
> // complete the request with error: status=STATUS_BUFFER_TOO_SMALL and
> // bytesReturned = 0x30
>
> // WdfRequestCompleteWithInformation(Request, status, bytesReturned);
>
> WDF_VIOLATION (10d)
> The Kernel-Mode Driver Framework has detected that Windows detected an
> error
> in a framework-based driver. In general, the dump file will yield
> additional
> information about the driver that caused this bug check.
> Arguments:
> Arg1: 00000006, 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.
> Arg2: 00000004, The driver has completed a framework request, but has
> written more bytes to the output buffer than are specified
> in the IRP.
> Arg3: f6b2b968, A pointer to a
> WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA
> structure, which contains a pointer to the IRP, a WDF
> request handle value, an IRP major function, and the
> number of bytes attempted to be written.
> Arg4: 81a735a8, Reserved.
>
> kd> d f6b2b968
> f6b2b968 00 f3 81 7e 08 70 b2 81-28 00 00 00 30 00 00 00
> …~.p…(…0…
> f6b2b978 0e b9 b2 f6 00 00 00 00-28 00 00 00 ac b9 b2 f6
> …(…
> f6b2b988 5f 5d 50 f6 ec e8 53 f6-f8 0c 7e 81 00 00 00 00
> _]P…S…~…
> f6b2b998 05 00 00 00 0d 00 00 00-0e 00 00 00 ec e8 53 f6
> …S.
> f6b2b9a8 a8 35 a7 81 c8 b9 b2 f6-a4 7f 50 f6 23 00 00 c0
> .5…P.#…
> f6b2b9b8 00 00 00 00 a8 35 a7 81-18 d6 53 f6 60 36 a7 81
> …5…S.`6…
> f6b2b9c8 d8 b9 b2 f6 c8 7f 50 f6-23 00 00 c0 00 00 00 00
> …P.#…
> f6b2b9d8 f4 b9 b2 f6 a2 24 4f f6-23 00 00 c0 30 00 00 00
> …$O.#…0…
>
> // WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA :
> // WDFREQUEST Request; = 0x7e81f300
> // PIRP Irp; = 0x81b27008
> // ULONG OutputBufferLength; = 0x00000028
> // ULONG_PTR Information; = 0x00000030
> // UCHAR MajorFunction;
>
> kd> !irp 0x81b27008 e
> Irp is active with 5 stacks 5 is current (= 0x81b27108)
> Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
> Flags = 00000000
> ThreadListEntry.Flink = 81859230
> ThreadListEntry.Blink = 81859230
> IoStatus.Status = 00000000 // !!! why is this 0 when I defintely set it to
> // STATUS_BUFFER_TOO_SMALL
> IoStatus.Information = 00000030 // !!! the status value must be being
> ignored in this case
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 010afef4
> UserEvent = 819f8d48
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 010afef4
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = 81b27048
> Tail.Overlay.Thread = 81859020
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 8184d580
> Tail.Overlay.ListEntry.Blink = 8184d580
> Tail.Overlay.CurrentStackLocation = 81b27108
> Tail.Overlay.OriginalFileObject = 81abfe38
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
> \Driver\mydriver
> Args: 00000028 00000000 00000632 00000000
>
> // the stack trace shows me completing the IRP with the error code :
>
> f6b2b4dc 804f780d 00000003 f6b2b838 00000000
> nt!RtlpBreakWithStatusInstruction
> f6b2b528 804f83fa 00000003 81b27108 817e0cf8 nt!KiBugCheckDebugBreak+0x19
> f6b2b908 804f8925 0000010d 00000006 00000004 nt!KeBugCheck2+0x574
> f6b2b928 f6502c3b 0000010d 00000006 00000004 nt!KeBugCheckEx+0x1b
> f6b2b944 f6505d2a 81a735a8 00000006 00000004
> Wdf01000!FxVerifierBugCheck+0x24
> f6b2b984 f6505d5f f653e8ec 817e0cf8 00000000
> Wdf01000!FxRequest::VerifierValidateCompletedRequest+0x1b3
> f6b2b9ac f6507fa4 c0000023 00000000 81a735a8
> Wdf01000!FxRequest::CompleteInternal+0x21
> f6b2b9c8 f6507fc8 c0000023 00000000 f6b2b9f4
> Wdf01000!FxRequest::Complete+0xb3
> f6b2b9d8 f64f24a2 c0000023 00000030 8184d520
> Wdf01000!FxRequest::CompleteWithInformation+0x18
> f6b2b9f4 f65a31ed 817e0cf8 7e81f300 c0000023
> Wdf01000!imp_WdfRequestCompleteWithInformation+0x7f
> f6b2ba0c f65aa57b 7e81f300 c0000023 00000030
> mydriver!WdfRequestCompleteWithInformation+0x1d
>

OSR_Community_User · October 3, 2006, 9:57am

You are assuming that the BytesReturned parameter has the same
overloaded meanings as Irp->IoStatus.Information and that is a bad
assumption.

STATUS_BUFFER_OVERFLOW is a warning (not an error) that allows you to
return partial information to the caller. If you design your IOCTL API
such that the partial information includes enough information to
retrieve all of the data on a subsequent call, you should be all set.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@farsite.co.uk
Sent: Tuesday, October 03, 2006 9:37 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDF_VIOLATION (10d) on IRP Completion (with status !=
STATUS_SUCCESS)

I’m encountering a WDF_VIOLATION (10d) which appears to be being
triggered within one of my IOCTL handlers due to an IRP being completed
with its Info field set > than the supplied OutputBufferLength. If it
was being completed with a STATUS_SUCCESS status then I would expect
this trap. However, in this case, it was being completed with
STATUS_BUFFER_TOO_SMALL. So no data was going to be copied into the
output buffer anyway.

If I determine that the supplied buffer is not large enough, can I
really not just set Status to STATUS_BUFFER_TOO_SMALL and the Info field
to the required size? i.e. Is WDF really correct in trapping on this
when Status != STATUS_SUCCESS?

Here’s the related (annotated) windbg output

// start processing request

kd> !wdfrequest 0x7e81f300
!IRP 0x81b27008
!WDFQUEUE 0x7e7b2ad8
State: Pending, Allocated by WDF for incoming IRP

kd> !irp 0x81b27008 e
Irp is active with 5 stacks 5 is current (= 0x81b27108)
Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 81859230
ThreadListEntry.Blink = 81859230
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 010afef4
UserEvent = 819f8d48
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 010afef4
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 81b27048
Tail.Overlay.Thread = 81859020
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 8184d580
Tail.Overlay.ListEntry.Blink = 8184d580
Tail.Overlay.CurrentStackLocation = 81b27108
Tail.Overlay.OriginalFileObject = 81abfe38
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
\Driver\mydriver
Args: 00000028 00000000 00000632 00000000

// So in this case OutputBufferLength is 0x28

// now check whether the buffer is big enough

// status = WdfRequestRetrieveOutputBuffer(Request,
// pFrameInfo->uFrameLen,
// &buffer,
// NULL);// BufferLength

// determine that it is not (pFrameInfo->uFrameLen = 0x30) so status is
now
// STATUS_BUFFER_TOO_SMALL
.
.
.
// complete the request with error: status=STATUS_BUFFER_TOO_SMALL and
// bytesReturned = 0x30

// WdfRequestCompleteWithInformation(Request, status,
bytesReturned);

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework has detected that Windows detected an
error
in a framework-based driver. In general, the dump file will yield
additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000006, 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.
Arg2: 00000004, The driver has completed a framework request, but has
written more bytes to the output buffer than are specified
in the IRP.
Arg3: f6b2b968, A pointer to a
WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA
structure, which contains a pointer to the IRP, a WDF
request handle value, an IRP major function, and the
number of bytes attempted to be written.
Arg4: 81a735a8, Reserved.

kd> d f6b2b968
f6b2b968 00 f3 81 7e 08 70 b2 81-28 00 00 00 30 00 00 00
…~.p…(…0…
f6b2b978 0e b9 b2 f6 00 00 00 00-28 00 00 00 ac b9 b2 f6
…(…
f6b2b988 5f 5d 50 f6 ec e8 53 f6-f8 0c 7e 81 00 00 00 00
_]P…S…~…
f6b2b998 05 00 00 00 0d 00 00 00-0e 00 00 00 ec e8 53 f6
…S.
f6b2b9a8 a8 35 a7 81 c8 b9 b2 f6-a4 7f 50 f6 23 00 00 c0
.5…P.#…
f6b2b9b8 00 00 00 00 a8 35 a7 81-18 d6 53 f6 60 36 a7 81
…5…S.`6…
f6b2b9c8 d8 b9 b2 f6 c8 7f 50 f6-23 00 00 c0 00 00 00 00
…P.#…
f6b2b9d8 f4 b9 b2 f6 a2 24 4f f6-23 00 00 c0 30 00 00 00
…$O.#…0…

// WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA :
// WDFREQUEST Request; = 0x7e81f300
// PIRP Irp; = 0x81b27008
// ULONG OutputBufferLength; = 0x00000028
// ULONG_PTR Information; = 0x00000030
// UCHAR MajorFunction;

kd> !irp 0x81b27008 e
Irp is active with 5 stacks 5 is current (= 0x81b27108)
Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 81859230
ThreadListEntry.Blink = 81859230
IoStatus.Status = 00000000 // !!! why is this 0 when I defintely
set it to
//
STATUS_BUFFER_TOO_SMALL
IoStatus.Information = 00000030 // !!! the status value must be being
ignored in this case
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 010afef4
UserEvent = 819f8d48
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 010afef4
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 81b27048
Tail.Overlay.Thread = 81859020
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 8184d580
Tail.Overlay.ListEntry.Blink = 8184d580
Tail.Overlay.CurrentStackLocation = 81b27108
Tail.Overlay.OriginalFileObject = 81abfe38
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
\Driver\mydriver
Args: 00000028 00000000 00000632 00000000

// the stack trace shows me completing the IRP with the error code :

f6b2b4dc 804f780d 00000003 f6b2b838 00000000
nt!RtlpBreakWithStatusInstruction
f6b2b528 804f83fa 00000003 81b27108 817e0cf8
nt!KiBugCheckDebugBreak+0x19
f6b2b908 804f8925 0000010d 00000006 00000004 nt!KeBugCheck2+0x574
f6b2b928 f6502c3b 0000010d 00000006 00000004 nt!KeBugCheckEx+0x1b
f6b2b944 f6505d2a 81a735a8 00000006 00000004
Wdf01000!FxVerifierBugCheck+0x24
f6b2b984 f6505d5f f653e8ec 817e0cf8 00000000
Wdf01000!FxRequest::VerifierValidateCompletedRequest+0x1b3
f6b2b9ac f6507fa4 c0000023 00000000 81a735a8
Wdf01000!FxRequest::CompleteInternal+0x21
f6b2b9c8 f6507fc8 c0000023 00000000 f6b2b9f4
Wdf01000!FxRequest::Complete+0xb3
f6b2b9d8 f64f24a2 c0000023 00000030 8184d520
Wdf01000!FxRequest::CompleteWithInformation+0x18
f6b2b9f4 f65a31ed 817e0cf8 7e81f300 c0000023
Wdf01000!imp_WdfRequestCompleteWithInformation+0x7f
f6b2ba0c f65aa57b 7e81f300 c0000023 00000030
mydriver!WdfRequestCompleteWithInformation+0x1d

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · October 3, 2006, 4:36pm

I would consider this a clever hack that undermines WDF as a DDI
separate from the WDM DDI. It is still a clever hack in all the best
sense of the term.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Tuesday, October 03, 2006 9:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDF_VIOLATION (10d) on IRP Completion (with status
!= STATUS_SUCCESS)

I’ve bumped into this before also. The problem is that when you use
WdfRequestCompleteWithInformation WDF Verifier checks the bytes returned

parameter against the status in the IRP *before* the status in the IRP
is
set. Since the default status in the IRP is STATUS_SUCCESS (as you can
see
in your output), it thinks that you’re trying to complete the IRP with
success and a buffer that is too large.

You can quickly work around it by manually updating the status in the
IRP
before completing:

WdfRequestWdmGetIrp(Request)->IoStatus.Status
= STATUS_BUFFER_TOO_SMALL;
WdfRequestCompleteWithInformation(Request,

STATUS_BUFFER_TOO_SMALL,

sizeof(IOCTL_STRUCTURE));

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> I’m encountering a WDF_VIOLATION (10d) which appears to be being
triggered
> within one of my IOCTL handlers due to an IRP being completed with its

> Info field set > than the supplied OutputBufferLength. If it was being

> completed with a STATUS_SUCCESS status then I would expect this trap.
> However, in this case, it was being completed with
> STATUS_BUFFER_TOO_SMALL. So no data was going to be copied into the
output
> buffer anyway.
>
> If I determine that the supplied buffer is not large enough, can I
really
> not just set Status to STATUS_BUFFER_TOO_SMALL and the Info field to
the
> required size? i.e. Is WDF really correct in trapping on this when
Status
> != STATUS_SUCCESS?
>
> Here’s the related (annotated) windbg output
>
> --------------------------------------------
>
> // start processing request
>
> kd> !wdfrequest 0x7e81f300
> !IRP 0x81b27008
> !WDFQUEUE 0x7e7b2ad8
> State: Pending, Allocated by WDF for incoming IRP
>
> kd> !irp 0x81b27008 e
> Irp is active with 5 stacks 5 is current (= 0x81b27108)
> Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
> Flags = 00000000
> ThreadListEntry.Flink = 81859230
> ThreadListEntry.Blink = 81859230
> IoStatus.Status = 00000000
> IoStatus.Information = 00000000
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 010afef4
> UserEvent = 819f8d48
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 010afef4
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = 81b27048
> Tail.Overlay.Thread = 81859020
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 8184d580
> Tail.Overlay.ListEntry.Blink = 8184d580
> Tail.Overlay.CurrentStackLocation = 81b27108
> Tail.Overlay.OriginalFileObject = 81abfe38
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
> \Driver\mydriver
> Args: 00000028 00000000 00000632 00000000
>
> // So in this case OutputBufferLength is 0x28
>
> // now check whether the buffer is big enough
>
> // status = WdfRequestRetrieveOutputBuffer(Request,
> // pFrameInfo->uFrameLen,
> // &buffer,
> // NULL);// BufferLength
>
> // determine that it is not (pFrameInfo->uFrameLen = 0x30) so status
is
> now
> // STATUS_BUFFER_TOO_SMALL
> .
> .
> .
> // complete the request with error: status=STATUS_BUFFER_TOO_SMALL and
> // bytesReturned = 0x30
>
> // WdfRequestCompleteWithInformation(Request, status,
bytesReturned);
>
> WDF_VIOLATION (10d)
> The Kernel-Mode Driver Framework has detected that Windows detected an

> error
> in a framework-based driver. In general, the dump file will yield
> additional
> information about the driver that caused this bug check.
> Arguments:
> Arg1: 00000006, 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.
> Arg2: 00000004, The driver has completed a framework request, but has
> written more bytes to the output buffer than are specified
> in the IRP.
> Arg3: f6b2b968, A pointer to a
> WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA
> structure, which contains a pointer to the IRP, a WDF
> request handle value, an IRP major function, and the
> number of bytes attempted to be written.
> Arg4: 81a735a8, Reserved.
>
> kd> d f6b2b968
> f6b2b968 00 f3 81 7e 08 70 b2 81-28 00 00 00 30 00 00 00
> …~.p…(…0…
> f6b2b978 0e b9 b2 f6 00 00 00 00-28 00 00 00 ac b9 b2 f6
> …(…
> f6b2b988 5f 5d 50 f6 ec e8 53 f6-f8 0c 7e 81 00 00 00 00
> _]P…S…~…
> f6b2b998 05 00 00 00 0d 00 00 00-0e 00 00 00 ec e8 53 f6
> …S.
> f6b2b9a8 a8 35 a7 81 c8 b9 b2 f6-a4 7f 50 f6 23 00 00 c0
> .5…P.#…
> f6b2b9b8 00 00 00 00 a8 35 a7 81-18 d6 53 f6 60 36 a7 81
> …5…S.`6…
> f6b2b9c8 d8 b9 b2 f6 c8 7f 50 f6-23 00 00 c0 00 00 00 00
> …P.#…
> f6b2b9d8 f4 b9 b2 f6 a2 24 4f f6-23 00 00 c0 30 00 00 00
> …$O.#…0…
>
> // WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA :
> // WDFREQUEST Request; = 0x7e81f300
> // PIRP Irp; = 0x81b27008
> // ULONG OutputBufferLength; = 0x00000028
> // ULONG_PTR Information; = 0x00000030
> // UCHAR MajorFunction;
>
> kd> !irp 0x81b27008 e
> Irp is active with 5 stacks 5 is current (= 0x81b27108)
> Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
> Flags = 00000000
> ThreadListEntry.Flink = 81859230
> ThreadListEntry.Blink = 81859230
> IoStatus.Status = 00000000 // !!! why is this 0 when I defintely set
it to
> //
STATUS_BUFFER_TOO_SMALL
> IoStatus.Information = 00000030 // !!! the status value must be being
> ignored in this case
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 010afef4
> UserEvent = 819f8d48
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 010afef4
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = 81b27048
> Tail.Overlay.Thread = 81859020
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 8184d580
> Tail.Overlay.ListEntry.Blink = 8184d580
> Tail.Overlay.CurrentStackLocation = 81b27108
> Tail.Overlay.OriginalFileObject = 81abfe38
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
> \Driver\mydriver
> Args: 00000028 00000000 00000632 00000000
>
> // the stack trace shows me completing the IRP with the error code :
>
> f6b2b4dc 804f780d 00000003 f6b2b838 00000000
> nt!RtlpBreakWithStatusInstruction
> f6b2b528 804f83fa 00000003 81b27108 817e0cf8
nt!KiBugCheckDebugBreak+0x19
> f6b2b908 804f8925 0000010d 00000006 00000004 nt!KeBugCheck2+0x574
> f6b2b928 f6502c3b 0000010d 00000006 00000004 nt!KeBugCheckEx+0x1b
> f6b2b944 f6505d2a 81a735a8 00000006 00000004
> Wdf01000!FxVerifierBugCheck+0x24
> f6b2b984 f6505d5f f653e8ec 817e0cf8 00000000
> Wdf01000!FxRequest::VerifierValidateCompletedRequest+0x1b3
> f6b2b9ac f6507fa4 c0000023 00000000 81a735a8
> Wdf01000!FxRequest::CompleteInternal+0x21
> f6b2b9c8 f6507fc8 c0000023 00000000 f6b2b9f4
> Wdf01000!FxRequest::Complete+0xb3
> f6b2b9d8 f64f24a2 c0000023 00000030 8184d520
> Wdf01000!FxRequest::CompleteWithInformation+0x18
> f6b2b9f4 f65a31ed 817e0cf8 7e81f300 c0000023
> Wdf01000!imp_WdfRequestCompleteWithInformation+0x7f
> f6b2ba0c f65aa57b 7e81f300 c0000023 00000030
> mydriver!WdfRequestCompleteWithInformation+0x1d
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Scott_Noone_OSR · October 3, 2006, 4:41pm

Note that I did say “quickly”, not “elegantly”.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
I would consider this a clever hack that undermines WDF as a DDI
separate from the WDM DDI. It is still a clever hack in all the best
sense of the term.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Tuesday, October 03, 2006 9:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDF_VIOLATION (10d) on IRP Completion (with status
!= STATUS_SUCCESS)

I’ve bumped into this before also. The problem is that when you use
WdfRequestCompleteWithInformation WDF Verifier checks the bytes returned

parameter against the status in the IRP before the status in the IRP
is
set. Since the default status in the IRP is STATUS_SUCCESS (as you can
see
in your output), it thinks that you’re trying to complete the IRP with
success and a buffer that is too large.

You can quickly work around it by manually updating the status in the
IRP
before completing:

WdfRequestWdmGetIrp(Request)->IoStatus.Status
= STATUS_BUFFER_TOO_SMALL;
WdfRequestCompleteWithInformation(Request,

STATUS_BUFFER_TOO_SMALL,

sizeof(IOCTL_STRUCTURE));

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> I’m encountering a WDF_VIOLATION (10d) which appears to be being
triggered
> within one of my IOCTL handlers due to an IRP being completed with its

> Info field set > than the supplied OutputBufferLength. If it was being

> completed with a STATUS_SUCCESS status then I would expect this trap.
> However, in this case, it was being completed with
> STATUS_BUFFER_TOO_SMALL. So no data was going to be copied into the
output
> buffer anyway.
>
> If I determine that the supplied buffer is not large enough, can I
really
> not just set Status to STATUS_BUFFER_TOO_SMALL and the Info field to
the
> required size? i.e. Is WDF really correct in trapping on this when
Status
> != STATUS_SUCCESS?
>
> Here’s the related (annotated) windbg output
>
> --------------------------------------------
>
> // start processing request
>
> kd> !wdfrequest 0x7e81f300
> !IRP 0x81b27008
> !WDFQUEUE 0x7e7b2ad8
> State: Pending, Allocated by WDF for incoming IRP
>
> kd> !irp 0x81b27008 e
> Irp is active with 5 stacks 5 is current (= 0x81b27108)
> Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
> Flags = 00000000
> ThreadListEntry.Flink = 81859230
> ThreadListEntry.Blink = 81859230
> IoStatus.Status = 00000000
> IoStatus.Information = 00000000
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 010afef4
> UserEvent = 819f8d48
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 010afef4
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = 81b27048
> Tail.Overlay.Thread = 81859020
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 8184d580
> Tail.Overlay.ListEntry.Blink = 8184d580
> Tail.Overlay.CurrentStackLocation = 81b27108
> Tail.Overlay.OriginalFileObject = 81abfe38
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
> \Driver\mydriver
> Args: 00000028 00000000 00000632 00000000
>
> // So in this case OutputBufferLength is 0x28
>
> // now check whether the buffer is big enough
>
> // status = WdfRequestRetrieveOutputBuffer(Request,
> // pFrameInfo->uFrameLen,
> // &buffer,
> // NULL);// BufferLength
>
> // determine that it is not (pFrameInfo->uFrameLen = 0x30) so status
is
> now
> // STATUS_BUFFER_TOO_SMALL
> .
> .
> .
> // complete the request with error: status=STATUS_BUFFER_TOO_SMALL and
> // bytesReturned = 0x30
>
> // WdfRequestCompleteWithInformation(Request, status,
bytesReturned);
>
> WDF_VIOLATION (10d)
> The Kernel-Mode Driver Framework has detected that Windows detected an

> error
> in a framework-based driver. In general, the dump file will yield
> additional
> information about the driver that caused this bug check.
> Arguments:
> Arg1: 00000006, 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.
> Arg2: 00000004, The driver has completed a framework request, but has
> written more bytes to the output buffer than are specified
> in the IRP.
> Arg3: f6b2b968, A pointer to a
> WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA
> structure, which contains a pointer to the IRP, a WDF
> request handle value, an IRP major function, and the
> number of bytes attempted to be written.
> Arg4: 81a735a8, Reserved.
>
> kd> d f6b2b968
> f6b2b968 00 f3 81 7e 08 70 b2 81-28 00 00 00 30 00 00 00
> …~.p…(…0…
> f6b2b978 0e b9 b2 f6 00 00 00 00-28 00 00 00 ac b9 b2 f6
> …(…
> f6b2b988 5f 5d 50 f6 ec e8 53 f6-f8 0c 7e 81 00 00 00 00
> _]P…S…~…
> f6b2b998 05 00 00 00 0d 00 00 00-0e 00 00 00 ec e8 53 f6
> …S.
> f6b2b9a8 a8 35 a7 81 c8 b9 b2 f6-a4 7f 50 f6 23 00 00 c0
> .5…P.#…
> f6b2b9b8 00 00 00 00 a8 35 a7 81-18 d6 53 f6 60 36 a7 81
> …5…S.`6…
> f6b2b9c8 d8 b9 b2 f6 c8 7f 50 f6-23 00 00 c0 00 00 00 00
> …P.#…
> f6b2b9d8 f4 b9 b2 f6 a2 24 4f f6-23 00 00 c0 30 00 00 00
> …$O.#…0…
>
> // WDF_REQUEST_FATAL_ERROR_INFORMATION_LENGTH_MISMATCH_DATA :
> // WDFREQUEST Request; = 0x7e81f300
> // PIRP Irp; = 0x81b27008
> // ULONG OutputBufferLength; = 0x00000028
> // ULONG_PTR Information; = 0x00000030
> // UCHAR MajorFunction;
>
> kd> !irp 0x81b27008 e
> Irp is active with 5 stacks 5 is current (= 0x81b27108)
> Mdl=81a0a888: No System Buffer: Thread 81859020: Irp stack trace.
> Flags = 00000000
> ThreadListEntry.Flink = 81859230
> ThreadListEntry.Blink = 81859230
> IoStatus.Status = 00000000 // !!! why is this 0 when I defintely set
it to
> //
STATUS_BUFFER_TOO_SMALL
> IoStatus.Information = 00000030 // !!! the status value must be being
> ignored in this case
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 010afef4
> UserEvent = 819f8d48
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 010afef4
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = 81b27048
> Tail.Overlay.Thread = 81859020
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 8184d580
> Tail.Overlay.ListEntry.Blink = 8184d580
> Tail.Overlay.CurrentStackLocation = 81b27108
> Tail.Overlay.OriginalFileObject = 81abfe38
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[e, 0] 5 1 817e0020 81abfe38 00000000-00000000 pending
> \Driver\mydriver
> Args: 00000028 00000000 00000632 00000000
>
> // the stack trace shows me completing the IRP with the error code :
>
> f6b2b4dc 804f780d 00000003 f6b2b838 00000000
> nt!RtlpBreakWithStatusInstruction
> f6b2b528 804f83fa 00000003 81b27108 817e0cf8
nt!KiBugCheckDebugBreak+0x19
> f6b2b908 804f8925 0000010d 00000006 00000004 nt!KeBugCheck2+0x574
> f6b2b928 f6502c3b 0000010d 00000006 00000004 nt!KeBugCheckEx+0x1b
> f6b2b944 f6505d2a 81a735a8 00000006 00000004
> Wdf01000!FxVerifierBugCheck+0x24
> f6b2b984 f6505d5f f653e8ec 817e0cf8 00000000
> Wdf01000!FxRequest::VerifierValidateCompletedRequest+0x1b3
> f6b2b9ac f6507fa4 c0000023 00000000 81a735a8
> Wdf01000!FxRequest::CompleteInternal+0x21
> f6b2b9c8 f6507fc8 c0000023 00000000 f6b2b9f4
> Wdf01000!FxRequest::Complete+0xb3
> f6b2b9d8 f64f24a2 c0000023 00000030 8184d520
> Wdf01000!FxRequest::CompleteWithInformation+0x18
> f6b2b9f4 f65a31ed 817e0cf8 7e81f300 c0000023
> Wdf01000!imp_WdfRequestCompleteWithInformation+0x7f
> f6b2ba0c f65aa57b 7e81f300 c0000023 00000030
> mydriver!WdfRequestCompleteWithInformation+0x1d
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer