Filter driver attempts to find device object and crashes

OSR_Community_User · December 14, 2005, 2:57pm

This one has me stumped. Or I’m looking at it and it just doesn’t register.

File scope:

UNICODE_STRING DriverUnicodeString;
PFILE_OBJECT DriverFileObject;
PDEVICE_OBJECT DriverDeviceObject;

In DriverEntry:

RtlInitUnicodeString (&DriverUnicodeString, L"\Device\Xyz");

NtStatus = IoGetDeviceObjectPointer (
&DriverUnicodeString,
STANDARD_RIGHTS_ALL,
&DriverFileObject,
&DriverDeviceObject);
if (NtStatus != STATUS_SUCCESS) {
DbgPrint (“*** Could not open driver\n”);
}
else {
DbgPrint (“Driver found\n”);
SetFlag (Flags, SBPFLG_XYZ_OPEN);
}

Crash 0xC0000005 (STATUS_ACCESS_VIOLATION) @ IoGetDeviceObjectPointer().

The Xyz driver is running without apparent problem. If I corrupt the “Xyz”
name, I get an error in NtStatus as expected.

What could the Xyz driver possibly do to mess this up?

OSR_Community_User · December 14, 2005, 5:00pm

Hello,

IoGetDeviceObjectPointer uses ZwOpenFile internally to open \Device\Xyz - not much…

if you try to open \Device\Xyz, which you have just created in DriverEntry, then you’ll fail ! Since your DriverObject is not still initialized (it sends IRP_MJ_CREATE and even if you set DO_DEVICE_INITIALIZING in pDriverObject->Flags it won’t help much).

not sure if this helps…

bye,
Petr Kurtin

“Mickey & Eileen Lane” wrote in message news:xxxxx@ntfsd…
> This one has me stumped. Or I’m looking at it and it just doesn’t register.
>
> File scope:
>
> UNICODE_STRING DriverUnicodeString;
> PFILE_OBJECT DriverFileObject;
> PDEVICE_OBJECT DriverDeviceObject;
>
> In DriverEntry:
>
> RtlInitUnicodeString (&DriverUnicodeString, L"\Device\Xyz");
>
> NtStatus = IoGetDeviceObjectPointer (
> &DriverUnicodeString,
> STANDARD_RIGHTS_ALL,
> &DriverFileObject,
> &DriverDeviceObject);
> if (NtStatus != STATUS_SUCCESS) {
> DbgPrint (“*** Could not open driver\n”);
> }
> else {
> DbgPrint (“Driver found\n”);
> SetFlag (Flags, SBPFLG_XYZ_OPEN);
> }
>
> Crash 0xC0000005 (STATUS_ACCESS_VIOLATION) @ IoGetDeviceObjectPointer().
>
> The Xyz driver is running without apparent problem. If I corrupt the “Xyz”
> name, I get an error in NtStatus as expected.
>
> What could the Xyz driver possibly do to mess this up?
>
>

OSR_Community_User · December 15, 2005, 6:56am

The Xyz device is another driver that has been running for a long time.
I was trying to get this driver to talk to that driver.

I commented out the IoGetDeviceObjectPointer() and put in
InitializeObjectAttributes(), ZwOpenFile() and
ObReferenceObjectByHandle() with all of the same arguments and it works
fine.

I’m doing this on Windows 2000 hoping to get one version of the Xyz
driver that will work on all 32-bit platforms. Maybe that has something
to do with it… Anyway, thanks. Your comment about “internally” pushed
me in the right direction.

Mickey.

Petr Kurtin wrote:

Hello,

IoGetDeviceObjectPointer uses ZwOpenFile internally to open
\Device\Xyz - not much…

if you try to open \Device\Xyz, which you have just created in
DriverEntry, then you’ll fail ! Since your DriverObject is not still
initialized (it sends IRP_MJ_CREATE and even if you set
DO_DEVICE_INITIALIZING in pDriverObject->Flags it won’t help much).

not sure if this helps…

bye,
Petr Kurtin

“Mickey & Eileen Lane” > mailto:xxxxx> wrote in message news:xxxxx@ntfsd…
> > This one has me stumped. Or I’m looking at it and it just doesn’t
> register.
> >
> > File scope:
> >
> > UNICODE_STRING DriverUnicodeString;
> > PFILE_OBJECT DriverFileObject;
> > PDEVICE_OBJECT DriverDeviceObject;
> >
> > In DriverEntry:
> >
> > RtlInitUnicodeString (&DriverUnicodeString, L"\Device\Xyz
> <file:>“);
> >
> > NtStatus = IoGetDeviceObjectPointer (
> > &DriverUnicodeString,
> > STANDARD_RIGHTS_ALL,
> > &DriverFileObject,
> > &DriverDeviceObject);
> > if (NtStatus != STATUS_SUCCESS) {
> > DbgPrint (”*** Could not open driver\n");
> > }
> > else {
> > DbgPrint (“Driver found\n”);
> > SetFlag (Flags, SBPFLG_XYZ_OPEN);
> > }
> >
> > Crash 0xC0000005 (STATUS_ACCESS_VIOLATION) @ IoGetDeviceObjectPointer().
> >
> > The Xyz driver is running without apparent problem. If I corrupt the
> “Xyz”
> > name, I get an error in NtStatus as expected.
> >
> > What could the Xyz driver possibly do to mess this up?
> >
> >
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com</file:></mailto:xxxxx>

OSR_Community_User · December 16, 2005, 12:01pm

I need to start this topic over again with a different description.

I’m doing this on Windows 2000 but it’ll be deployed on XP as well. I’m
using the IFS DDK.

I have three components - user code _U, a filter driver _F and a boot
driver _B.

The object is to get _F to open _B and issue Ioctl IRPs.

#1
_U asks service control manager if _B exists. If no, _U creates the _B
service (flagged as a boot driver) and starts it.
If yes, it does nothing.

#2
_U uses service control manager to load _F and start it. In
DriverEntry(), _F tries to communicate with _B.

In the case above where _U created & started _B - - everything works fine.

In the case where _B was in the registry prior to system boot and was
started during boot - - when _F tries to obtain the PDEVICE_OBJECT for
_B, the system crashes if I use IoGetDeviceObjectPointer. If I use
InitializeObjectAttributes + ZwOpenFile + ObReferenceObjectByHandle, the
system does not crash but the PDEVICE_OBJECT I get is bogus.

_B always works as it doesn’t actually do much at this point. The
problem seems to be related to _B and when it starts. If started after
boot, it’s good. If started at boot, the system blows up when something
tries to attach to it.

Suggestions?

Regards,
Mickey.

OSR_Community_User · December 16, 2005, 12:09pm

Be more explicit than “the system blows up”. That’s user talk. Post the
!analyze -v output for each of the scenarios that are failing for you. Your
approach may be valid, but you may have details wrong. Only output as
specific as !analyze -v will help.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 12:01 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

I need to start this topic over again with a different description.

I’m doing this on Windows 2000 but it’ll be deployed on XP as well. I’m
using the IFS DDK.

I have three components - user code _U, a filter driver _F and a boot driver
_B.

The object is to get _F to open _B and issue Ioctl IRPs.

#1
_U asks service control manager if _B exists. If no, _U creates the _B
service (flagged as a boot driver) and starts it.
If yes, it does nothing.

#2
_U uses service control manager to load _F and start it. In DriverEntry(),
_F tries to communicate with _B.

In the case above where _U created & started _B - - everything works fine.

In the case where _B was in the registry prior to system boot and was
started during boot - - when _F tries to obtain the PDEVICE_OBJECT for _B,
the system crashes if I use IoGetDeviceObjectPointer. If I use
InitializeObjectAttributes + ZwOpenFile + ObReferenceObjectByHandle, the
system does not crash but the PDEVICE_OBJECT I get is bogus.

_B always works as it doesn’t actually do much at this point. The problem
seems to be related to _B and when it starts. If started after boot, it’s
good. If started at boot, the system blows up when something tries to attach
to it.

Suggestions?

Regards,
Mickey.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 16, 2005, 12:32pm

Sorry. You're quite right.
Crash occured in VMware. "sbprotector" is the filter driver.
"driverentry.c @ 175" is:

WCHAR DriverName = L"\Device\Sbhr0";
UNICODE_STRING DriverDeviceNameString = {26, 26, DriverName };
PFILE_OBJECT DriverFileObject;
PDEVICE_OBJECT DriverDeviceObject;

NtStatus = IoGetDeviceObjectPointer (
&DriverDeviceNameString,
FILE_READ_ATTRIBUTES,
&DriverFileObject,
&DriverDeviceObject);

The _U call to load _B via service control manager is:

Service = CreateService (
SCManagerHandle, // SCManager database
SbhrDriverName, // name of service
SbhrDriverName, // name to display
SERVICE_ALL_ACCESS, // desired access
SERVICE_KERNEL_DRIVER, // service type
SERVICE_BOOT_START, // start type
SERVICE_ERROR_IGNORE, // error control type
SystemDriverPathAndName, // service's binary
NULL, // no load ordering group
NULL, // no tag identifier
NULL, // no dependencies
NULL, // LocalSystem account
NULL); // no password

The same binary images (_U, _F & _B) work if _B is not started at boot time.

Loading Dump File [G:\Crash Dumps\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

************************************************************************
WARNING: Dump file has inconsistent set-bit count. Data may be missing.
************************************************************************
Symbol search path is:
SRV*f:\Symbols*http://msdl.microsoft.com/download/symbols;F:\SYMBOLS
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x804814c0
Debug session time: Fri Dec 16 12:17:57 2005
System Uptime: 0 days 0:02:33.968
Loading Kernel Symbols
..................................Page 22b7 not present in the dump
file. Type ".hh dbgerr004" for details
.................................................
Loading unloaded module list
............
Loading User Symbols
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {c0000005, 0, 0, 0}

Probably caused by : sbprotector.sys ( sbprotector!DriverEntry+21f )

Followup: MachineOwner

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

KMODE_EXCEPTION_NOT_HANDLED (1e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 00000000, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 00000000, Parameter 1 of the exception

Debugging Details:

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

FAULTING_IP:
+0
00000000 ?? ???

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000000

READ_ADDRESS: 00000000

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x1E

LAST_CONTROL_TRANSFER: from 8041dded to 00000000

TRAP_FRAME: f40476d8 -- (.trap fffffffff40476d8)
ErrCode = 00000000
eax=00000012 ebx=815423f8 ecx=81870df0 edx=815423e8 esi=815423e8
edi=81870cd0
eip=00000000 esp=f404774c ebp=f4047790 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
00000000 ?? ???
Resetting default scope

STACK_TEXT:
f4047748 8041dded 81870cd0 815423e8 815a9a48 0x0
f404775c 804c04c8 80064fac 818a8680 00000001 nt!IopfCallDriver+0x35
f4047790 804d6ff2 818b5420 81870cd0 00000080 nt!IopCloseFile+0x2b4
f40477bc 8044ecdc 818b5420 815a9a34 815a9a48
nt!ObpDecrementHandleCount+0x13c
f4047870 80464f84 00000260 818b5f08 8044e765 nt!NtClose+0x1f0
f4047870 8042f9eb 00000260 818b5f08 8044e765 nt!KiSystemService+0xc4
f40478ec 8049ffc8 00000260 81560700 e1fb1140 nt!ZwClose+0xb
f4047920 f3da111f 00000260 815a9a48 f3da87d0
nt!IoGetDeviceObjectPointer+0x76
f4047c90 804ad3ca 815f3710 81139000 be8dbd08
sbprotector!DriverEntry+0x21f
[g:\e6\sbprotector\src\driver\legacy\driverentry.c @ 175]
f4047d58 804ad60b 0000023c 81139000 be8dbd08 nt!IopLoadDriver+0x672
f4047d78 80416bfa be8dbd08 00000000 00000000 nt!IopLoadUnloadDriver+0x3f
f4047da8 80454a24 be8dbd08 00000000 00000000 nt!ExpWorkerThread+0xae
f4047ddc 80469212 80416b4c 00000001 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
sbprotector!DriverEntry+21f
[g:\e6\sbprotector\src\driver\legacy\driverentry.c @ 175]
f3da111f 8945b0 mov [ebp-0x50],eax

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: sbprotector!DriverEntry+21f

MODULE_NAME: sbprotector

IMAGE_NAME: sbprotector.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 43a2f199

STACK_COMMAND: .trap fffffffff40476d8 ; kb

BUCKET_ID: 0x1E_BAD_IP_sbprotector!DriverEntry+21f

Followup: MachineOwner

Arlie Davis wrote:

Be more explicit than "the system blows up". That's user talk. Post the
!analyze -v output for each of the scenarios that are failing for you. Your
approach may be valid, but you may have details wrong. Only output as
specific as !analyze -v will help.

-- arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 12:01 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

I need to start this topic over again with a different description.

I'm doing this on Windows 2000 but it'll be deployed on XP as well. I'm
using the IFS DDK.

I have three components - user code _U, a filter driver _F and a boot driver
_B.

The object is to get _F to open _B and issue Ioctl IRPs.

#1
_U asks service control manager if _B exists. If no, _U creates the _B
service (flagged as a boot driver) and starts it.
If yes, it does nothing.

#2
_U uses service control manager to load _F and start it. In DriverEntry(),
_F tries to communicate with _B.

In the case above where _U created & started _B - - everything works fine.

In the case where _B was in the registry prior to system boot and was
started during boot - - when _F tries to obtain the PDEVICE_OBJECT for _B,
the system crashes if I use IoGetDeviceObjectPointer. If I use
InitializeObjectAttributes + ZwOpenFile + ObReferenceObjectByHandle, the
system does not crash but the PDEVICE_OBJECT I get is bogus.

_B always works as it doesn't actually do much at this point. The problem
seems to be related to _B and when it starts. If started after boot, it's
good. If started at boot, the system blows up when something tries to attach
to it.

Suggestions?

Regards,
Mickey.

Questions? First check the IFS FAQ at
The NT Insider:Windows NT Virtual Memory (Part I)

You are currently subscribed to ntfsd as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at The NT Insider:Windows NT Virtual Memory (Part I)

You are currently subscribed to ntfsd as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 16, 2005, 12:45pm

Ok, now read the !analyze -v output. The fault is occurring at line 175 of
your driverentry.c. The fault is an access violation, apparently because
your code has jumped to NULL (set eip to NULL). You need to figure out why.
Your next step should be to use the command that !analyze prints out, in
order to set your debugger context to the context that was active when the
fault occurred. That command is listed below in the output: ".trap
fffffffff40476d8 ; kb". Enter this command, and you will be able to see the
stack that was active when the fault occurred.

Are you the person who was creating instances of PDEVICE_OBJECT and
PDRIVER_OBJECT manually, using ExAllocatePool? If so, don't do that.

It appears that ZwClose is running, and it has retrieved the dispatch method
for IRP_MJ_CLOSE from the device object, and has jumped to it. But that
pointer is NULL, so the fault occurs. Can you post your DriverEntry code,
verbatim?

Also, you should use RtlInitUnicodeString in preference to manually
initializing UNICODE_STRING instances. It's less fragile; if you change the
string name, there's a chance you'll forget to update the string length, or
get it wrong.

-- arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 12:32 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

Sorry. You're quite right.
Crash occured in VMware. "sbprotector" is the filter driver.
"driverentry.c @ 175" is:

WCHAR DriverName = L"\Device\Sbhr0"; UNICODE_STRING
DriverDeviceNameString = {26, 26, DriverName }; PFILE_OBJECT
DriverFileObject; PDEVICE_OBJECT DriverDeviceObject;

NtStatus = IoGetDeviceObjectPointer (
&DriverDeviceNameString,
FILE_READ_ATTRIBUTES,
&DriverFileObject,
&DriverDeviceObject);

The _U call to load _B via service control manager is:

Service = CreateService (
SCManagerHandle, // SCManager database
SbhrDriverName, // name of service
SbhrDriverName, // name to display
SERVICE_ALL_ACCESS, // desired access
SERVICE_KERNEL_DRIVER, // service type
SERVICE_BOOT_START, // start type
SERVICE_ERROR_IGNORE, // error control type
SystemDriverPathAndName, // service's binary
NULL, // no load ordering group
NULL, // no tag identifier
NULL, // no dependencies
NULL, // LocalSystem account
NULL); // no password

The same binary images (_U, _F & _B) work if _B is not started at boot time.

Loading Dump File [G:\Crash Dumps\MEMORY.DMP] Kernel Summary Dump File: Only
kernel address space is available

************************************************************************
WARNING: Dump file has inconsistent set-bit count. Data may be missing.
************************************************************************
Symbol search path is:
SRV*f:\Symbols*http://msdl.microsoft.com/download/symbols;F:\SYMBOLS
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x804814c0 Debug session time:
Fri Dec 16 12:17:57 2005 System Uptime: 0 days 0:02:33.968 Loading Kernel
Symbols ..................................Page 22b7 not present in the dump
file. Type ".hh dbgerr004" for details
.................................................
Loading unloaded module list
............
Loading User Symbols
****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

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

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {c0000005, 0, 0, 0}

Probably caused by : sbprotector.sys ( sbprotector!DriverEntry+21f )

Followup: MachineOwner

kd> !analyze -v
****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

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

KMODE_EXCEPTION_NOT_HANDLED (1e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 00000000, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 00000000, Parameter 1 of the exception

Debugging Details:

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

FAULTING_IP:
+0
00000000 ?? ???

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000000

READ_ADDRESS: 00000000

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x1E

LAST_CONTROL_TRANSFER: from 8041dded to 00000000

TRAP_FRAME: f40476d8 -- (.trap fffffffff40476d8) ErrCode = 00000000
eax=00000012 ebx=815423f8 ecx=81870df0 edx=815423e8 esi=815423e8
edi=81870cd0
eip=00000000 esp=f404774c ebp=f4047790 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
00000000 ?? ???
Resetting default scope

STACK_TEXT:
f4047748 8041dded 81870cd0 815423e8 815a9a48 0x0 f404775c 804c04c8 80064fac
818a8680 00000001 nt!IopfCallDriver+0x35 f4047790 804d6ff2 818b5420 81870cd0
00000080 nt!IopCloseFile+0x2b4 f40477bc 8044ecdc 818b5420 815a9a34 815a9a48
nt!ObpDecrementHandleCount+0x13c f4047870 80464f84 00000260 818b5f08
8044e765 nt!NtClose+0x1f0 f4047870 8042f9eb 00000260 818b5f08 8044e765
nt!KiSystemService+0xc4 f40478ec 8049ffc8 00000260 81560700 e1fb1140
nt!ZwClose+0xb f4047920 f3da111f 00000260 815a9a48 f3da87d0
nt!IoGetDeviceObjectPointer+0x76
f4047c90 804ad3ca 815f3710 81139000 be8dbd08 sbprotector!DriverEntry+0x21f
[g:\e6\sbprotector\src\driver\legacy\driverentry.c @ 175]
f4047d58 804ad60b 0000023c 81139000 be8dbd08 nt!IopLoadDriver+0x672
f4047d78 80416bfa be8dbd08 00000000 00000000 nt!IopLoadUnloadDriver+0x3f
f4047da8 80454a24 be8dbd08 00000000 00000000 nt!ExpWorkerThread+0xae
f4047ddc 80469212 80416b4c 00000001 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
sbprotector!DriverEntry+21f
[g:\e6\sbprotector\src\driver\legacy\driverentry.c @ 175]
f3da111f 8945b0 mov [ebp-0x50],eax

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: sbprotector!DriverEntry+21f

MODULE_NAME: sbprotector

IMAGE_NAME: sbprotector.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 43a2f199

STACK_COMMAND: .trap fffffffff40476d8 ; kb

BUCKET_ID: 0x1E_BAD_IP_sbprotector!DriverEntry+21f

Followup: MachineOwner

OSR_Community_User · December 16, 2005, 12:51pm

What does your IRP_MJ_CLEANUP dispatch handler do in the boot time driver?
Do you have a default handler for this request?

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting

(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 9:32 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

Sorry. You're quite right.
Crash occured in VMware. "sbprotector" is the filter driver.
"driverentry.c @ 175" is:

WCHAR DriverName = L"\Device\Sbhr0";
UNICODE_STRING DriverDeviceNameString = {26, 26, DriverName };
PFILE_OBJECT DriverFileObject;
PDEVICE_OBJECT DriverDeviceObject;

NtStatus = IoGetDeviceObjectPointer (
&DriverDeviceNameString,
FILE_READ_ATTRIBUTES,
&DriverFileObject,
&DriverDeviceObject);

The _U call to load _B via service control manager is:

Service = CreateService (
SCManagerHandle, // SCManager database
SbhrDriverName, // name of service
SbhrDriverName, // name to display
SERVICE_ALL_ACCESS, // desired access
SERVICE_KERNEL_DRIVER, // service type
SERVICE_BOOT_START, // start type
SERVICE_ERROR_IGNORE, // error control type
SystemDriverPathAndName, // service's binary
NULL, // no load ordering group
NULL, // no tag identifier
NULL, // no dependencies
NULL, // LocalSystem account
NULL); // no password

The same binary images (_U, _F & _B) work if _B is not started at boot time.

Loading Dump File [G:\Crash Dumps\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

************************************************************************
WARNING: Dump file has inconsistent set-bit count. Data may be missing.
************************************************************************
Symbol search path is:
SRV*f:\Symbols*http://msdl.microsoft.com/download/symbols;F:\SYMBOLS
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x804814c0
Debug session time: Fri Dec 16 12:17:57 2005
System Uptime: 0 days 0:02:33.968
Loading Kernel Symbols
..................................Page 22b7 not present in the dump
file. Type ".hh dbgerr004" for details
.................................................
Loading unloaded module list
............
Loading User Symbols
****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

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

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {c0000005, 0, 0, 0}

Probably caused by : sbprotector.sys ( sbprotector!DriverEntry+21f )

Followup: MachineOwner

kd> !analyze -v
****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

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

KMODE_EXCEPTION_NOT_HANDLED (1e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 00000000, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 00000000, Parameter 1 of the exception

Debugging Details:

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

FAULTING_IP:
+0
00000000 ?? ???

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000000

READ_ADDRESS: 00000000

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x1E

LAST_CONTROL_TRANSFER: from 8041dded to 00000000

TRAP_FRAME: f40476d8 -- (.trap fffffffff40476d8)
ErrCode = 00000000
eax=00000012 ebx=815423f8 ecx=81870df0 edx=815423e8 esi=815423e8
edi=81870cd0
eip=00000000 esp=f404774c ebp=f4047790 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
00000000 ?? ???
Resetting default scope

STACK_TEXT:
f4047748 8041dded 81870cd0 815423e8 815a9a48 0x0
f404775c 804c04c8 80064fac 818a8680 00000001 nt!IopfCallDriver+0x35
f4047790 804d6ff2 818b5420 81870cd0 00000080 nt!IopCloseFile+0x2b4
f40477bc 8044ecdc 818b5420 815a9a34 815a9a48
nt!ObpDecrementHandleCount+0x13c
f4047870 80464f84 00000260 818b5f08 8044e765 nt!NtClose+0x1f0
f4047870 8042f9eb 00000260 818b5f08 8044e765 nt!KiSystemService+0xc4
f40478ec 8049ffc8 00000260 81560700 e1fb1140 nt!ZwClose+0xb
f4047920 f3da111f 00000260 815a9a48 f3da87d0
nt!IoGetDeviceObjectPointer+0x76
f4047c90 804ad3ca 815f3710 81139000 be8dbd08
sbprotector!DriverEntry+0x21f
[g:\e6\sbprotector\src\driver\legacy\driverentry.c @ 175]
f4047d58 804ad60b 0000023c 81139000 be8dbd08 nt!IopLoadDriver+0x672
f4047d78 80416bfa be8dbd08 00000000 00000000 nt!IopLoadUnloadDriver+0x3f
f4047da8 80454a24 be8dbd08 00000000 00000000 nt!ExpWorkerThread+0xae
f4047ddc 80469212 80416b4c 00000001 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
sbprotector!DriverEntry+21f
[g:\e6\sbprotector\src\driver\legacy\driverentry.c @ 175]
f3da111f 8945b0 mov [ebp-0x50],eax

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: sbprotector!DriverEntry+21f

MODULE_NAME: sbprotector

IMAGE_NAME: sbprotector.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 43a2f199

STACK_COMMAND: .trap fffffffff40476d8 ; kb

BUCKET_ID: 0x1E_BAD_IP_sbprotector!DriverEntry+21f

Followup: MachineOwner

Arlie Davis wrote:

Be more explicit than "the system blows up". That's user talk. Post the
!analyze -v output for each of the scenarios that are failing for you.
Your
approach may be valid, but you may have details wrong. Only output as
specific as !analyze -v will help.

-- arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen
Lane
Sent: Friday, December 16, 2005 12:01 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

I need to start this topic over again with a different description.

I'm doing this on Windows 2000 but it'll be deployed on XP as well. I'm
using the IFS DDK.

I have three components - user code _U, a filter driver _F and a boot
driver
_B.

The object is to get _F to open _B and issue Ioctl IRPs.

#1
_U asks service control manager if _B exists. If no, _U creates the _B
service (flagged as a boot driver) and starts it.
If yes, it does nothing.

#2
_U uses service control manager to load _F and start it. In DriverEntry(),
_F tries to communicate with _B.

In the case above where _U created & started _B - - everything works fine.

In the case where _B was in the registry prior to system boot and was
started during boot - - when _F tries to obtain the PDEVICE_OBJECT for _B,
the system crashes if I use IoGetDeviceObjectPointer. If I use
InitializeObjectAttributes + ZwOpenFile + ObReferenceObjectByHandle, the
system does not crash but the PDEVICE_OBJECT I get is bogus.

_B always works as it doesn't actually do much at this point. The problem
seems to be related to _B and when it starts. If started after boot, it's
good. If started at boot, the system blows up when something tries to
attach
to it.

Suggestions?

Regards,
Mickey.

Questions? First check the IFS FAQ at
The NT Insider:Windows NT Virtual Memory (Part I)

You are currently subscribed to ntfsd as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
The NT Insider:Windows NT Virtual Memory (Part I)

You are currently subscribed to ntfsd as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 16, 2005, 1:10pm

Arlie Davis wrote

Are you the person who was creating instances of PDEVICE_OBJECT and
>PDRIVER_OBJECT manually, using ExAllocatePool? If so, don’t do that.

Nope. That definitly isn’t me.

I ran the same test using Windows XP Gold and got about the same thing
with the added comments:

*******************************************************************************
*
*
* 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.
An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
that an unaligned data reference was encountered. The trap frame will
supply additional information.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 00000000, The address that the exception occurred at
Arg3: f9ea670c, Trap Frame
Arg4: 00000000

The STATUS_DATATYPE_MISALIGNMENT bit is interesting.

It appears that ZwClose is running, and it has retrieved the dispatch method
for IRP_MJ_CLOSE from the device object, and has jumped to it. But that
pointer is NULL, so the fault occurs. Can you post your DriverEntry code,
verbatim?

Also, you should use RtlInitUnicodeString in preference to manually
initializing UNICODE_STRING instances. It’s less fragile; if you change the
string name, there’s a chance you’ll forget to update the string length, or
get it wrong.

OSR_Community_User · December 16, 2005, 1:30pm

Peter Scott wrote:

What does your IRP_MJ_CLEANUP dispatch handler do in the boot time driver?

What IRP_MJ_CLEANUP dispatch handler?

DriverObject->MajorFunction[IRP_MJ_CLEANUP] was NULL.

Now it points to:

NTSTATUS Cleanup (PDEVICE_OBJECT DeviceObject, PIRP CleanupIrp)
{
CleanupIrp->IoStatus.Status = STATUS_SUCCESS;
CleanupIrp->IoStatus.Information = 0;
IoCompleteRequest (CleanupIrp, IO_NO_INCREMENT );

return STATUS_SUCCESS;
}

…and things work better. I wasn’t thinking cleanup since the driver does not have an unload routine nor do I ever attempt to unload it.

Thanks.

OSR_Community_User · December 16, 2005, 1:39pm

You should have a default handler setup for ALL dispatch requests, it would
either pass it through or simply complete it, depending on the situation.

The Ob call you are doing to get the object, opens the device then
dereferences the handle, which will issue an IRP_MJ_CLEANUP to the driver.
It deref’s the handle since the API does not return a handle. You should
also have a handler for the IR_MJ_CLOSE since when you dereference the
object it will call this handler.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 10:30 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

Peter Scott wrote:

What does your IRP_MJ_CLEANUP dispatch handler do in the boot time driver?

What IRP_MJ_CLEANUP dispatch handler?

DriverObject->MajorFunction[IRP_MJ_CLEANUP] was NULL.

Now it points to:

NTSTATUS Cleanup (PDEVICE_OBJECT DeviceObject, PIRP CleanupIrp)
{
CleanupIrp->IoStatus.Status = STATUS_SUCCESS;
CleanupIrp->IoStatus.Information = 0;
IoCompleteRequest (CleanupIrp, IO_NO_INCREMENT );

return STATUS_SUCCESS;
}

…and things work better. I wasn’t thinking cleanup since the driver does
not have an unload routine nor do I ever attempt to unload it.

Thanks.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 16, 2005, 1:41pm

Unload and cleanup are very different operations. Unload handles your
driver being unloaded, after all of its device objects have been deleted.

Your IRP_MJ_CLEANUP handler runs when a file object (file handle) is
detaching from the device. If you support IRP_MJ_CREATE (i.e. user-mode
clients), you must support both IRP_MJ_CLEANUP and IRP_MJ_CLOSE.

Think of it like this: A file handle can have any number of outstanding
requests (IRPs) active on it at any time. At some point, someone calls
CloseHandle -> NtClose -> ZwClose. ZwClose calls your IRP_MJ_CLEANUP
handler in order to request that your driver find and cancel any IRPs that
are active on the device. Once all of the IRPs have completed, and the I/O
manager is sure that it will not send any more IRPs to your driver (for this
specific PFILE_OBJECT), it sends IRP_MJ_CLOSE to your driver. This is your
notification that you will never see this PFILE_OBJECT again, and so you
have your chance to tear down state associated with that file object /
handle.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 1:30 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

Peter Scott wrote:

What does your IRP_MJ_CLEANUP dispatch handler do in the boot time driver?

What IRP_MJ_CLEANUP dispatch handler?

DriverObject->MajorFunction[IRP_MJ_CLEANUP] was NULL.

Now it points to:

NTSTATUS Cleanup (PDEVICE_OBJECT DeviceObject, PIRP CleanupIrp) {
CleanupIrp->IoStatus.Status = STATUS_SUCCESS;
CleanupIrp->IoStatus.Information = 0;
IoCompleteRequest (CleanupIrp, IO_NO_INCREMENT );

return STATUS_SUCCESS;
}

…and things work better. I wasn’t thinking cleanup since the driver does
not have an unload routine nor do I ever attempt to unload it.

Thanks.

OSR_Community_User · December 16, 2005, 2:24pm

I’ll run everyhing except IRP_MJ_DEVICE_CONTROL to a do nothing routine
that completes
with success.

Even though I was using the ZwOpen routine as a test alternative to
IoGetDeviceObjectPointer, it didn’t
sink in that I wasn’t prepared to properly support open/close. I had no
intention of ever creating a handle
to it.

Thanks for your help,
Mickey.

Peter Scott wrote:

You should have a default handler setup for ALL dispatch requests, it would
either pass it through or simply complete it, depending on the situation.

The Ob call you are doing to get the object, opens the device then
dereferences the handle, which will issue an IRP_MJ_CLEANUP to the driver.
It deref’s the handle since the API does not return a handle. You should
also have a handler for the IR_MJ_CLOSE since when you dereference the
object it will call this handler.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 10:30 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

Peter Scott wrote:

>What does your IRP_MJ_CLEANUP dispatch handler do in the boot time driver?

What IRP_MJ_CLEANUP dispatch handler?

DriverObject->MajorFunction[IRP_MJ_CLEANUP] was NULL.

Now it points to:

NTSTATUS Cleanup (PDEVICE_OBJECT DeviceObject, PIRP CleanupIrp)
{
CleanupIrp->IoStatus.Status = STATUS_SUCCESS;
CleanupIrp->IoStatus.Information = 0;
IoCompleteRequest (CleanupIrp, IO_NO_INCREMENT );

return STATUS_SUCCESS;
}

…and things work better. I wasn’t thinking cleanup since the driver does
not have an unload routine nor do I ever attempt to unload it.

Thanks.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 16, 2005, 2:24pm

I encounter all of these situations in my filter driver. I think my
problem was that since I wasn’t
trying to get a handle to the boot driver or do anything other than
IRP_MJ_DEVICE_CONTROL, I didn’t implement enough ‘do nothing’ routines.

Thanks for your help.
Mickey.

Arlie Davis wrote:

Unload and cleanup are very different operations. Unload handles your
driver being unloaded, after all of its device objects have been deleted.

Your IRP_MJ_CLEANUP handler runs when a file object (file handle) is
detaching from the device. If you support IRP_MJ_CREATE (i.e. user-mode
clients), you must support both IRP_MJ_CLEANUP and IRP_MJ_CLOSE.

Think of it like this: A file handle can have any number of outstanding
requests (IRPs) active on it at any time. At some point, someone calls
CloseHandle -> NtClose -> ZwClose. ZwClose calls your IRP_MJ_CLEANUP
handler in order to request that your driver find and cancel any IRPs that
are active on the device. Once all of the IRPs have completed, and the I/O
manager is sure that it will not send any more IRPs to your driver (for this
specific PFILE_OBJECT), it sends IRP_MJ_CLOSE to your driver. This is your
notification that you will never see this PFILE_OBJECT again, and so you
have your chance to tear down state associated with that file object /
handle.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey & Eileen Lane
Sent: Friday, December 16, 2005 1:30 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filter driver attempts to find device object and
crashes

Peter Scott wrote:

>What does your IRP_MJ_CLEANUP dispatch handler do in the boot time driver?

What IRP_MJ_CLEANUP dispatch handler?

DriverObject->MajorFunction[IRP_MJ_CLEANUP] was NULL.

Now it points to:

NTSTATUS Cleanup (PDEVICE_OBJECT DeviceObject, PIRP CleanupIrp) {
CleanupIrp->IoStatus.Status = STATUS_SUCCESS;
CleanupIrp->IoStatus.Information = 0;
IoCompleteRequest (CleanupIrp, IO_NO_INCREMENT );

return STATUS_SUCCESS;
}

…and things work better. I wasn’t thinking cleanup since the driver does
not have an unload routine nor do I ever attempt to unload it.

Thanks.

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 16, 2005, 7:08pm

> Even though I was using the ZwOpen routine as a test alternative to

IoGetDeviceObjectPointer, it didn’t

IoGetDeviceObjectPointer calls ZwClose internally. It is a sequence of
ZwCreateFile+ObReferenceObjectByHandle+ZwClose.

So, you must have the cleanup and close paths. Any driver must have them,
otherwise, the file object destruction will BSOD.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com