Basic Driver Assertion Failure

When I run my driver under Windows XP…and read/write to it from a sample app I don’t receive any errors. However, when I run the same driver under Windows 7, I receive a bug check once I read/write to the driver. CreateFile works fine, but once ReadFile or WriteFile is executed, I received a BSOD. I have placed the EvtRead/EvtWrite functions below along with the analysis. In this basic driver, it just handles basic read/writes.

///////////////////////////

#include “ProtoTypes.h”

VOID
BasicEvtRead(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t Length
)
/*++

Routine Description:

This event is called when the framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with the
I/O request.
Request - Handle to a framework request object.

Length - number of bytes to be written.
Queue is by default configured to fail zero length read & write requests.

Return Value:

None
–*/
{
NTSTATUS status = STATUS_SUCCESS;
PRESPONSE output_buffer;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
ULONG_PTR bytesWritten = 0;
size_t output_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context = BasicGetFileObjectData(WdfRequestGetFileObject(Request));
//
// Get the response buffer. Since the device is set to do buffered
// I/O, this function will retrieve Irp->AssociatedIrp.SystemBuffer.
//

status = WdfRequestRetrieveOutputBuffer(Request,0, &output_buffer, &output_buffer_length);
if(!NT_SUCCESS(status))
{
WdfRequestComplete(Request, status);
return;

}
else{
switch (file_object_context->function_code)
{
case 0x1:
output_buffer->function_code = (file_object_context->function_code);
output_buffer->data = 2390;
bytesWritten = Length;
break;
default:
bytesWritten = 0;
}

}
WdfRequestCompleteWithInformation(Request, status, bytesWritten);
}

VOID
BasicEvtWrite (
WDFQUEUE Queue,
WDFREQUEST Request,
size_t Length
)
/*++

Routine Description:

Performs read from the toaster device. This event is called when the
framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with the
I/O request.
Request - Handle to a framework request object.

Lenght - Length of the data buffer associated with the request.
By default, the queue does not dispatch
zero length read & write requests to the driver and instead to
complete such requests with status success. So we will never get
a zero length request.

Return Value:

None.

–*/
{
NTSTATUS status = STATUS_SUCCESS;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
PREQUEST input_buffer;
ULONG_PTR bytesWritten = 0;
size_t input_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context = BasicGetFileObjectData(WdfRequestGetFileObject(Request));

//
// Get the request memory and perform read operation here
//
status = WdfRequestRetrieveInputBuffer(Request, 0, &input_buffer, &input_buffer_length);
if( NT_SUCCESS(status) )
{
file_object_context->function_code = (input_buffer->function_code);
bytesWritten = Length;
}
else
{
WdfRequestComplete(Request, status);
return;
}

WdfRequestCompleteWithInformation(Request, status, bytesWritten);
}

VOID
BasicEvtDeviceControl(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
/*++
Routine Description:

This event is called when the framework receives IRP_MJ_DEVICE_CONTROL
requests from the system.

Arguments:

Queue - Handle to the framework queue object that is associated
with the I/O request.
Request - Handle to a framework request object.

OutputBufferLength - length of the request’s output buffer,
if an output buffer is available.
InputBufferLength - length of the request’s input buffer,
if an input buffer is available.

IoControlCode - the driver-defined or system-defined I/O control code
(IOCTL) that is associated with the request.

Return Value:

VOID

–*/
{
NTSTATUS status= STATUS_SUCCESS;

UNREFERENCED_PARAMETER(Queue);
UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);

//
// Use WdfRequestRetrieveInputBuffer and WdfRequestRetrieveOutputBuffer
// to get the request buffers.
//

switch (IoControlCode) {

default:
status = STATUS_INVALID_DEVICE_REQUEST;
}

//
// Complete the Request.
//
WdfRequestCompleteWithInformation(Request, status, (ULONG_PTR) 0);
}
/////////////////////

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000420, The exception code that was not handled
Arg2: bc385595, The address that the exception occurred at
Arg3: b6293afc, Trap Frame
Arg4: 00000000

Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for basic.sys

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

FAULTING_IP:
basic+1595
bc385595 cd2c int 2Ch

TRAP_FRAME: b6293afc – (.trap 0xffffffffb6293afc)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000002 edx=00000065 esi=8537c28c edi=8537c1b0
eip=bc385595 esp=b6293b70 ebp=b6293b70 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286
basic+0x1595:
bc385595 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: DriverTest.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 82ad004c to 82af9eb4

STACK_TEXT:
b6293664 82ad004c 0000008e c0000420 bc385595 nt!KeBugCheckEx+0x1e
b6293a8c 82a59de6 b6293aa8 00000000 b6293afc nt!KiDispatchException+0x1ac
b6293af4 82a59d82 b6293b70 bc385597 badb0d00 nt!CommonDispatchException+0x4a
b6293b14 82a80654 76c89001 000001cb 000001c0 nt!Kei386EoiHelper+0x17a
b6293b70 bc3854c0 855fcaa8 855fcaa0 00000000 nt!MiUpdateWsle+0x231
WARNING: Stack unwind information not available. Following frames may be wrong.
b6293b94 8af1802a 7ac83e48 77105580 00000004 basic+0x14c0
b6293bb0 8af19256 7ac83e48 77105580 00000004 Wdf01000!FxIoQueueIoRead::Invoke+0x2a
b6293bd8 8af1b9ac 77105580 88efaa78 8537c1b0 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x1a3
b6293bf4 8af1ca36 8537c100 00000000 88f544f8 Wdf01000!FxIoQueue::DispatchEvents+0x3be
b6293c14 8af1e824 88efaa78 8849ab60 8789b030 Wdf01000!FxIoQueue::QueueRequest+0x1ec
b6293c38 8af0da3f 878bd2a0 b6293c5c 82a5258e Wdf01000!FxPkgIo::Dispatch+0x27d
b6293c44 82a5258e 8789b030 878bd2a0 878bd2a0 Wdf01000!FxDevice::Dispatch+0x7f
b6293c5c 82c45a31 878bd2a0 878bd334 8849ab60 nt!IofCallDriver+0x63
b6293c7c 82c7e380 8789b030 8849ab60 00000001 nt!IopSynchronousServiceTail+0x1f8
b6293d08 82a591fa 8789b030 878bd2a0 00000000 nt!NtReadFile+0x644
b6293d08 771870b4 8789b030 878bd2a0 00000000 nt!KiFastCallEntry+0x12a
0030f8e4 00000000 00000000 00000000 00000000 0x771870b4

STACK_COMMAND: kb

FOLLOWUP_IP:
basic+1595
bc385595 cd2c int 2Ch

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: basic+1595

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: basic

IMAGE_NAME: basic.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4e4da09e

FAILURE_BUCKET_ID: 0x8E_basic+1595

BUCKET_ID: 0x8E_basic+1595

You should fix your symbols:

.symfix
.reload -f -n

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, August 23, 2011 2:17 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Basic Driver Assertion Failure

When I run my driver under Windows XP…and read/write to it from a sample
app I don’t receive any errors. However, when I run the same driver under
Windows 7, I receive a bug check once I read/write to the driver. CreateFile
works fine, but once ReadFile or WriteFile is executed, I received a BSOD. I
have placed the EvtRead/EvtWrite functions below along with the analysis. In
this basic driver, it just handles basic read/writes.

///////////////////////////

#include “ProtoTypes.h”

VOID
BasicEvtRead(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t Length
)
/++

Routine Description:

This event is called when the framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with
the
I/O request.
Request - Handle to a framework request object.

Length - number of bytes to be written.
Queue is by default configured to fail zero length read &
write requests.

Return Value:

None
/
{
NTSTATUS status = STATUS_SUCCESS;
PRESPONSE output_buffer;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
ULONG_PTR bytesWritten = 0;
size_t output_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context =
BasicGetFileObjectData(WdfRequestGetFileObject(Request));
//
// Get the response buffer. Since the device is set to do buffered
// I/O, this function will retrieve Irp->AssociatedIrp.SystemBuffer.
//

status = WdfRequestRetrieveOutputBuffer(Request,0, &output_buffer,
&output_buffer_length);
if(!NT_SUCCESS(status))
{
WdfRequestComplete(Request, status);
return;

}
else{
switch (file_object_context->function_code)
{
case 0x1:
output_buffer->function_code =
(file_object_context->function_code);
output_buffer->data = 2390;
bytesWritten = Length;
break;
default:
bytesWritten = 0;
}

}
WdfRequestCompleteWithInformation(Request, status, bytesWritten); }

VOID
BasicEvtWrite (
WDFQUEUE Queue,
WDFREQUEST Request,
size_t Length
)
/++

Routine Description:

Performs read from the toaster device. This event is called when the
framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with
the
I/O request.
Request - Handle to a framework request object.

Lenght - Length of the data buffer associated with the request.
By default, the queue does not dispatch
zero length read & write requests to the driver and instead
to
complete such requests with status success. So we will
never get
a zero length request.

Return Value:

None.

/
{
NTSTATUS status = STATUS_SUCCESS;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
PREQUEST input_buffer;
ULONG_PTR bytesWritten = 0;
size_t input_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context =
BasicGetFileObjectData(WdfRequestGetFileObject(Request));

//
// Get the request memory and perform read operation here
//
status = WdfRequestRetrieveInputBuffer(Request, 0, &input_buffer,
&input_buffer_length);
if( NT_SUCCESS(status) )
{
file_object_context->function_code =
(input_buffer->function_code);
bytesWritten = Length;
}
else
{
WdfRequestComplete(Request, status);
return;
}

WdfRequestCompleteWithInformation(Request, status, bytesWritten); }

VOID
BasicEvtDeviceControl(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
/++
Routine Description:

This event is called when the framework receives IRP_MJ_DEVICE_CONTROL
requests from the system.

Arguments:

Queue - Handle to the framework queue object that is associated
with the I/O request.
Request - Handle to a framework request object.

OutputBufferLength - length of the request’s output buffer,
if an output buffer is available.
InputBufferLength - length of the request’s input buffer,
if an input buffer is available.

IoControlCode - the driver-defined or system-defined I/O control code
(IOCTL) that is associated with the request.

Return Value:

VOID

/
{
NTSTATUS status= STATUS_SUCCESS;

UNREFERENCED_PARAMETER(Queue);
UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);

//
// Use WdfRequestRetrieveInputBuffer and WdfRequestRetrieveOutputBuffer
// to get the request buffers.
//

switch (IoControlCode) {

default:
status = STATUS_INVALID_DEVICE_REQUEST;
}

//
// Complete the Request.
//
WdfRequestCompleteWithInformation(Request, status, (ULONG_PTR) 0); }
/////////////////////

*******************************************************************



Bugcheck Analysis



**********************************************************************


KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints the
driver/function that caused the problem. Always note this address as well
as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded
breakpoint or assertion was hit, but this system was booted /NODEBUG. This
is not supposed to happen as developers should never have hardcoded
breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the system is
booted /DEBUG. This will let us see why this breakpoint is happening.
Arguments:
Arg1: c0000420, The exception code that was not handled
Arg2: bc385595, The address that the exception occurred at
Arg3: b6293afc, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

ERROR: Module load completed but symbols could not be loaded for
basic.sys

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

FAULTING_IP:
basic+1595
bc385595 cd2c int 2Ch

TRAP_FRAME: b6293afc – (.trap 0xffffffffb6293afc) ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000002 edx=00000065 esi=8537c28c
edi=8537c1b0
eip=bc385595 esp=b6293b70 ebp=b6293b70 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000286
basic+0x1595:
bc385595 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: DriverTest.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 82ad004c to 82af9eb4

STACK_TEXT:
b6293664 82ad004c 0000008e c0000420 bc385595 nt!KeBugCheckEx+0x1e b6293a8c
82a59de6 b6293aa8 00000000 b6293afc nt!KiDispatchException+0x1ac
b6293af4 82a59d82 b6293b70 bc385597 badb0d00 nt!CommonDispatchException+0x4a
b6293b14 82a80654 76c89001 000001cb 000001c0 nt!Kei386EoiHelper+0x17a
b6293b70 bc3854c0 855fcaa8 855fcaa0 00000000 nt!MiUpdateWsle+0x231
WARNING: Stack unwind information not available. Following frames may be
wrong.
b6293b94 8af1802a 7ac83e48 77105580 00000004 basic+0x14c0
b6293bb0 8af19256 7ac83e48 77105580 00000004
Wdf01000!FxIoQueueIoRead::Invoke+0x2a
b6293bd8 8af1b9ac 77105580 88efaa78 8537c1b0
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x1a3
b6293bf4 8af1ca36 8537c100 00000000 88f544f8
Wdf01000!FxIoQueue::DispatchEvents+0x3be
b6293c14 8af1e824 88efaa78 8849ab60 8789b030
Wdf01000!FxIoQueue::QueueRequest+0x1ec
b6293c38 8af0da3f 878bd2a0 b6293c5c 82a5258e
Wdf01000!FxPkgIo::Dispatch+0x27d
b6293c44 82a5258e 8789b030 878bd2a0 878bd2a0
Wdf01000!FxDevice::Dispatch+0x7f b6293c5c 82c45a31 878bd2a0 878bd334
8849ab60 nt!IofCallDriver+0x63 b6293c7c 82c7e380 8789b030 8849ab60 00000001
nt!IopSynchronousServiceTail+0x1f8
b6293d08 82a591fa 8789b030 878bd2a0 00000000 nt!NtReadFile+0x644
b6293d08 771870b4 8789b030 878bd2a0 00000000 nt!KiFastCallEntry+0x12a
0030f8e4 00000000 00000000 00000000 00000000 0x771870b4

STACK_COMMAND: kb

FOLLOWUP_IP:
basic+1595
bc385595 cd2c int 2Ch

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: basic+1595

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: basic

IMAGE_NAME: basic.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4e4da09e

FAILURE_BUCKET_ID: 0x8E_basic+1595

BUCKET_ID: 0x8E_basic+1595


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Did you mark any of these functions as pagable in a #pragma? Do you have the PAGED_CODE macro in any of these functions (perhaps you removed them for clarity). Fix the symbols for your driver as well, it will give you better clarity as to where in your code the int 2c is hitting. PAGED_CODE turns into an NT_ASSERT, which turns into an int 2ch and PAGED_CODE has the following

#define PAGED_CODE() { \
if (KeGetCurrentIrql() > APC_LEVEL) { \
KdPrint((“EX: Pageable code called at IRQL %d\n”, KeGetCurrentIrql())); \
PAGED_ASSERT(FALSE); \
} \
}

The PAGED_ASSERT(FALSE) is probably where the int2c is coming from

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, August 23, 2011 11:17 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Basic Driver Assertion Failure

When I run my driver under Windows XP…and read/write to it from a sample app I don’t receive any errors. However, when I run the same driver under Windows 7, I receive a bug check once I read/write to the driver. CreateFile works fine, but once ReadFile or WriteFile is executed, I received a BSOD. I have placed the EvtRead/EvtWrite functions below along with the analysis. In this basic driver, it just handles basic read/writes.

///////////////////////////

#include “ProtoTypes.h”

VOID
BasicEvtRead(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t Length
)
/*++

Routine Description:

This event is called when the framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with the
I/O request.
Request - Handle to a framework request object.

Length - number of bytes to be written.
Queue is by default configured to fail zero length read & write requests.

Return Value:

None
–*/
{
NTSTATUS status = STATUS_SUCCESS;
PRESPONSE output_buffer;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
ULONG_PTR bytesWritten = 0;
size_t output_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context = BasicGetFileObjectData(WdfRequestGetFileObject(Request));
//
// Get the response buffer. Since the device is set to do buffered
// I/O, this function will retrieve Irp->AssociatedIrp.SystemBuffer.
//

status = WdfRequestRetrieveOutputBuffer(Request,0, &output_buffer, &output_buffer_length);
if(!NT_SUCCESS(status))
{
WdfRequestComplete(Request, status);
return;

}
else{
switch (file_object_context->function_code)
{
case 0x1:
output_buffer->function_code = (file_object_context->function_code);
output_buffer->data = 2390;
bytesWritten = Length;
break;
default:
bytesWritten = 0;
}

}
WdfRequestCompleteWithInformation(Request, status, bytesWritten); }

VOID
BasicEvtWrite (
WDFQUEUE Queue,
WDFREQUEST Request,
size_t Length
)
/*++

Routine Description:

Performs read from the toaster device. This event is called when the
framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with the
I/O request.
Request - Handle to a framework request object.

Lenght - Length of the data buffer associated with the request.
By default, the queue does not dispatch
zero length read & write requests to the driver and instead to
complete such requests with status success. So we will never get
a zero length request.

Return Value:

None.

–*/
{
NTSTATUS status = STATUS_SUCCESS;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
PREQUEST input_buffer;
ULONG_PTR bytesWritten = 0;
size_t input_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context = BasicGetFileObjectData(WdfRequestGetFileObject(Request));

//
// Get the request memory and perform read operation here
//
status = WdfRequestRetrieveInputBuffer(Request, 0, &input_buffer, &input_buffer_length);
if( NT_SUCCESS(status) )
{
file_object_context->function_code = (input_buffer->function_code);
bytesWritten = Length;
}
else
{
WdfRequestComplete(Request, status);
return;
}

WdfRequestCompleteWithInformation(Request, status, bytesWritten); }

VOID
BasicEvtDeviceControl(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
/*++
Routine Description:

This event is called when the framework receives IRP_MJ_DEVICE_CONTROL
requests from the system.

Arguments:

Queue - Handle to the framework queue object that is associated
with the I/O request.
Request - Handle to a framework request object.

OutputBufferLength - length of the request’s output buffer,
if an output buffer is available.
InputBufferLength - length of the request’s input buffer,
if an input buffer is available.

IoControlCode - the driver-defined or system-defined I/O control code
(IOCTL) that is associated with the request.

Return Value:

VOID

–*/
{
NTSTATUS status= STATUS_SUCCESS;

UNREFERENCED_PARAMETER(Queue);
UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);

//
// Use WdfRequestRetrieveInputBuffer and WdfRequestRetrieveOutputBuffer
// to get the request buffers.
//

switch (IoControlCode) {

default:
status = STATUS_INVALID_DEVICE_REQUEST;
}

//
// Complete the Request.
//
WdfRequestCompleteWithInformation(Request, status, (ULONG_PTR) 0); } /////////////////////

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening.
Arguments:
Arg1: c0000420, The exception code that was not handled
Arg2: bc385595, The address that the exception occurred at
Arg3: b6293afc, Trap Frame
Arg4: 00000000

Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for basic.sys

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

FAULTING_IP:
basic+1595
bc385595 cd2c int 2Ch

TRAP_FRAME: b6293afc – (.trap 0xffffffffb6293afc) ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000002 edx=00000065 esi=8537c28c edi=8537c1b0
eip=bc385595 esp=b6293b70 ebp=b6293b70 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286
basic+0x1595:
bc385595 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: DriverTest.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 82ad004c to 82af9eb4

STACK_TEXT:
b6293664 82ad004c 0000008e c0000420 bc385595 nt!KeBugCheckEx+0x1e b6293a8c 82a59de6 b6293aa8 00000000 b6293afc nt!KiDispatchException+0x1ac
b6293af4 82a59d82 b6293b70 bc385597 badb0d00 nt!CommonDispatchException+0x4a
b6293b14 82a80654 76c89001 000001cb 000001c0 nt!Kei386EoiHelper+0x17a
b6293b70 bc3854c0 855fcaa8 855fcaa0 00000000 nt!MiUpdateWsle+0x231
WARNING: Stack unwind information not available. Following frames may be wrong.
b6293b94 8af1802a 7ac83e48 77105580 00000004 basic+0x14c0
b6293bb0 8af19256 7ac83e48 77105580 00000004 Wdf01000!FxIoQueueIoRead::Invoke+0x2a
b6293bd8 8af1b9ac 77105580 88efaa78 8537c1b0 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x1a3
b6293bf4 8af1ca36 8537c100 00000000 88f544f8 Wdf01000!FxIoQueue::DispatchEvents+0x3be
b6293c14 8af1e824 88efaa78 8849ab60 8789b030 Wdf01000!FxIoQueue::QueueRequest+0x1ec
b6293c38 8af0da3f 878bd2a0 b6293c5c 82a5258e Wdf01000!FxPkgIo::Dispatch+0x27d
b6293c44 82a5258e 8789b030 878bd2a0 878bd2a0 Wdf01000!FxDevice::Dispatch+0x7f b6293c5c 82c45a31 878bd2a0 878bd334 8849ab60 nt!IofCallDriver+0x63 b6293c7c 82c7e380 8789b030 8849ab60 00000001 nt!IopSynchronousServiceTail+0x1f8
b6293d08 82a591fa 8789b030 878bd2a0 00000000 nt!NtReadFile+0x644
b6293d08 771870b4 8789b030 878bd2a0 00000000 nt!KiFastCallEntry+0x12a
0030f8e4 00000000 00000000 00000000 00000000 0x771870b4

STACK_COMMAND: kb

FOLLOWUP_IP:
basic+1595
bc385595 cd2c int 2Ch

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: basic+1595

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: basic

IMAGE_NAME: basic.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4e4da09e

FAILURE_BUCKET_ID: 0x8E_basic+1595

BUCKET_ID: 0x8E_basic+1595


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Yet another good use of the headers…

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, August 23, 2011 2:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Basic Driver Assertion Failure

Did you mark any of these functions as pagable in a #pragma? Do you have the
PAGED_CODE macro in any of these functions (perhaps you removed them for
clarity). Fix the symbols for your driver as well, it will give you better
clarity as to where in your code the int 2c is hitting. PAGED_CODE turns
into an NT_ASSERT, which turns into an int 2ch and PAGED_CODE has the
following

#define PAGED_CODE() {
\
if (KeGetCurrentIrql() > APC_LEVEL) {
\
KdPrint((“EX: Pageable code called at IRQL %d\n”,
KeGetCurrentIrql())); \
PAGED_ASSERT(FALSE);
\
}
\
}

The PAGED_ASSERT(FALSE) is probably where the int2c is coming from

d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, August 23, 2011 11:17 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Basic Driver Assertion Failure

When I run my driver under Windows XP…and read/write to it from a sample
app I don’t receive any errors. However, when I run the same driver under
Windows 7, I receive a bug check once I read/write to the driver. CreateFile
works fine, but once ReadFile or WriteFile is executed, I received a BSOD. I
have placed the EvtRead/EvtWrite functions below along with the analysis. In
this basic driver, it just handles basic read/writes.

///////////////////////////

#include “ProtoTypes.h”

VOID
BasicEvtRead(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t Length
)
/*++

Routine Description:

This event is called when the framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with
the
I/O request.
Request - Handle to a framework request object.

Length - number of bytes to be written.
Queue is by default configured to fail zero length read &
write requests.

Return Value:

None
–*/
{
NTSTATUS status = STATUS_SUCCESS;
PRESPONSE output_buffer;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
ULONG_PTR bytesWritten = 0;
size_t output_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context =
BasicGetFileObjectData(WdfRequestGetFileObject(Request));
//
// Get the response buffer. Since the device is set to do buffered
// I/O, this function will retrieve Irp->AssociatedIrp.SystemBuffer.
//

status = WdfRequestRetrieveOutputBuffer(Request,0, &output_buffer,
&output_buffer_length);
if(!NT_SUCCESS(status))
{
WdfRequestComplete(Request, status);
return;

}
else{
switch (file_object_context->function_code)
{
case 0x1:
output_buffer->function_code =
(file_object_context->function_code);
output_buffer->data = 2390;
bytesWritten = Length;
break;
default:
bytesWritten = 0;
}

}
WdfRequestCompleteWithInformation(Request, status, bytesWritten); }

VOID
BasicEvtWrite (
WDFQUEUE Queue,
WDFREQUEST Request,
size_t Length
)
/*++

Routine Description:

Performs read from the toaster device. This event is called when the
framework receives IRP_MJ_READ requests.

Arguments:

Queue - Handle to the framework queue object that is associated with
the
I/O request.
Request - Handle to a framework request object.

Lenght - Length of the data buffer associated with the request.
By default, the queue does not dispatch
zero length read & write requests to the driver and instead
to
complete such requests with status success. So we will
never get
a zero length request.

Return Value:

None.

–*/
{
NTSTATUS status = STATUS_SUCCESS;
PDEVICE_CONTEXT devExt;
PBASIC_FILEOBJECT_CONTEXT file_object_context;
PREQUEST input_buffer;
ULONG_PTR bytesWritten = 0;
size_t input_buffer_length;

// Get a pointer to our device extension
devExt = BasicGetDeviceContext( WdfIoQueueGetDevice(Queue) );

// Get a pointer to our file object context
file_object_context =
BasicGetFileObjectData(WdfRequestGetFileObject(Request));

//
// Get the request memory and perform read operation here
//
status = WdfRequestRetrieveInputBuffer(Request, 0, &input_buffer,
&input_buffer_length);
if( NT_SUCCESS(status) )
{
file_object_context->function_code =
(input_buffer->function_code);
bytesWritten = Length;
}
else
{
WdfRequestComplete(Request, status);
return;
}

WdfRequestCompleteWithInformation(Request, status, bytesWritten); }

VOID
BasicEvtDeviceControl(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
/*++
Routine Description:

This event is called when the framework receives IRP_MJ_DEVICE_CONTROL
requests from the system.

Arguments:

Queue - Handle to the framework queue object that is associated
with the I/O request.
Request - Handle to a framework request object.

OutputBufferLength - length of the request’s output buffer,
if an output buffer is available.
InputBufferLength - length of the request’s input buffer,
if an input buffer is available.

IoControlCode - the driver-defined or system-defined I/O control code
(IOCTL) that is associated with the request.

Return Value:

VOID

–*/
{
NTSTATUS status= STATUS_SUCCESS;

UNREFERENCED_PARAMETER(Queue);
UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);

//
// Use WdfRequestRetrieveInputBuffer and WdfRequestRetrieveOutputBuffer
// to get the request buffers.
//

switch (IoControlCode) {

default:
status = STATUS_INVALID_DEVICE_REQUEST;
}

//
// Complete the Request.
//
WdfRequestCompleteWithInformation(Request, status, (ULONG_PTR) 0); }
/////////////////////

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints the
driver/function that caused the problem. Always note this address as well
as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded
breakpoint or assertion was hit, but this system was booted /NODEBUG. This
is not supposed to happen as developers should never have hardcoded
breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the system is
booted /DEBUG. This will let us see why this breakpoint is happening.
Arguments:
Arg1: c0000420, The exception code that was not handled
Arg2: bc385595, The address that the exception occurred at
Arg3: b6293afc, Trap Frame
Arg4: 00000000

Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for
basic.sys

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

FAULTING_IP:
basic+1595
bc385595 cd2c int 2Ch

TRAP_FRAME: b6293afc – (.trap 0xffffffffb6293afc) ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000002 edx=00000065 esi=8537c28c
edi=8537c1b0
eip=bc385595 esp=b6293b70 ebp=b6293b70 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000286
basic+0x1595:
bc385595 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: DriverTest.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 82ad004c to 82af9eb4

STACK_TEXT:
b6293664 82ad004c 0000008e c0000420 bc385595 nt!KeBugCheckEx+0x1e b6293a8c
82a59de6 b6293aa8 00000000 b6293afc nt!KiDispatchException+0x1ac
b6293af4 82a59d82 b6293b70 bc385597 badb0d00 nt!CommonDispatchException+0x4a
b6293b14 82a80654 76c89001 000001cb 000001c0 nt!Kei386EoiHelper+0x17a
b6293b70 bc3854c0 855fcaa8 855fcaa0 00000000 nt!MiUpdateWsle+0x231
WARNING: Stack unwind information not available. Following frames may be
wrong.
b6293b94 8af1802a 7ac83e48 77105580 00000004 basic+0x14c0
b6293bb0 8af19256 7ac83e48 77105580 00000004
Wdf01000!FxIoQueueIoRead::Invoke+0x2a
b6293bd8 8af1b9ac 77105580 88efaa78 8537c1b0
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x1a3
b6293bf4 8af1ca36 8537c100 00000000 88f544f8
Wdf01000!FxIoQueue::DispatchEvents+0x3be
b6293c14 8af1e824 88efaa78 8849ab60 8789b030
Wdf01000!FxIoQueue::QueueRequest+0x1ec
b6293c38 8af0da3f 878bd2a0 b6293c5c 82a5258e
Wdf01000!FxPkgIo::Dispatch+0x27d
b6293c44 82a5258e 8789b030 878bd2a0 878bd2a0
Wdf01000!FxDevice::Dispatch+0x7f b6293c5c 82c45a31 878bd2a0 878bd334
8849ab60 nt!IofCallDriver+0x63 b6293c7c 82c7e380 8789b030 8849ab60 00000001
nt!IopSynchronousServiceTail+0x1f8
b6293d08 82a591fa 8789b030 878bd2a0 00000000 nt!NtReadFile+0x644
b6293d08 771870b4 8789b030 878bd2a0 00000000 nt!KiFastCallEntry+0x12a
0030f8e4 00000000 00000000 00000000 00000000 0x771870b4

STACK_COMMAND: kb

FOLLOWUP_IP:
basic+1595
bc385595 cd2c int 2Ch

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: basic+1595

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: basic

IMAGE_NAME: basic.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4e4da09e

FAILURE_BUCKET_ID: 0x8E_basic+1595

BUCKET_ID: 0x8E_basic+1595


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

I don’t have PAGED_CODE anywhere in my code right now. Also, when I reload the symbols, I get an error:

1: kd> .symfix C:\WinDDK\7600.16385.1\src\KMDFTest\objchk_wxp_x86\i386
1: kd> .reload
Loading Kernel Symbols



Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdd00c). Type “.hh dbgerr001” for details
Loading unloaded module list

.reload -f -n
On Aug 23, 2011 2:32 PM, wrote:
> I don’t have PAGED_CODE anywhere in my code right now. Also, when I reload
the symbols, I get an error:
>
>
> 1: kd> .symfix C:\WinDDK\7600.16385.1\src\KMDFTest\objchk_wxp_x86\i386
> 1: kd> .reload
> Loading Kernel Symbols
> …
> …
> …
> Loading User Symbols
> PEB is paged out (Peb.Ldr = 7ffdd00c). Type “.hh dbgerr001” for details
> Loading unloaded module list
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

For some reason my symbols won’t load. Says unable to load symbols for basic.sys. My .pdb file is located in the same directory as my sys file.

Try setting the path only to your source directory, not the path of your
pdb.

Also, before issuing .reload, issue this: .symopt+ 0x80000000

Mm
On Aug 23, 2011 2:39 PM, wrote:
> For some reason my symbols won’t load. Says unable to load symbols for
basic.sys. My .pdb file is located in the same directory as my sys file.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

You are probably running an older version of your sys file on the machine under test. !lmi basic.sys should give you the timestamp see if it matches the pdb. Once you get it to match, re run !analyze -v. in the end, the is a call to int2c. 99.99% of the time that is due to an indirect call to NT_ASSERT by your code by calling PAGED_CODE or IS_PAGED_CODE or something of the like.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, August 23, 2011 11:38 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Basic Driver Assertion Failure

For some reason my symbols won’t load. Says unable to load symbols for basic.sys. My .pdb file is located in the same directory as my sys file.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

It’s frustrating. My sys and pdb file have the same timestamp. Nothing new. my symbols are set up correctly, and still I get an error in loading the symbols. I don’t have PAGED_CODE any where in my code. Just confused as to why the driver works flawlessly under WinXP and blue screens under Win7

Try loading your driver as a dump file (windbg -z filename.sys) and then see if you can resolve symbols with your PDB. Removes the pain of reloading for real on an OS. The bluescreen on win7 is not a bluescreen, it is an NT_ASSERT that broke into the debugger. As to why it is firing on win7 and not XP, it could easily be any number of things. Did you enable driver verifier and IRQL verification on both XP and 7?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, August 23, 2011 1:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Basic Driver Assertion Failure

It’s frustrating. My sys and pdb file have the same timestamp. Nothing new. my symbols are set up correctly, and still I get an error in loading the symbols. I don’t have PAGED_CODE any where in my code. Just confused as to why the driver works flawlessly under WinXP and blue screens under Win7


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

My XP environment is just running under debug mode on another system. I just ran the driver on Win7 under my development computer just to randomly test it and it blue screened. I’ll try your suggestion

Here is what I get after I fixed the symbols–>

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

FAULTING_IP:
basic!WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE+15 [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfio.h @ 419]
928f2595 cd2c int 2Ch

TRAP_FRAME: bb8ffafc – (.trap 0xffffffffbb8ffafc)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000002 edx=00000065 esi=87571a9c edi=875719c0
eip=928f2595 esp=bb8ffb70 ebp=bb8ffb70 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286
basic!WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE+0x15:
928f2595 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: DriverTest.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 82abe04c to 82ae7eb4

STACK_TEXT:
bb8ff664 82abe04c 0000008e c0000420 928f2595 nt!KeBugCheckEx+0x1e
bb8ffa8c 82a47de6 bb8ffaa8 00000000 bb8ffafc nt!KiDispatchException+0x1ac
bb8ffaf4 82a47d82 bb8ffb70 928f2597 badb0d00 nt!CommonDispatchException+0x4a
bb8ffb14 82a6e654 777f9001 000001c9 000001be nt!Kei386EoiHelper+0x17a
bb8ffb70 928f24c0 8740b988 8740b980 00000000 nt!MiUpdateWsle+0x231
bb8ffb94 8aeff02a 78a8e638 77907b48 00000004 basic!WdfDeviceInitSetFileObjectConfig [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfdevice.h @ 2765]
bb8ffbb0 8af00256 78a8e638 77907b48 00000004 Wdf01000!FxIoQueueIoRead::Invoke+0x2a
bb8ffbd8 8af029ac 77907b48 886f84b0 875719c0 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x1a3
bb8ffbf4 8af03a36 87571900 00000000 87413be8 Wdf01000!FxIoQueue::DispatchEvents+0x3be
bb8ffc14 8af05824 886f84b0 85316cb0 8740b648 Wdf01000!FxIoQueue::QueueRequest+0x1ec
bb8ffc38 8aef4a3f 8883f008 bb8ffc5c 82a4058e Wdf01000!FxPkgIo::Dispatch+0x27d
bb8ffc44 82a4058e 8740b648 8883f008 8883f008 Wdf01000!FxDevice::Dispatch+0x7f
bb8ffc5c 82c33a31 8883f008 8883f09c 85316cb0 nt!IofCallDriver+0x63
bb8ffc7c 82c6c380 8740b648 85316cb0 00000001 nt!IopSynchronousServiceTail+0x1f8
bb8ffd08 82a471fa 8740b648 8883f008 00000000 nt!NtReadFile+0x644
bb8ffd08 779870b4 8740b648 8883f008 00000000 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
001cf86c 00000000 00000000 00000000 00000000 0x779870b4

STACK_COMMAND: kb

FOLLOWUP_IP:
basic!WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE+15 [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfio.h @ 419]
928f2595 cd2c int 2Ch

FAULTING_SOURCE_CODE:
415: )
416: {
417: RtlZeroMemory(Config, sizeof(WDF_IO_QUEUE_CONFIG));
418:

419: Config->Size = sizeof(WDF_IO_QUEUE_CONFIG);
420: Config->PowerManaged = WdfUseDefault;
421: Config->DefaultQueue = TRUE;
422: Config->DispatchType = DispatchType;
423: if (Config->DispatchType == WdfIoQueueDispatchParallel) {
424: Config->Settings.Parallel.NumberOfPresentedRequests = (ULONG)-1;

xxxxx@gmail.com wrote:

Here is what I get after I fixed the symbols–>

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

If it is a KMDF assertion, it will be in the in-flight recorder log:

!load wdfkd
!wdftmffile \winddk\7600.16385.1\tools\tracing\i386\wdf01009.tmf
!wdflogdump basic

However, this looks suspicious. You’re supposedly handling a ReadFile
request, but you’re in WdfDeviceInitSetFileObjectConfig , which would
only be run at AddDevice time. Do you possible have your callbacks
crossed in some way, so that your EvtIoRead handler is actually calling
the wrong function?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Something is weird here. The faulting IP is wdfio.h @ 419 in WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE. Since this is an line function, you can see what it does

VOID
FORCEINLINE
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(
__out PWDF_IO_QUEUE_CONFIG Config,
__in WDF_IO_QUEUE_DISPATCH_TYPE DispatchType
)
{
RtlZeroMemory(Config, sizeof(WDF_IO_QUEUE_CONFIG));

Config->Size = sizeof(WDF_IO_QUEUE_CONFIG); <– line 409, no ASSERT here!
Config->PowerManaged = WdfUseDefault;
Config->DefaultQueue = TRUE;
Config->DispatchType = DispatchType;
if (Config->DispatchType == WdfIoQueueDispatchParallel) {
Config->Settings.Parallel.NumberOfPresentedRequests = (ULONG)-1;
}
}

And see there is no ASSERT, yet the faulting callstack has basic!WdfDeviceInitSetFileObjectConfig in it. The faulting IP usually matches the call in your driver. As tim said, this is the wrong api call to be making in a read callback.

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, August 23, 2011 5:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Basic Driver Assertion Failure

Here is what I get after I fixed the symbols–>

EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

FAULTING_IP:
basic!WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE+15 [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfio.h @ 419]
928f2595 cd2c int 2Ch

TRAP_FRAME: bb8ffafc – (.trap 0xffffffffbb8ffafc) ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000002 edx=00000065 esi=87571a9c edi=875719c0
eip=928f2595 esp=bb8ffb70 ebp=bb8ffb70 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286
basic!WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE+0x15:
928f2595 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: DriverTest.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 82abe04c to 82ae7eb4

STACK_TEXT:
bb8ff664 82abe04c 0000008e c0000420 928f2595 nt!KeBugCheckEx+0x1e bb8ffa8c 82a47de6 bb8ffaa8 00000000 bb8ffafc nt!KiDispatchException+0x1ac
bb8ffaf4 82a47d82 bb8ffb70 928f2597 badb0d00 nt!CommonDispatchException+0x4a
bb8ffb14 82a6e654 777f9001 000001c9 000001be nt!Kei386EoiHelper+0x17a
bb8ffb70 928f24c0 8740b988 8740b980 00000000 nt!MiUpdateWsle+0x231
bb8ffb94 8aeff02a 78a8e638 77907b48 00000004 basic!WdfDeviceInitSetFileObjectConfig [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfdevice.h @ 2765]
bb8ffbb0 8af00256 78a8e638 77907b48 00000004 Wdf01000!FxIoQueueIoRead::Invoke+0x2a
bb8ffbd8 8af029ac 77907b48 886f84b0 875719c0 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x1a3
bb8ffbf4 8af03a36 87571900 00000000 87413be8 Wdf01000!FxIoQueue::DispatchEvents+0x3be
bb8ffc14 8af05824 886f84b0 85316cb0 8740b648 Wdf01000!FxIoQueue::QueueRequest+0x1ec
bb8ffc38 8aef4a3f 8883f008 bb8ffc5c 82a4058e Wdf01000!FxPkgIo::Dispatch+0x27d
bb8ffc44 82a4058e 8740b648 8883f008 8883f008 Wdf01000!FxDevice::Dispatch+0x7f bb8ffc5c 82c33a31 8883f008 8883f09c 85316cb0 nt!IofCallDriver+0x63 bb8ffc7c 82c6c380 8740b648 85316cb0 00000001 nt!IopSynchronousServiceTail+0x1f8
bb8ffd08 82a471fa 8740b648 8883f008 00000000 nt!NtReadFile+0x644
bb8ffd08 779870b4 8740b648 8883f008 00000000 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
001cf86c 00000000 00000000 00000000 00000000 0x779870b4

STACK_COMMAND: kb

FOLLOWUP_IP:
basic!WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE+15 [c:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfio.h @ 419]
928f2595 cd2c int 2Ch

FAULTING_SOURCE_CODE:
415: )
416: {
417: RtlZeroMemory(Config, sizeof(WDF_IO_QUEUE_CONFIG));
418:

419: Config->Size = sizeof(WDF_IO_QUEUE_CONFIG);
420: Config->PowerManaged = WdfUseDefault;
421: Config->DefaultQueue = TRUE;
422: Config->DispatchType = DispatchType;
423: if (Config->DispatchType == WdfIoQueueDispatchParallel) {
424: Config->Settings.Parallel.NumberOfPresentedRequests = (ULONG)-1;


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

This is weird. I don’t know what’s wrong. I set up my queue in the following function…very basic:

NTSTATUS EvtDeviceAdd(
IN WDFDRIVER Driver,
IN PWDFDEVICE_INIT DeviceInit
)
{
NTSTATUS status;
WDFDEVICE device;
PDEVICE_CONTEXT devCtx = NULL;
WDF_OBJECT_ATTRIBUTES devAttributes;
WDF_PNPPOWER_EVENT_CALLBACKS pnpPowerCallbacks;
WDF_IO_QUEUE_CONFIG ioQConfig;
WDF_FILEOBJECT_CONFIG fileObjectConfig;
WDF_OBJECT_ATTRIBUTES fileObjAttributes;

DECLARE_CONST_UNICODE_STRING(dosDeviceName, L"\DosDevices\RobertDriver") ;
DECLARE_CONST_UNICODE_STRING(ntDeviceName, L"\Device\RobertDriver") ;

UNREFERENCED_PARAMETER(Driver);

KdPrint((__DRIVER_NAME “–> EvtDeviceAdd\n”));

/*set the callback functions that will be executed on PNP and Power events*/
WDF_PNPPOWER_EVENT_CALLBACKS_INIT(&pnpPowerCallbacks);
pnpPowerCallbacks.EvtDevicePrepareHardware = EvtDevicePrepareHardware;
//pnpPowerCallbacks.EvtDeviceD0Entry = EvtDeviceD0Entry;
//pnpPowerCallbacks.EvtDeviceD0Exit = EvtDeviceD0Exit;
WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit, &pnpPowerCallbacks);
// Set IO Type: Buffered, Direct I/O, Neither I/O
WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoBuffered);

//
// Setup the file object stuff
//
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(
&fileObjAttributes,
BASIC_FILEOBJECT_CONTEXT
);

fileObjAttributes.SynchronizationScope = WdfSynchronizationScopeNone;

WDF_FILEOBJECT_CONFIG_INIT(
&fileObjectConfig,
BasicEvtDeviceFileCreate, // New handle opened
WDF_NO_EVENT_CALLBACK, // Close when last ref released
BasicEvtFileCleanup // Cleanup when handle closed
);

WdfDeviceInitSetFileObjectConfig(
DeviceInit,
&fileObjectConfig,
&fileObjAttributes
);

//
// We want our device object NAMED, thank you very much
//
status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);

if (!NT_SUCCESS(status))
{
return(status);
}

/*initialize storage for the device context*/
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&devAttributes, DEVICE_CONTEXT);
devAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;

/*create a device instance.*/
status = WdfDeviceCreate(&DeviceInit, &devAttributes, &device);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfDeviceCreate failed with status 0x%08x\n”, status));
return status;
}
// Set up device context
devCtx = BasicGetDeviceContext(device);
devCtx->WdfDevice = device;

/*create the default IO queue. this one will be used for ioctl requests*/
WDF_IO_QUEUE_CONFIG_INIT(&ioQConfig,WdfIoQueueDispatchSequential);
ioQConfig.EvtIoRead = BasicEvtRead;
ioQConfig.EvtIoWrite = BasicEvtWrite;
ioQConfig.EvtIoDeviceControl = BasicEvtDeviceControl;

status = WdfIoQueueCreate(device,
&ioQConfig,
WDF_NO_OBJECT_ATTRIBUTES,
NULL);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfIoQueueCreate failed with status 0x%08x\n”, status));
return status;
}

status = WdfDeviceCreateDeviceInterface(device, &GUID_DEV_IF_BASIC, NULL);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfDeviceCreateDeviceInterface failed with status 0x%08x\n”, status));
return status;
}

KdPrint((__DRIVER_NAME “<– EvtDeviceAdd\n”));

// Create a symbolic link for control object so that usermode can open
// the device.
//
status = WdfDeviceCreateSymbolicLink(device, &dosDeviceName);
return status;
}

xxxxx@gmail.com wrote:

This is weird. I don’t know what’s wrong. I set up my queue in the following function…very basic:

That code looks fundamentally correct. You’re going to have to insert
some KdPrint traces and watch the flow in the debugger to see how you
got to that bad place.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

The code looks correct, but the stack traces you are providing are somehow incorrect. Are you live debugging or capturing a dump file and debugging post mortem?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, August 24, 2011 9:56 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Basic Driver Assertion Failure

xxxxx@gmail.com wrote:

This is weird. I don’t know what’s wrong. I set up my queue in the following function…very basic:

That code looks fundamentally correct. You’re going to have to insert some KdPrint traces and watch the flow in the debugger to see how you got to that bad place.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

I’m just capturing the dump file right now. Guess I’ll have to live debug

I didn’t want to live debug because I was mainly testing on my XP machine and assumed everything was working since it worked on it.