As I mentioned previously, I got my disk filter driver to not cause the system boot disk to become inaccessible by just switching to the 32-bit version of Windows 7. I know the driver is loaded and is acting as an upper filter for the disk subsystem because I have an application that shows what is loaded as a filter for any particular device.
The problem is that I have a function that is the pass-to-next-driver function. I set a breakpoint in there thinking that should get hit a lot with disk activity but it’s not getting hit at all. I only intercept IoDeviceControl() calls, everything else I just pass along.
I also have a lot of DbgPrintEx() calls in the driver so that I can see what’s happening in the kernel debugger but none of those are showing up. I thought I made sure to put the right priority on them so that they will actually make it to the kernel debugger.
I know my AddDevice() is working as I can see the device I create for my driver in WinObj from SysInternals so I know at least some of the driver is getting called. I just can’t figure out why my pass-to-next-driver breakpoint is never hit. Is there some way I can follow an I/O down the stack to see why I’m not ending up in my filter driver?
This is a disk upper filter? If so, what gets ‘hit a lot’ are Read and
Write requests. IOCTL: not so much.
Mark Roddy
On Wed, Feb 24, 2010 at 9:47 AM, Hanson, Jonathan M
wrote:
> As I mentioned previously, I got my disk filter driver to not cause the
> system boot disk to become inaccessible by just switching to the 32-bit
> version of Windows 7. I know the driver is loaded and is acting as an upper
> filter for the disk subsystem because I have an application that shows what
> is loaded as a filter for any particular device.
>
>
>
> The problem is that I have a function that is the pass-to-next-driver
> function. I set a breakpoint in there thinking that should get hit a lot
> with disk activity but it?s not getting hit at all. I only intercept
> IoDeviceControl() calls, everything else I just pass along.
>
>
>
> I also have a lot of DbgPrintEx() calls in the driver so that I can see
> what?s happening in the kernel debugger but none of those are showing up. I
> thought I made sure to put the right priority on them so that they will
> actually make it to the kernel debugger.
>
>
>
> I know my AddDevice() is working as I can see the device I create for my
> driver in WinObj from SysInternals so I know at least some of the driver is
> getting called. I just can?t figure out why my pass-to-next-driver
> breakpoint is never hit. Is there some way I can follow an I/O down the
> stack to see why I?m not ending up in my filter driver?
>
>
>
> —
> 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
Yes it is. Wouldn’t the read and writes also go through my filter and then be passed along down the stack? In my DriverEntry() I immediately fill the major function array with a pointer to my pass-to-next-driver function. I’m putting a breakpoint in that function. Shouldn’t that get hit for any read or write going to any disk?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, February 24, 2010 8:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Breakpoint in disk filter driver not being hit
This is a disk upper filter? If so, what gets ‘hit a lot’ are Read and
Write requests. IOCTL: not so much.
Mark Roddy
On Wed, Feb 24, 2010 at 9:47 AM, Hanson, Jonathan M
wrote:
> As I mentioned previously, I got my disk filter driver to not cause the
> system boot disk to become inaccessible by just switching to the 32-bit
> version of Windows 7. I know the driver is loaded and is acting as an upper
> filter for the disk subsystem because I have an application that shows what
> is loaded as a filter for any particular device.
>
>
>
> The problem is that I have a function that is the pass-to-next-driver
> function. I set a breakpoint in there thinking that should get hit a lot
> with disk activity but it’s not getting hit at all. I only intercept
> IoDeviceControl() calls, everything else I just pass along.
>
>
>
> I also have a lot of DbgPrintEx() calls in the driver so that I can see
> what’s happening in the kernel debugger but none of those are showing up. I
> thought I made sure to put the right priority on them so that they will
> actually make it to the kernel debugger.
>
>
>
> I know my AddDevice() is working as I can see the device I create for my
> driver in WinObj from SysInternals so I know at least some of the driver is
> getting called. I just can’t figure out why my pass-to-next-driver
> breakpoint is never hit. Is there some way I can follow an I/O down the
> stack to see why I’m not ending up in my filter driver?
>
>
>
> —
> 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
Yes. Sorry - I misread " I only intercept IoDeviceControl" and thought
that was where you were setting your breakpoint.
So you are saying that you can use the debugger to set a breakpoint in
your pass-to-next-driver function and that breakpoint never gets hit?
Mark Roddy
On Wed, Feb 24, 2010 at 10:30 AM, Hanson, Jonathan M
wrote:
> Yes it is. Wouldn’t the read and writes also go through my filter and then be passed along down the stack? In my DriverEntry() I immediately fill the major function array with a pointer to my pass-to-next-driver function. I’m putting a breakpoint in that function. Shouldn’t that get hit for any read or write going to any disk?
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Wednesday, February 24, 2010 8:20 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Breakpoint in disk filter driver not being hit
>
> This is a disk upper filter? If so, what gets ‘hit a lot’ are Read and
> Write requests. IOCTL: not so much.
>
> Mark Roddy
>
>
>
> On Wed, Feb 24, 2010 at 9:47 AM, Hanson, Jonathan M
> wrote:
>> As I mentioned previously, I got my disk filter driver to not cause the
>> system boot disk to become inaccessible by just switching to the 32-bit
>> version of Windows 7. I know the driver is loaded and is acting as an upper
>> filter for the disk subsystem because I have an application that shows what
>> is loaded as a filter for any particular device.
>>
>>
>>
>> The problem is that I have a function that is the pass-to-next-driver
>> function. I set a breakpoint in there thinking that should get hit a lot
>> with disk activity but it’s not getting hit at all. I only intercept
>> IoDeviceControl() calls, everything else I just pass along.
>>
>>
>>
>> I also have a lot of DbgPrintEx() calls in the driver so that I can see
>> what’s happening in the kernel debugger but none of those are showing up. I
>> thought I made sure to put the right priority on them so that they will
>> actually make it to the kernel debugger.
>>
>>
>>
>> I know my AddDevice() is working as I can see the device I create for my
>> driver in WinObj from SysInternals so I know at least some of the driver is
>> getting called. I just can’t figure out why my pass-to-next-driver
>> breakpoint is never hit. Is there some way I can follow an I/O down the
>> stack to see why I’m not ending up in my filter driver?
>>
>>
>>
>> —
>> 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
>
> —
> 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
>
That’s correct.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, February 24, 2010 10:00 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Breakpoint in disk filter driver not being hit
Yes. Sorry - I misread " I only intercept IoDeviceControl" and thought
that was where you were setting your breakpoint.
So you are saying that you can use the debugger to set a breakpoint in
your pass-to-next-driver function and that breakpoint never gets hit?
Mark Roddy
On Wed, Feb 24, 2010 at 10:30 AM, Hanson, Jonathan M
wrote:
> Yes it is. Wouldn’t the read and writes also go through my filter and then be passed along down the stack? In my DriverEntry() I immediately fill the major function array with a pointer to my pass-to-next-driver function. I’m putting a breakpoint in that function. Shouldn’t that get hit for any read or write going to any disk?
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Wednesday, February 24, 2010 8:20 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Breakpoint in disk filter driver not being hit
>
> This is a disk upper filter? If so, what gets ‘hit a lot’ are Read and
> Write requests. IOCTL: not so much.
>
> Mark Roddy
>
>
>
> On Wed, Feb 24, 2010 at 9:47 AM, Hanson, Jonathan M
> wrote:
>> As I mentioned previously, I got my disk filter driver to not cause the
>> system boot disk to become inaccessible by just switching to the 32-bit
>> version of Windows 7. I know the driver is loaded and is acting as an upper
>> filter for the disk subsystem because I have an application that shows what
>> is loaded as a filter for any particular device.
>>
>>
>>
>> The problem is that I have a function that is the pass-to-next-driver
>> function. I set a breakpoint in there thinking that should get hit a lot
>> with disk activity but it’s not getting hit at all. I only intercept
>> IoDeviceControl() calls, everything else I just pass along.
>>
>>
>>
>> I also have a lot of DbgPrintEx() calls in the driver so that I can see
>> what’s happening in the kernel debugger but none of those are showing up. I
>> thought I made sure to put the right priority on them so that they will
>> actually make it to the kernel debugger.
>>
>>
>>
>> I know my AddDevice() is working as I can see the device I create for my
>> driver in WinObj from SysInternals so I know at least some of the driver is
>> getting called. I just can’t figure out why my pass-to-next-driver
>> breakpoint is never hit. Is there some way I can follow an I/O down the
>> stack to see why I’m not ending up in my filter driver?
>>
>>
>>
>> —
>> 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
>
> —
> 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 think I got this figured out. I thought it was too easy for my first try at a filter driver that I perfectly had all of the functions written with no system crashes. I think the problem was that I didn’t have a pointer to my AddDevice() function in the appropriate place in the driver extension structure. Once I added that, now I’m getting lots of crashes from my driver that I need to fix :). At least now I can figure out what’s going on if it’s going through my driver.
Thanks everyone for the help and suggestions.
-----Original Message-----
From: Hanson, Jonathan M
Sent: Wednesday, February 24, 2010 8:31 AM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Breakpoint in disk filter driver not being hit
Yes it is. Wouldn’t the read and writes also go through my filter and then be passed along down the stack? In my DriverEntry() I immediately fill the major function array with a pointer to my pass-to-next-driver function. I’m putting a breakpoint in that function. Shouldn’t that get hit for any read or write going to any disk?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, February 24, 2010 8:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Breakpoint in disk filter driver not being hit
This is a disk upper filter? If so, what gets ‘hit a lot’ are Read and
Write requests. IOCTL: not so much.
Mark Roddy
On Wed, Feb 24, 2010 at 9:47 AM, Hanson, Jonathan M
wrote:
> As I mentioned previously, I got my disk filter driver to not cause the
> system boot disk to become inaccessible by just switching to the 32-bit
> version of Windows 7. I know the driver is loaded and is acting as an upper
> filter for the disk subsystem because I have an application that shows what
> is loaded as a filter for any particular device.
>
>
>
> The problem is that I have a function that is the pass-to-next-driver
> function. I set a breakpoint in there thinking that should get hit a lot
> with disk activity but it’s not getting hit at all. I only intercept
> IoDeviceControl() calls, everything else I just pass along.
>
>
>
> I also have a lot of DbgPrintEx() calls in the driver so that I can see
> what’s happening in the kernel debugger but none of those are showing up. I
> thought I made sure to put the right priority on them so that they will
> actually make it to the kernel debugger.
>
>
>
> I know my AddDevice() is working as I can see the device I create for my
> driver in WinObj from SysInternals so I know at least some of the driver is
> getting called. I just can’t figure out why my pass-to-next-driver
> breakpoint is never hit. Is there some way I can follow an I/O down the
> stack to see why I’m not ending up in my filter driver?
>
>
>
> —
> 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