Creating an extra device object

NTDEV
1

Hi guys,

I’ve been trying to create an extra device object in my filter driver on the tape class, in order to recieve certain IOCTL’s from a win app, purely as a measure in case the tape device is already claimed, and therefore cannot have a handle opened. I’ve got to the point where I have the extra device created, but I can’t open the handle.

I’ve found that if I create the device in the DriverEntry routine, I am able to create a symbolic link (for debug purposes I’ve just called it ‘\Device\BensExtra’, which links to ‘\DosDevices\BensExtra’) and successfully open a handle in my windows app, using the CreateFile method. However, when I then try to send an IOCTL to the device, I get a BSOD with an IRQL_NOT_LESS_OR_EQUAL error, presumably due to bad code in my DeviceControl routine.

If I create the extra device in the AddDevice routine, I am not able to open the handle from my win app, and I have checked that both the device and the symbolic link are correctly being created.

Can anyone explain why there is a difference between creating the extra device in the DriverEntry and AddDevice routines (using exactly the same code!), and how to get round the problem? Once I’ve got that sorted I can try tackling the BSOD issue…

Many thanks,

Ben

2

Did you clear the Device Initializing bit in the device object that you
created? If not, you won’t be able to open it. The Device
Initializing bit is cleared by default in Driver Entry…

–Mark Cariddi
OSR, Open Systems Resources…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
ben.simpson@hp.com
Sent: Thursday, September 17, 2009 11:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Creating an extra device object

Hi guys,

I’ve been trying to create an extra device object in my filter driver on
the tape class, in order to recieve certain IOCTL’s from a win app,
purely as a measure in case the tape device is already claimed, and
therefore cannot have a handle opened. I’ve got to the point where I
have the extra device created, but I can’t open the handle.

I’ve found that if I create the device in the DriverEntry routine, I am
able to create a symbolic link (for debug purposes I’ve just called it
‘\Device\BensExtra’, which links to ‘\DosDevices\BensExtra’) and
successfully open a handle in my windows app, using the CreateFile
method. However, when I then try to send an IOCTL to the device, I get a
BSOD with an IRQL_NOT_LESS_OR_EQUAL error, presumably due to bad code in
my DeviceControl routine.

If I create the extra device in the AddDevice routine, I am not able to
open the handle from my win app, and I have checked that both the device
and the symbolic link are correctly being created.

Can anyone explain why there is a difference between creating the extra
device in the DriverEntry and AddDevice routines (using exactly the same
code!), and how to get round the problem? Once I’ve got that sorted I
can try tackling the BSOD issue…

Many thanks,

Ben

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

3

No, I hadn’t cleared it :slight_smile:

Now that’s sorted, I can open the handle to the device. Now I need to solve the BSOD issue. I’ve got a flag in my DEVICE_EXTENSION structure that differentiates between fido’s and edo’s, so I’ve got a switch in my DeviceControl routine that calls different code accordingly. The basic code structure in this routine is:

if (deviceExtension->flag==FIDO_EXTENSION)
{
…

} else {

//EDO extension…

switch (currentIrpStack->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_MYIOCTL:
KdPrint((“%s: Recieved IOCTL”,FUNCTION));
break;
}

Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return (STATUS_SUCCESS);
}

I’m not convinced the error lies here though, I think it’s before this point that I get the BSOD, possibly in my Create routine. But all I have in there is:

Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return status;

Should I be doing something else for the extra device object?

Ben

4

What is the crash that your getting?

–Mark Cariddi
OSR, Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
ben.simpson@hp.com
Sent: Thursday, September 17, 2009 12:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Creating an extra device object

No, I hadn’t cleared it :slight_smile:

Now that’s sorted, I can open the handle to the device. Now I need to
solve the BSOD issue. I’ve got a flag in my DEVICE_EXTENSION structure
that differentiates between fido’s and edo’s, so I’ve got a switch in my
DeviceControl routine that calls different code accordingly. The basic
code structure in this routine is:

if (deviceExtension->flag==FIDO_EXTENSION)
{
…

} else {

//EDO extension…

switch (currentIrpStack->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_MYIOCTL:
KdPrint((“%s: Recieved IOCTL”,FUNCTION));
break;
}

Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return (STATUS_SUCCESS);
}

I’m not convinced the error lies here though, I think it’s before this
point that I get the BSOD, possibly in my Create routine. But all I have
in there is:

Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return status;

Should I be doing something else for the extra device object?

Ben

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

5

Once you have a BSOD and you need help, please attach WinDbg to your machine
and give us the ‘!analyze -v’ output. This has been reiterated many many
times in this forum.

On Thu, Sep 17, 2009 at 2:24 PM, Mark Cariddi wrote:

> What is the crash that your getting?
>
> --Mark Cariddi
> OSR, Open Systems Resources, Inc.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> ben.simpson@hp.com
> Sent: Thursday, September 17, 2009 12:30 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Creating an extra device object
>
> No, I hadn’t cleared it :slight_smile:
>
> Now that’s sorted, I can open the handle to the device. Now I need to
> solve the BSOD issue. I’ve got a flag in my DEVICE_EXTENSION structure
> that differentiates between fido’s and edo’s, so I’ve got a switch in my
> DeviceControl routine that calls different code accordingly. The basic
> code structure in this routine is:
>
> if (deviceExtension->flag==FIDO_EXTENSION)
> {
> …
>
> } else {
>
> //EDO extension…
>
> switch (currentIrpStack->Parameters.DeviceIoControl.IoControlCode)
> {
> case IOCTL_MYIOCTL:
> KdPrint((“%s: Recieved IOCTL”, FUNCTION ));
> break;
> }
>
> Irp->IoStatus.Status = STATUS_SUCCESS;
> IoCompleteRequest(Irp, IO_NO_INCREMENT);
> return (STATUS_SUCCESS);
> }
>
> I’m not convinced the error lies here though, I think it’s before this
> point that I get the BSOD, possibly in my Create routine. But all I have
> in there is:
>
> Irp->IoStatus.Status = STATUS_SUCCESS;
> IoCompleteRequest(Irp, IO_NO_INCREMENT);
> return status;
>
> Should I be doing something else for the extra device object?
>
> Ben
>
> —
> 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
>

6

Apologies. Here’s the windbg output:

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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: c0000005, The exception code that was not handled
Arg2: f7a0e4d3, The address that the exception occurred at
Arg3: f71aebd4, Trap Frame
Arg4: 00000000

…

ADDITIONAL_DEBUG_TEXT:
Use ‘!findthebuild’ command to search for the target build information.
If the build information is available, run ‘!findthebuild -s ; .reload’ to set symbol path and load symbols.

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4ab35f0a

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
hpfilter!MemDrvCleanup+83 [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]

TRAP_FRAME: f71aebd4 – (.trap 0xfffffffff71aebd4)
ErrCode = 00000000
eax=00000190 ebx=866b68e8 ecx=866b6948 edx=00000190 esi=867336d8 edi=86376028
eip=f7a0e4d3 esp=f71aec48 ebp=f71aec60 iopl=0 nv up ei pl nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010217
hpfilter!MemDrvCleanup+0x83:
f7a0e4d3 8b5008 mov edx,dword ptr [eax+8] ds:0023:00000198=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 804ee129 to f7a0e4d3

STACK_TEXT:
f71aec60 804ee129 85ad42f0 866b68d8 866b68d8 hpfilter!MemDrvCleanup+0x83 [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
WARNING: Stack unwind information not available. Following frames may be wrong.
f71aeca4 805b21e0 866ef8e0 85ad42f0 0012019f nt+0x17129
f71aecd4 805b1b0d 866ef8e0 00000001 867e9040 nt+0xdb1e0
f71aecfc 805b1bab e13f2138 86376028 00000090 nt+0xdab0d
f71aed44 805b1ce3 00000090 00000001 00000000 nt+0xdabab
f71aed58 8053d648 00000090 0012f710 7c90e514 nt+0xdace3
f71aed64 7c90e514 badb0d00 0012f70c ee208d98 nt+0x66648
f71aed68 badb0d00 0012f70c ee208d98 ee208dcc 0x7c90e514
f71aed6c 0012f70c ee208d98 ee208dcc 00000000 0xbadb0d00
f71aed70 ee208d98 ee208dcc 00000000 00000000 0x12f70c
f71aed74 ee208dcc 00000000 00000000 00000000 0xee208d98
f71aed78 00000000 00000000 00000000 00000000 0xee208dcc

STACK_COMMAND: kb

FOLLOWUP_IP:
hpfilter!MemDrvCleanup+83 [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: hpfilter!MemDrvCleanup+83

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hpfilter

IMAGE_NAME: hpfilter.sys

Note, the BSOD still shows IRQL_NOT_LESS_OR_EQUAL.

Ben

7

CAUSE:
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

COULD BE REASON:
KdPrint((“%s: Recieved IOCTL”,FUNCTION));

On Fri, Sep 18, 2009 at 4:22 PM, <ben.simpson> wrote:

> Apologies. Here’s the windbg output:
>
> kd> !analyze -v
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
> 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: c0000005, The exception code that was not handled
> Arg2: f7a0e4d3, The address that the exception occurred at
> Arg3: f71aebd4, Trap Frame
> Arg4: 00000000
>
> …
>
> ADDITIONAL_DEBUG_TEXT:
> Use ‘!findthebuild’ command to search for the target build information.
> If the build information is available, run ‘!findthebuild -s ; .reload’ to
> set symbol path and load symbols.
>
> FAULTING_MODULE: 804d7000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4ab35f0a
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.
>
> FAULTING_IP:
> hpfilter!MemDrvCleanup+83
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
> f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]
>
> TRAP_FRAME: f71aebd4 – (.trap 0xfffffffff71aebd4)
> ErrCode = 00000000
> eax=00000190 ebx=866b68e8 ecx=866b6948 edx=00000190 esi=867336d8
> edi=86376028
> eip=f7a0e4d3 esp=f71aec48 ebp=f71aec60 iopl=0 nv up ei pl nz ac pe
> cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010217
> hpfilter!MemDrvCleanup+0x83:
> f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]
> ds:0023:00000198=???
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 5
>
> DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 804ee129 to f7a0e4d3
>
> STACK_TEXT:
> f71aec60 804ee129 85ad42f0 866b68d8 866b68d8 hpfilter!MemDrvCleanup+0x83
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f71aeca4 805b21e0 866ef8e0 85ad42f0 0012019f nt+0x17129
> f71aecd4 805b1b0d 866ef8e0 00000001 867e9040 nt+0xdb1e0
> f71aecfc 805b1bab e13f2138 86376028 00000090 nt+0xdab0d
> f71aed44 805b1ce3 00000090 00000001 00000000 nt+0xdabab
> f71aed58 8053d648 00000090 0012f710 7c90e514 nt+0xdace3
> f71aed64 7c90e514 badb0d00 0012f70c ee208d98 nt+0x66648
> f71aed68 badb0d00 0012f70c ee208d98 ee208dcc 0x7c90e514
> f71aed6c 0012f70c ee208d98 ee208dcc 00000000 0xbadb0d00
> f71aed70 ee208d98 ee208dcc 00000000 00000000 0x12f70c
> f71aed74 ee208dcc 00000000 00000000 00000000 0xee208d98
> f71aed78 00000000 00000000 00000000 00000000 0xee208dcc
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> hpfilter!MemDrvCleanup+83
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
> f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: hpfilter!MemDrvCleanup+83
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: hpfilter
>
> IMAGE_NAME: hpfilter.sys
>
> Note, the BSOD still shows IRQL_NOT_LESS_OR_EQUAL.
>
> Ben
>
> —
> 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
></ben.simpson>

8

Fix your symbol please so that we can know what you are doing.

On Fri, Sep 18, 2009 at 6:52 AM, <ben.simpson> wrote:

> Apologies. Here’s the windbg output:
>
> kd> !analyze -v
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
> 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: c0000005, The exception code that was not handled
> Arg2: f7a0e4d3, The address that the exception occurred at
> Arg3: f71aebd4, Trap Frame
> Arg4: 00000000
>
> …
>
> ADDITIONAL_DEBUG_TEXT:
> Use ‘!findthebuild’ command to search for the target build information.
> If the build information is available, run ‘!findthebuild -s ; .reload’ to
> set symbol path and load symbols.
>
> FAULTING_MODULE: 804d7000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4ab35f0a
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.
>
> FAULTING_IP:
> hpfilter!MemDrvCleanup+83
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
> f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]
>
> TRAP_FRAME: f71aebd4 – (.trap 0xfffffffff71aebd4)
> ErrCode = 00000000
> eax=00000190 ebx=866b68e8 ecx=866b6948 edx=00000190 esi=867336d8
> edi=86376028
> eip=f7a0e4d3 esp=f71aec48 ebp=f71aec60 iopl=0 nv up ei pl nz ac pe
> cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010217
> hpfilter!MemDrvCleanup+0x83:
> f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]
> ds:0023:00000198=???
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 5
>
> DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 804ee129 to f7a0e4d3
>
> STACK_TEXT:
> f71aec60 804ee129 85ad42f0 866b68d8 866b68d8 hpfilter!MemDrvCleanup+0x83
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f71aeca4 805b21e0 866ef8e0 85ad42f0 0012019f nt+0x17129
> f71aecd4 805b1b0d 866ef8e0 00000001 867e9040 nt+0xdb1e0
> f71aecfc 805b1bab e13f2138 86376028 00000090 nt+0xdab0d
> f71aed44 805b1ce3 00000090 00000001 00000000 nt+0xdabab
> f71aed58 8053d648 00000090 0012f710 7c90e514 nt+0xdace3
> f71aed64 7c90e514 badb0d00 0012f70c ee208d98 nt+0x66648
> f71aed68 badb0d00 0012f70c ee208d98 ee208dcc 0x7c90e514
> f71aed6c 0012f70c ee208d98 ee208dcc 00000000 0xbadb0d00
> f71aed70 ee208d98 ee208dcc 00000000 00000000 0x12f70c
> f71aed74 ee208dcc 00000000 00000000 00000000 0xee208d98
> f71aed78 00000000 00000000 00000000 00000000 0xee208dcc
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> hpfilter!MemDrvCleanup+83
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1349]
> f7a0e4d3 8b5008 mov edx,dword ptr [eax+8]
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: hpfilter!MemDrvCleanup+83
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: hpfilter
>
> IMAGE_NAME: hpfilter.sys
>
> Note, the BSOD still shows IRQL_NOT_LESS_OR_EQUAL.
>
> Ben
>
> —
> 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
></ben.simpson>

9

Hmmmm… what is it that your driver does in its Cleanup routine (assuming this is the handler for IRP_MJ_CLEANUP, which is an IRP you almost never need to handle in the first place)??

AND fix your symbols, please. Gosh, I get tired of asking people to do that… how can you debug your code if your symbols aren’t set up?? Seriously: .symfix and you’re done, you know?

Peter
OSR

10

Ok, sorry for the lack of symbols. This is the first time I’ve used windbg, still finding my way about.

I’ve commented out the KdPrints, but why they would be causing the errors confuses me. Is translating ‘FUNCTION’ to a %s an issue in certain circumstances?

Peter, you’re right that my MemDrvCleanup routine is a handler for IRP_MJ_CLEANUP. This routine is used to cleanup stuff after my driver and win app have stopped sharing a block of memory that I’m using to transport data from the driver to the app. Why this is getting called for my extra device object I don’t know, I’ve not got as far as communicating memory addresses or anything to the edo (yet).

Here’s my latest windbg data:

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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: c0000005, The exception code that was not handled
Arg2: f7a124c1, The address that the exception occurred at
Arg3: edee6bd4, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
hpfilter!MemDrvCleanup+71 [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1348]
f7a124c1 8b5008 mov edx,dword ptr [eax+8]

TRAP_FRAME: edee6bd4 – (.trap 0xffffffffedee6bd4)
ErrCode = 00000000
eax=48000000 ebx=858eeac8 ecx=858eeb28 edx=48000000 esi=8654dc78 edi=8586d8a8
eip=f7a124c1 esp=edee6c48 ebp=edee6c60 iopl=0 ov up ei ng nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010a97
hpfilter!MemDrvCleanup+0x71:
f7a124c1 8b5008 mov edx,dword ptr [eax+8] ds:0023:48000008=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 7

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: iSpy.exe

LOCK_ADDRESS: 805591e0 – (!locks 805591e0)

Resource @ nt!PiEngineLock (0x805591e0) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x805591e0
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from 804ee129 to f7a124c1

STACK_TEXT:
edee6c60 804ee129 855e0030 858eeab8 858eeab8 hpfilter!MemDrvCleanup+0x71 [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1348]
edee6ca4 805b21e0 857c9568 855e0030 0012019f nt!CcLazyWriteScan+0x398
edee6cd4 805b1b0d 857c9568 00000001 867e9e70 nt!pIoQueryBusDescription+0xda
edee6cfc 805b1bab e502fbb8 8586d8a8 00000094 nt!CmTypeString+0x7d
edee6d44 805b1ce3 00000094 00000001 00000000 nt!string'+0x13 edee6d58 8053d648 00000094 0012f710 7c90e514 nt!string’+0xb
edee6d64 7c90e514 badb0d00 0012f70c edba2d98 nt!PopRunDownSourceTargetList+0x10e
WARNING: Frame IP not in any known module. Following frames may be wrong.
edee6d68 badb0d00 0012f70c edba2d98 edba2dcc 0x7c90e514
edee6d6c 0012f70c edba2d98 edba2dcc 00000000 0xbadb0d00
edee6d70 edba2d98 edba2dcc 00000000 00000000 0x12f70c
edee6d74 edba2dcc 00000000 00000000 00000000 0xedba2d98
edee6d78 00000000 00000000 00000000 00000000 0xedba2dcc

STACK_COMMAND: kb

FOLLOWUP_IP:
hpfilter!MemDrvCleanup+71 [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1348]
f7a124c1 8b5008 mov edx,dword ptr [eax+8]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: hpfilter!MemDrvCleanup+71

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hpfilter

IMAGE_NAME: hpfilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ab38162

FAILURE_BUCKET_ID: 0x8E_hpfilter!MemDrvCleanup+71

BUCKET_ID: 0x8E_hpfilter!MemDrvCleanup+71

Thanks,

Ben

11

Edit: By commenting out all the KdPrints, the driver has stopped causing a BSOD. However, when my app calls CreateFile, it just hangs… presumably waiting for the driver or edo to respond?

Ben

12

ben.simpson@hp.com wrote:

Ok, sorry for the lack of symbols. This is the first time I’ve used windbg, still finding my way about.

I’ve commented out the KdPrints, but why they would be causing the errors confuses me. Is translating ‘FUNCTION’ to a %s an issue in certain circumstances?

No, I think that was just a stab in the dark.

However, here’s a hint for the future. FUNCTION, even though it
doesn’t look like one, is a string constant. You do not need to use
%s. You can say:

KdPrint(( FUNCTION “: processing ioctl.” );

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

13

OK, that’s good news: It’s correct and appropriate to have a Cleanup handler to do exactly this. Good call.

Ah! Well! THAT I *might* be able to answer: Remember that IRP_MJ_CLEANUP is the IRP that gets sent whenever a handle is closed. So the user does CloseHandle(xxxx) and the IRP you get is _CLEANUP.

Of course, most people think you get a _CLOSE… but in fact, you only get a close when the reference count on the associated FILE_OBJECT goes to zero. For a device driver that would almost always be immediately after the cleanup is complete.

Does that help any… even a little?

Peter
OSR

14

Tim - Thanks for the tip, I’ll keep it in mind :slight_smile:

Peter - Yes, that does help alot! It appears then that my app is hanging when it calls CloseHandle, I guess either my cleanup routine is not doing what it should, or something else is causing the hang.

Just to clarify what I am aiming to achieve here, I want to send an IOCTL to the edo from my win app, which then stores the memory address for the associated output buffer, marks the IRP as IO_PENDING and then returns. I have already written the code to do all that, and it works fine for the fido handler for IRP_MJ_DEVICE_CONTROL, I’m just trying to get it working for the edo. So effectively all I’ve done so far is create the edo, create a symbolic link, and use an extra flag in my DEVICE_EXTENSION structure to determine between fido/edo. I’m not sure what else I should change to make the code work for the edo, not just the original fido. When CloseFile is called, what other IRPs are sent to the device, and should any of them be handled differently to how I’d normally handle them for the fido object?

Hope all that makes sense!

Thanks,

Ben

15

It sounds to me like you just have some sort of ordinary, garden-variety, bug in your cleanup and close code Ben.

Your design sounds reasonable.

So, you’re NOT mapping the section into the caller if he opens the Control Device Object (what you’re calling the EDO)?? If not, you shouldn’t have to do anything at all for IRP_MJ_CLEANUP and IRP_MJ_CLOSE when you get an IRP associated with your EDO… just complete the request with success.

And there are no other outstanding requests on the EDO from the caller when it calls CloseHandle?? You don’t have any IRPs pending on the EDO during the close?

CLEANUP and CLOSE are the only requests you get as a result of a user issuing a CloseHandle.

Peter
OSR

16

The code I’ve got in my MemDrvCleanup routine is copied from OSR’s sample on Sharing Memory Between Drivers and Applications (http://www.osronline.com/article.cfm?article=39), and it’s proven to work with standard filter device object.

I’ve got a slightly different BSOD now. The exception is still “EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.” - which I believe is still to do with some KdPrint calls? (I don’t understand how/why the KdPrints would be causing these errors…) But I’m also getting:

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x805591e0
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from 804ee129 to f7a0e37b

STACK_TEXT:
ed8a5c60 804ee129 85c7d280 84c12140 84c12140 hpfilter!MemDrvCleanup+0x8b [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1344]
ed8a5ca4 805b21e0 863cc020 85c7d280 0012019f nt!CcLazyWriteScan+0x398
ed8a5cd4 805b1b0d 863cc020 00000001 867e9040 nt!pIoQueryBusDescription+0xda
ed8a5cfc 805b1bab e1378608 858af568 00000094 nt!CmTypeString+0x7d
ed8a5d44 805b1ce3 00000094 00000001 00000000 nt!string'+0x13 ed8a5d58 8053d648 00000094 0012f710 7c90e514 nt!string’+0xb
ed8a5d64 7c90e514 badb0d00 0012f70c ed956d98 nt!PopRunDownSourceTargetList+0x10e
WARNING: Frame IP not in any known module. Following frames may be wrong.
ed8a5d68 badb0d00 0012f70c ed956d98 ed956dcc 0x7c90e514
ed8a5d6c 0012f70c ed956d98 ed956dcc 00000000 0xbadb0d00
ed8a5d70 ed956d98 ed956dcc 00000000 00000000 0x12f70c
ed8a5d74 ed956dcc 00000000 00000000 00000000 0xed956d98
ed8a5d78 00000000 00000000 00000000 00000000 0xed956dcc

…

Any help will be greatly appreciated!

Thanks,

Ben

17

If the problem is caused by some KdPrint call, then there should be no
problem with release build driver. Have you tried the release build of your
driver? And can you enable driver verifier on your driver and enable
‘Special pool’, ‘Pool tracking’, ‘I/O verification’ and ‘Enhanced I/O
verification’?

Is that possible that you can post your MemDrvCleanup() code at here?

On Mon, Sep 21, 2009 at 11:13 AM, <ben.simpson> wrote:

> The code I’ve got in my MemDrvCleanup routine is copied from OSR’s sample
> on Sharing Memory Between Drivers and Applications (
> http://www.osronline.com/article.cfm?article=39), and it’s proven to work
> with standard filter device object.
>
> I’ve got a slightly different BSOD now. The exception is still
> “EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.” - which I
> believe is still to do with some KdPrint calls? (I don’t understand how/why
> the KdPrints would be causing these errors…) But I’m also getting:
>
> WARNING: SystemResourcesList->Flink chain invalid. Resource may be
> corrupted, or already deleted.
>
> WARNING: SystemResourcesList->Blink chain invalid. Resource may be
> corrupted, or already deleted.
>
> 1 total locks
>
> PNP_TRIAGE:
> Lock address : 0x805591e0
> Thread Count : 0
> Thread address: 0x00000000
> Thread wait : 0x0
>
> LAST_CONTROL_TRANSFER: from 804ee129 to f7a0e37b
>
> STACK_TEXT:
> ed8a5c60 804ee129 85c7d280 84c12140 84c12140 hpfilter!MemDrvCleanup+0x8b
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1344]
> ed8a5ca4 805b21e0 863cc020 85c7d280 0012019f nt!CcLazyWriteScan+0x398
> ed8a5cd4 805b1b0d 863cc020 00000001 867e9040 nt!pIoQueryBusDescription+0xda
> ed8a5cfc 805b1bab e1378608 858af568 00000094 nt!CmTypeString+0x7d
> ed8a5d44 805b1ce3 00000094 00000001 00000000 nt!string'+0x13<br>&gt; ed8a5d58 8053d648 00000094 0012f710 7c90e514 nt!string’+0xb
> ed8a5d64 7c90e514 badb0d00 0012f70c ed956d98
> nt!PopRunDownSourceTargetList+0x10e
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> ed8a5d68 badb0d00 0012f70c ed956d98 ed956dcc 0x7c90e514
> ed8a5d6c 0012f70c ed956d98 ed956dcc 00000000 0xbadb0d00
> ed8a5d70 ed956d98 ed956dcc 00000000 00000000 0x12f70c
> ed8a5d74 ed956dcc 00000000 00000000 00000000 0xed956d98
> ed8a5d78 00000000 00000000 00000000 00000000 0xed956dcc
>
> …
>
> Any help will be greatly appreciated!
>
> Thanks,
>
> Ben
>
> —
> 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
></ben.simpson>

18

Michael, can you explain how to enable driver verifier, and ‘Special pool’ etc, I’m not sure how to go about doing that.

My code from MemDrvCleanup is as follows (as I said, exactly as-is from OSR’s example…)

NTSTATUS MemDrvCleanup(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
PIO_STACK_LOCATION ioStackLocation;
PDEVICE_EXTENSION devExt = (PDEVICE_EXTENSION)DeviceObject->DeviceExtension;
PMEM_USER_ENTRY pEntry = NULL;
NTSTATUS status = STATUS_SUCCESS;

ioStackLocation = IoGetCurrentIrpStackLocation(Irp);

//
// Gain access to the MemUserList…
//
ExAcquireFastMutex(&devExt->MemUserListMutex);

//
// Check to see if there are any entries on the list…
//
if(!IsListEmpty(&devExt->MemUserList)) {

//
// Go thru the list and remove the entry whose file object matches the one contained in the
// cleanup IRP.
//
PLIST_ENTRY pLentry;
for(pLentry = devExt->MemUserList.Flink; pLentry != &devExt->MemUserList; pLentry = pLentry->Flink) {
pEntry = (PMEM_USER_ENTRY) pLentry;
if(pEntry->FileObject == ioStackLocation->FileObject) {
//
// We have found a match, remove it from the list, unmap, free the memory, and then
// deallocate the ENTRY from the list. We’re good after this…
//
RemoveEntryList(&pEntry->ListEntry);
UnMapAndFreeMemory(pEntry->PMdl,pEntry->UserVaToReturn);
ExFreePool(pEntry);
break;
}
}
}

//
// Release access to the list.
//
ExReleaseFastMutex(&devExt->MemUserListMutex);

//
// Gain access to the IRP queue…
//
ExAcquireFastMutex(&devExt->IrpQueueMutex);

//
// See if there are any hanging IOCTL_OSR_SETSHAREMEM Irps.
//

if(!IsListEmpty(&devExt->IrpQueue)) {

//
// The list is not empty… Go through the list looking for an entry with a File Object that
// matches the one contained in the cleanup IRP.
//
PLIST_ENTRY pLentry;
for(pLentry = devExt->IrpQueue.Flink; pLentry != &devExt->IrpQueue; pLentry = pLentry->Flink) {
pEntry = (PMEM_USER_ENTRY) pLentry;
if(pEntry->FileObject == ioStackLocation->FileObject) {
//
// We found a match, remove the entry from the list,
// clear the cancel routine,
// Set the status of the hung irp to cancel and complete
// it. We’re done with this list…
//
RemoveEntryList(&pEntry->ListEntry);
IoSetCancelRoutine(pEntry->Irp,NULL);
pEntry->Irp->IoStatus.Status = STATUS_SUCCESS;
pEntry->Irp->IoStatus.Information = 0;
IoCompleteRequest(pEntry->Irp,IO_NO_INCREMENT);
ExFreePool(pEntry);
break;
}
}
}

//
// Release access to the Irp Queue.
//
ExReleaseFastMutex(&devExt->IrpQueueMutex);

Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;

IoCompleteRequest(Irp, IO_NO_INCREMENT);

return(STATUS_SUCCESS);
}

Ben

19

If KdPrint is causing the crash these are the possibilities come to my mind,

  1. Stack is corrupt (Looks like parameters to KdPrint is not causing issues)
  2. Are you using any special compiler switches that block
    FUNCTION expansion ?

Sisimon
Bangalore
On Mon, Sep 21, 2009 at 8:43 PM, <ben.simpson> wrote:

> The code I’ve got in my MemDrvCleanup routine is copied from OSR’s sample
> on Sharing Memory Between Drivers and Applications (
> http://www.osronline.com/article.cfm?article=39), and it’s proven to work
> with standard filter device object.
>
> I’ve got a slightly different BSOD now. The exception is still
> “EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.” - which I
> believe is still to do with some KdPrint calls? (I don’t understand how/why
> the KdPrints would be causing these errors…) But I’m also getting:
>
> WARNING: SystemResourcesList->Flink chain invalid. Resource may be
> corrupted, or already deleted.
>
> WARNING: SystemResourcesList->Blink chain invalid. Resource may be
> corrupted, or already deleted.
>
> 1 total locks
>
> PNP_TRIAGE:
> Lock address : 0x805591e0
> Thread Count : 0
> Thread address: 0x00000000
> Thread wait : 0x0
>
> LAST_CONTROL_TRANSFER: from 804ee129 to f7a0e37b
>
> STACK_TEXT:
> ed8a5c60 804ee129 85c7d280 84c12140 84c12140 hpfilter!MemDrvCleanup+0x8b
> [c:\winddk\6001.18002\src\storage\filters\hpfilter\hpfilter.cpp @ 1344]
> ed8a5ca4 805b21e0 863cc020 85c7d280 0012019f nt!CcLazyWriteScan+0x398
> ed8a5cd4 805b1b0d 863cc020 00000001 867e9040 nt!pIoQueryBusDescription+0xda
> ed8a5cfc 805b1bab e1378608 858af568 00000094 nt!CmTypeString+0x7d
> ed8a5d44 805b1ce3 00000094 00000001 00000000 nt!string'+0x13<br>&gt; ed8a5d58 8053d648 00000094 0012f710 7c90e514 nt!string’+0xb
> ed8a5d64 7c90e514 badb0d00 0012f70c ed956d98
> nt!PopRunDownSourceTargetList+0x10e
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> ed8a5d68 badb0d00 0012f70c ed956d98 ed956dcc 0x7c90e514
> ed8a5d6c 0012f70c ed956d98 ed956dcc 00000000 0xbadb0d00
> ed8a5d70 ed956d98 ed956dcc 00000000 00000000 0x12f70c
> ed8a5d74 ed956dcc 00000000 00000000 00000000 0xed956d98
> ed8a5d78 00000000 00000000 00000000 00000000 0xed956dcc
>
> …
>
> Any help will be greatly appreciated!
>
> Thanks,
>
> Ben
>
> —
> 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
>

–
GCS d+ s: a- c++++ U> B+ L++>$ w++++$ W++(+++) PGP+N+ t PS+PE++ tv+(++) b+++
G+++ e++>(++++) h-- r
Don’t know this? See http://www.geekcode.com/geek.html</ben.simpson>

20

Nope, no special compiler switches. It’s been working fine up until now, and it still works fine in other functions. Stack corruption is my guess too.

Ben