I am writing a PNP driver and I’m having the following problem :
In the DispatchRead routine for the IRP_MJ_READ I need to pend the IRP and
to insert it into a queue, so I’m doing the following sequence of operations
:
insert the IRP in a queue
call IoMarkIrpPending(Irp)
return STATUS_PENDING
The problem is that after I insert 1 IRP in the list and pending it my
driver doesn’t get any other IRP’s (for a example an IOCTL from my
user-space program)…it seems blocked.
The operation where I insert the IRP in a queue is completing
successfully…this behaviour appears only after I return STATUS_PENDING.
I want to complete this IRP’s only after I get an IOCTL from a program in
user-space…but as said above I don’t receieve anymore IRP’s.
It seems that the whole driver blocks in the context of the thread that
issued the IRP_MJ_READ that was inserted in the list and I don’t understand
why.
Is this a PNP issue ? Any ideas ?
In your test program are you opening the file with OVERLAPPED? The behavior
you describe it exactly correct for a non-overlapped I/O.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Victor Asavei” wrote in message news:xxxxx@ntdev… Hi
I am writing a PNP driver and I’m having the following problem :
In the DispatchRead routine for the IRP_MJ_READ I need to pend the IRP and to insert it into a queue, so I’m doing the following sequence of operations : - insert the IRP in a queue - call IoMarkIrpPending(Irp) - return STATUS_PENDING
The problem is that after I insert 1 IRP in the list and pending it my driver doesn’t get any other IRP’s (for a example an IOCTL from my user-space program)…it seems blocked. The operation where I insert the IRP in a queue is completing successfully…this behaviour appears only after I return STATUS_PENDING. I want to complete this IRP’s only after I get an IOCTL from a program in user-space…but as said above I don’t receieve anymore IRP’s. It seems that the whole driver blocks in the context of the thread that issued the IRP_MJ_READ that was inserted in the list and I don’t understand why. Is this a PNP issue ? Any ideas ?
It seems it is not an OVERLAPPED problem (tested with OVERLAPPED and without
OVERLAPPED -> same behaviour).
Plus it’s not just my test program. The driver is a FILE_DEVICE_DISK driver
that mounts a virtual disk and creates a symbolic link mapping a drive
letter, so the problems occurs even when doing a read operation on the disk
( for example ‘dir x:’ where x: is the drive letter; if I don’t pend any IRP
it works just fine…I get the read IRP generated by the ‘dir x:’ in the
DispatchRoutine )
Victor
On 4/1/06, Don Burn wrote: > > In your test program are you opening the file with OVERLAPPED? The > behavior > you describe it exactly correct for a non-overlapped I/O. > > > – > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > > > > “Victor Asavei” wrote in message > news:xxxxx@ntdev… > Hi > > I am writing a PNP driver and I’m having the following problem : > > In the DispatchRead routine for the IRP_MJ_READ I need to pend the IRP and > to insert it into a queue, so I’m doing the following sequence of > operations > : > - insert the IRP in a queue > - call IoMarkIrpPending(Irp) > - return STATUS_PENDING > > The problem is that after I insert 1 IRP in the list and pending it my > driver doesn’t get any other IRP’s (for a example an IOCTL from my > user-space program)…it seems blocked. > The operation where I insert the IRP in a queue is completing > successfully…this behaviour appears only after I return STATUS_PENDING. > I want to complete this IRP’s only after I get an IOCTL from a program in > user-space…but as said above I don’t receieve anymore IRP’s. > It seems that the whole driver blocks in the context of the thread that > issued the IRP_MJ_READ that was inserted in the list and I don’t > understand > why. > Is this a PNP issue ? Any ideas ? > > Victor > > > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
I can’t tell why you experience that behaviour, but I
can tell you that you should call IoMarkIrpPending
before you insert the Irp in the queue (read the DDK
documentation for IoMarkIrpPending).
Do you synchronize your inserts using some sort of
synchronization mechanism? Make sure you don’t have
any deadlocks or some other kind of problems because
of this.
Regards,
Razvan
— Victor Asavei wrote:
> Hi > > I am writing a PNP driver and I’m having the > following problem : > > In the DispatchRead routine for the IRP_MJ_READ I > need to pend the IRP and > to insert it into a queue, so I’m doing the > following sequence of operations > : > - insert the IRP in a queue > - call IoMarkIrpPending(Irp) > - return STATUS_PENDING > > The problem is that after I insert 1 IRP in the list > and pending it my > driver doesn’t get any other IRP’s (for a example an > IOCTL from my > user-space program)…it seems blocked. > The operation where I insert the IRP in a queue is > completing > successfully…this behaviour appears only after I > return STATUS_PENDING. > I want to complete this IRP’s only after I get an > IOCTL from a program in > user-space…but as said above I don’t receieve > anymore IRP’s. > It seems that the whole driver blocks in the context > of the thread that > issued the IRP_MJ_READ that was inserted in the list > and I don’t understand > why. > Is this a PNP issue ? Any ideas ? > > Victor > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR > Online at http://www.osronline.com/page.cfm?name=ListServer
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Not related to the problem you’re reporting, you’ve got a severe problem with the sequence above. You need to call IoMarkIrpPending on the IRP *before* you insert it into the queue.
So, what you’re saying is that you’re CERTAIN that your application program sends multiple simultaneous read requests, but you’re only being called in your dispatch routine for ONE such request at a time… is that right? How many reads does your app have simultaneously outstanding? We ARE actually talking about your DISPATCH routine here… not your StartIo function, right.
It’s not a PnP problem. As Mr. Burn said, it’s more likely a problem with your application than your driver.
On 4/1/06, Razvan Hobeanu wrote: > > I can’t tell why you experience that behaviour, but I > can tell you that you should call IoMarkIrpPending > before you insert the Irp in the queue (read the DDK > documentation for IoMarkIrpPending).
My mistake before…actually I do call IoMarkIrpPending before inserting the Irp in the queue.
Do you synchronize your inserts using some sort of > synchronization mechanism? Make sure you don’t have > any deadlocks or some other kind of problems because > of this. > Yes, I synchronize the inserts using a FAST_MUTEX but I verified and the inserts are ok…no deadlock here.
Regards, > Razvan > > — Victor Asavei wrote: > > > Hi > > > > I am writing a PNP driver and I’m having the > > following problem : > > > > In the DispatchRead routine for the IRP_MJ_READ I > > need to pend the IRP and > > to insert it into a queue, so I’m doing the > > following sequence of operations > > : > > - insert the IRP in a queue > > - call IoMarkIrpPending(Irp) > > - return STATUS_PENDING > > > > The problem is that after I insert 1 IRP in the list > > and pending it my > > driver doesn’t get any other IRP’s (for a example an > > IOCTL from my > > user-space program)…it seems blocked. > > The operation where I insert the IRP in a queue is > > completing > > successfully…this behaviour appears only after I > > return STATUS_PENDING. > > I want to complete this IRP’s only after I get an > > IOCTL from a program in > > user-space…but as said above I don’t receieve > > anymore IRP’s. > > It seems that the whole driver blocks in the context > > of the thread that > > issued the IRP_MJ_READ that was inserted in the list > > and I don’t understand > > why. > > Is this a PNP issue ? Any ideas ? > > > > Victor > > > > — > > Questions? First check the Kernel Driver FAQ at > > http://www.osronline.com/article.cfm?id=256 > > > > To unsubscribe, visit the List Server section of OSR > > Online at > http://www.osronline.com/page.cfm?name=ListServer > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
> > Not related to the problem you’re reporting, you’ve got a severe problem > with the sequence above. You need to call IoMarkIrpPending on the IRP > before you insert it into the queue.
I call IoMarkIrpPending “before” inserting the IRP.
> > So, what you’re saying is that you’re CERTAIN that your application > program sends multiple simultaneous read requests, but you’re only being > called in your dispatch routine for ONE such request at a time… is that > right? How many reads does your app have simultaneously outstanding? We > ARE actually talking about your DISPATCH routine here… not your StartIo > function, right. > > It’s not a PnP problem. As Mr. Burn said, it’s more likely a problem with > your application than your driver.
Why I am saying it’s a PNP “related problem”…I have written another driver (not PNP) that does exactly the same thing…in the DispatchWrite pends an IRP inserting it in a queue and in the DispatchRead extracts the IRP’s from the list and completes them…and it works just fine. Here it seems that if I don’t complete the IRP the driver blocks. Yes,.we are not talking about the StartIo function and my aplication is used to control the driver with IOCTL’s from user-space so it just sends one IOCTL and then exits. When I try to send another(by running again the test app) nothing gets to the driver, it just blocks as it does if it gets a normal read operation (for example ‘dir x:’ tries to read the first LCN of the volume from the offset 0)
P.S. : In the DispatchRead I’m using a IO_REMOVE_LOCK (as seen in the DDK docs) but I do IoReleaseRemoveLock just before returning STATUS_PENDING.
You can’t use a FAST_MUTEX for IRP cancellation queues, you must use a spinlock. A spinlock is required because the cancellation code uses a spinlock as well, so you must be able to sync at DISPATCH_LEVEL.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Victor Asavei
Sent: Saturday, April 01, 2006 9:01 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Pending IRP_MJ_READ
On 4/1/06, Razvan Hobeanu wrote: I can’t tell why you experience that behaviour, but I can tell you that you should call IoMarkIrpPending before you insert the Irp in the queue (read the DDK documentation for IoMarkIrpPending). ? My mistake before…actually I do call IoMarkIrpPending before inserting the Irp in the queue.
Do you synchronize your inserts using some sort of synchronization mechanism? Make sure you don’t have any deadlocks or some other kind of problems because of this. Yes, I synchronize the inserts using a FAST_MUTEX but I verified and the inserts are ok…no deadlock here. ?
Regards, Razvan
— Victor Asavei wrote:
> Hi > > I am writing a PNP driver and I’m having the > following problem : > > In the DispatchRead routine for the IRP_MJ_READ I > need to pend the IRP and > to insert it into a queue, so I’m doing the > following sequence of operations > : > - insert the IRP in a queue > - call IoMarkIrpPending(Irp) > - return STATUS_PENDING > > The problem is that after I insert 1 IRP in the list > and pending it my > driver doesn’t get any other IRP’s (for a example an > IOCTL from my > user-space program)…it seems blocked. > The operation where I insert the IRP in a queue is > completing > successfully…this behaviour appears only after I > return STATUS_PENDING. > I want to complete this IRP’s only after I get an > IOCTL from a program in > user-space…but as said above I don’t receieve > anymore IRP’s. > It seems that the whole driver blocks in the context > of the thread that > issued the IRP_MJ_READ that was inserted in the list > and I don’t understand > why. > Is this a PNP issue ? Any ideas ? > > Victor > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR > Online at http://www.osronline.com/page.cfm?name=ListServer
__________________________________________________ Do You Yahoo!? Tired of spam???Yahoo! Mail has the best spam protection around http://mail.yahoo.com
“Victor Asavei” wrote in message news:xxxxx@ntdev… >> Yes,.we are not talking about the StartIo function and my aplication is >> used >> to control the driver with IOCTL’s from user-space so it just sends one >> IOCTL and then exits. When I try to send another(by running again the >> test >> app) nothing gets to the driver, it just blocks as it does if it gets a >> normal read operation (for example ‘dir x:’ tries to read the first LCN >> of >> the volume from the offset 0)
Well the next obvious question is are you handling Cancel? Also, is the device exclusive? If you are just doing one IOCTL and exiting you need support for Cancel to clean things up.
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply
It behaves the same with a SpinLock instead of a FAST_MUTEX.
For the queue I’m using a double-linked queue initialized with
InitializeListHead and to insert/delete I’m not using ExInterlockedxxx
functions and that’s why I was using a fast mutex to synchronize access to
the list.
On 4/1/06, Doron Holan wrote: > > You can’t use a FAST_MUTEX for IRP cancellation queues, you must use a > spinlock. A spinlock is required because the cancellation code uses a > spinlock as well, so you must be able to sync at DISPATCH_LEVEL. > > d > > ________________________________________ > From: xxxxx@lists.osr.com [mailto: > xxxxx@lists.osr.com] On Behalf Of Victor Asavei > Sent: Saturday, April 01, 2006 9:01 AM > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] Pending IRP_MJ_READ > > > On 4/1/06, Razvan Hobeanu wrote: > I can’t tell why you experience that behaviour, but I > can tell you that you should call IoMarkIrpPending > before you insert the Irp in the queue (read the DDK > documentation for IoMarkIrpPending). > > My mistake before…actually I do call IoMarkIrpPending before inserting > the Irp in the queue. > > Do you synchronize your inserts using some sort of > synchronization mechanism? Make sure you don’t have > any deadlocks or some other kind of problems because > of this. > Yes, I synchronize the inserts using a FAST_MUTEX but I verified and the > inserts are ok…no deadlock here. > > > Regards, > Razvan > > — Victor Asavei wrote: > > > Hi > > > > I am writing a PNP driver and I’m having the > > following problem : > > > > In the DispatchRead routine for the IRP_MJ_READ I > > need to pend the IRP and > > to insert it into a queue, so I’m doing the > > following sequence of operations > > : > > - insert the IRP in a queue > > - call IoMarkIrpPending(Irp) > > - return STATUS_PENDING > > > > The problem is that after I insert 1 IRP in the list > > and pending it my > > driver doesn’t get any other IRP’s (for a example an > > IOCTL from my > > user-space program)…it seems blocked. > > The operation where I insert the IRP in a queue is > > completing > > successfully…this behaviour appears only after I > > return STATUS_PENDING. > > I want to complete this IRP’s only after I get an > > IOCTL from a program in > > user-space…but as said above I don’t receieve > > anymore IRP’s. > > It seems that the whole driver blocks in the context > > of the thread that > > issued the IRP_MJ_READ that was inserted in the list > > and I don’t understand > > why. > > Is this a PNP issue ? Any ideas ? > > > > Victor > > > > — > > Questions? First check the Kernel Driver FAQ at > > http://www.osronline.com/article.cfm?id=256 > > > > To unsubscribe, visit the List Server section of OSR > > Online at > http://www.osronline.com/page.cfm?name=ListServer > > >__________________________________________________ > Do You Yahoo!? > Tired of spam?Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List > Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
On 4/1/06, Don Burn wrote: > > > “Victor Asavei” wrote in message > news:xxxxx@ntdev… > >> Yes,.we are not talking about the StartIo function and my aplication is > >> used > >> to control the driver with IOCTL’s from user-space so it just sends one > >> IOCTL and then exits. When I try to send another(by running again the > >> test > >> app) nothing gets to the driver, it just blocks as it does if it gets a > >> normal read operation (for example ‘dir x:’ tries to read the first LCN > >> of > >> the volume from the offset 0) > > Well the next obvious question is are you handling Cancel? Also, is the > device exclusive? If you are just doing one IOCTL and exiting you need > support for Cancel to clean things up.
The device is not exclusive. I’m not handling Cancel…why do I need to handle Cancel ? Also by exiting I meant that the test app is exiting…the driver is loaded and running. Let me explain better how it behaves (the driver is loaded in the memory and running) - open 3 command prompts - from the first : user_app mount x: (in the driver I create the link and mapping the drive letter to the device ) - from the second : dir x: (an IRP_MJ_READ arrives and is inserted in the queue and STATUS_PENDING is returned ) - from the third: dir x: (nothing arrives in the driver)
In the DispatchRead if instead of returning STATUS_PENDING I do a CompleteRequest the driver doesn’t block.
To see what happens I use DbgView, so I see when the IRP_MJ_READ arrives, when it is inserted in my queue successfully.
Are you saying the first app is trying to exit while it still has an ioctl
irp pending? Are you processing IRP_MJ_CLEANUP? Does your app wait for the
overlapped request to complete before trying to exit?
I don’t know for sure, but could imagine there is a lock in the OS to
prevent new irps from being dispatched while the OS is waiting to dispatch
an IRP_MJ_CLOSE, which it can’t do until all outstanding irps for the file
handle are completed. The bug would really be your app not waiting for its
overlapped I/O to complete. IRP_MJ_CLEANUP is more for the case of your app
crashes, so can no longer wait for the I/O to complete.
Jan
Also by exiting I meant that the test app is exiting…the driver is loaded
and running.
Let me explain better how it behaves (the driver is loaded in the memory and
running)
open 3 command prompts
from the first : user_app mount x: (in the driver I create the link and
mapping the drive letter to the device )
from the second : dir x: (an IRP_MJ_READ arrives and is inserted in the
queue and STATUS_PENDING is returned )
from the third: dir x: (nothing arrives in the driver)
It seems that the blocking is linked with the device type: I’m using
FILE_DEVICE_DISK.
I think that the problem is with the File System Recognizer when it tries to
determine the file system on my virtual disk and waits for the IRP to be
completed. Is there some kind of global lock that the FSR does to prevent
new IRP’s to be dispatched until it’s IRP’s are completed ?
the file system has the directory llocked when you do the first dir x:\
while it issues a read to the disk. You’ve pended this read. Since
you’ve never mentioned anything about completing it, i’m presuming that
it stays pended for a long time.
the second dir x:\ comes through and blocks because the file system is
already trying to read the metadata in on another thread.
If you want to test whether your driver can handle asynchronous I/O then
you should send asynch I/O to your driver. write an acutal test program
that opens an overlapped handle to the raw partition (x: not x:) and
issue your read requests directly through that using ReadFile &
WriteFile. This will show you what your driver can do.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Victor Asavei
Sent: Saturday, April 01, 2006 10:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Pending IRP_MJ_READ
On 4/1/06, Don Burn wrote:
“Victor Asavei” wrote in message news:xxxxx@ntdev… >> Yes,.we are not talking about the StartIo function and my aplication is >> used >> to control the driver with IOCTL’s from user-space so it just sends one >> IOCTL and then exits. When I try to send another(by running again the >> test >> app) nothing gets to the driver, it just blocks as it does if it gets a >> normal read operation (for example ‘dir x:’ tries to read the first LCN >> of >> the volume from the offset 0)
Well the next obvious question is are you handling Cancel? Also, is the device exclusive? If you are just doing one IOCTL and exiting you need support for Cancel to clean things up.
The device is not exclusive. I’m not handling Cancel…why do I need to handle Cancel ? Also by exiting I meant that the test app is exiting…the driver is loaded and running. Let me explain better how it behaves (the driver is loaded in the memory and running) - open 3 command prompts - from the first : user_app mount x: (in the driver I create the link and mapping the drive letter to the device ) - from the second : dir x: (an IRP_MJ_READ arrives and is inserted in the queue and STATUS_PENDING is returned ) - from the third: dir x: (nothing arrives in the driver)
In the DispatchRead if instead of returning STATUS_PENDING I do a CompleteRequest the driver doesn’t block.
To see what happens I use DbgView, so I see when the IRP_MJ_READ arrives, when it is inserted in my queue successfully.
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply
I doubt there’s a global lock which does exactly what you’re suggesting,
but there could be a global lock which stops a second mount from
happening when one is already in progress. That wouldn’t “prevent new
IRP’s to be dispatched” but it could cause a deadlock if you’re never
completing the first request.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Victor Asavei
Sent: Sunday, April 02, 2006 5:11 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Pending IRP_MJ_READ
It seems that the blocking is linked with the device type: I’m using
FILE_DEVICE_DISK.
I think that the problem is with the File System Recognizer when it
tries to determine the file system on my virtual disk and waits for the
IRP to be completed. Is there some kind of global lock that the FSR does
to prevent new IRP’s to be dispatched until it’s IRP’s are completed ?
On 4/2/06, Peter Wieland wrote: > > I’m going to take a guess here: > > the file system has the directory llocked when you do the first dir x:<br>> while it issues a read to the disk. You’ve pended this read. Since you’ve > never mentioned anything about completing it, i’m presuming that it stays > pended for a long time. > the second dir x:\ comes through and blocks because the file system is already trying to read the metadata in on another thread.
> >
I want to complete that read when an event happens (for example when I get a IOCTL from my user-space app…but I can’t send any IOCTL’s to the driver because it is blocked). What I’m trying to do : - I have a 2 part appilcation : the driver and a program that controls the driver from user-space - I have a compressed Image of an NTFS volume on the disk - I load the driver - using the user-space program I need to “mount” read-only the Image so that I can access files from the Image - I send the mount command to the driver with an IOCTL from the user-space program; in the driver I create a SymbolicLink using a drive letter (for example if the drive letter is x: I create the link \DosDevices\x:) - when I issue ‘x:’ I think the File System Recognizer tries to identify the filesystem and mount the drive, but since I don’t have the information from the Image I need to pend the read operation and obtain the portion of data from the Image; here is the problem…I need a way to somehow pend this read operation but also to be able to communicate with the driver(the driver shouldn’t be blocked) If you want to test whether your driver can handle asynchronous I/O then you should send asynch I/O to your driver. write an acutal test program that opens an overlapped handle to the raw partition (x: not x:) and issue your read requests directly through that using ReadFile & WriteFile. This will show you what your driver can do.
> >
Thanks for the suggestion…I will do that, but I’m curious…if I set the device type to FILE_DEVICE_DISK the driver can’t do asynchronous I/O ?
-p > > ------------------------------ > From:xxxxx@lists.osr.com [mailto: > xxxxx@lists.osr.com] *On Behalf Of *Victor Asavei > Sent: Saturday, April 01, 2006 10:02 AM > > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] Pending IRP_MJ_READ > > > > > > On 4/1/06, Don Burn wrote: > > > > > > “Victor Asavei” wrote in message > > news:xxxxx@ntdev… > > >> Yes,.we are not talking about the StartIo function and my aplication > > is > > >> used > > >> to control the driver with IOCTL’s from user-space so it just sends > > one > > >> IOCTL and then exits. When I try to send another(by running again the > > > > >> test > > >> app) nothing gets to the driver, it just blocks as it does if it gets > > a > > >> normal read operation (for example ‘dir x:’ tries to read the first > > LCN > > >> of > > >> the volume from the offset 0) > > > > Well the next obvious question is are you handling Cancel? Also, is the > > device exclusive? If you are just doing one IOCTL and exiting you need > > support for Cancel to clean things up. > > > The device is not exclusive. > I’m not handling Cancel…why do I need to handle Cancel ? > Also by exiting I meant that the test app is exiting…the driver is > loaded and running. > Let me explain better how it behaves (the driver is loaded in the memory > and running) > - open 3 command prompts > - from the first : user_app mount x: (in the driver I create the link and > mapping the drive letter to the device ) > - from the second : dir x: (an IRP_MJ_READ arrives and is inserted in the > queue and STATUS_PENDING is returned ) > - from the third: dir x: (nothing arrives in the driver) > > In the DispatchRead if instead of returning STATUS_PENDING I do a > CompleteRequest the driver doesn’t block. > > To see what happens I use DbgView, so I see when the IRP_MJ_READ arrives, > when it is inserted in my queue successfully. > > – > > Don Burn (MVP, Windows DDK) > > Windows 2k/XP/2k3 Filesystem and Driver Consulting > > Remove StopSpam from the email to reply > > > > > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at > > http://www.osronline.com/article.cfm?id=256 > > > > To unsubscribe, visit the List Server section of OSR Online at > > http://www.osronline.com/page.cfm?name=ListServer > > > > — Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List > Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
Maybe when you queue your IRPs you also queue the Irps containing the IOCTL and so neither of them ever get the chance of being completed. Do you send the IOCTL to a control device or to the volume device you create inside your driver? If you have a control device, do you use different dispatch code for Irps coming for the control device and those coming for the volume?
Victor Asavei wrote:
On 4/2/06, Peter Wieland wrote: I’m going to take a guess here:
the file system has the directory llocked when you do the first dir x:\ while it issues a read to the disk. You’ve pended this read. Since you’ve never mentioned anything about completing it, i’m presuming that it stays pended for a long time.
the second dir x:\ comes through and blocks because the file system is already trying to read the metadata in on another thread.
I want to complete that read when an event happens (for example when I get a IOCTL from my user-space app…but I can’t send any IOCTL’s to the driver because it is blocked). What I’m trying to do : - I have a 2 part appilcation : the driver and a program that controls the driver from user-space - I have a compressed Image of an NTFS volume on the disk - I load the driver - using the user-space program I need to “mount” read-only the Image so that I can access files from the Image - I send the mount command to the driver with an IOCTL from the user-space program; in the driver I create a SymbolicLink using a drive letter (for example if the drive letter is x: I create the link \DosDevices\x:) - when I issue ‘x:’ I think the File System Recognizer tries to identify the filesystem and mount the drive, but since I don’t have the information from the Image I need to pend the read operation and obtain the portion of data from the Image; here is the problem…I need a way to somehow pend this read operation but also to be able to communicate with the driver(the driver shouldn’t be blocked) If you want to test whether your driver can handle asynchronous I/O then you should send asynch I/O to your driver. write an acutal test program that opens an overlapped handle to the raw partition (x: not x:) and issue your read requests directly through that using ReadFile & WriteFile. This will show you what your driver can do.
Thanks for the suggestion…I will do that, but I’m curious…if I set the device type to FILE_DEVICE_DISK the driver can’t do asynchronous I/O ?
-p
--------------------------------- From: xxxxx@lists.osr.com [mailto: xxxxx@lists.osr.com] On Behalf Of Victor Asavei Sent: Saturday, April 01, 2006 10:02 AM
To: Windows System Software Devs Interest List Subject: Re: [ntdev] Pending IRP_MJ_READ
On 4/1/06, Don Burn wrote: “Victor Asavei” < xxxxx@gmail.com> wrote in message news:xxxxx@ntdev… >> Yes,.we are not talking about the StartIo function and my aplication is >> used >> to control the driver with IOCTL’s from user-space so it just sends one >> IOCTL and then exits. When I try to send another(by running again the >> test >> app) nothing gets to the driver, it just blocks as it does if it gets a >> normal read operation (for example ‘dir x:’ tries to read the first LCN >> of >> the volume from the offset 0)
Well the next obvious question is are you handling Cancel? Also, is the device exclusive? If you are just doing one IOCTL and exiting you need support for Cancel to clean things up. The device is not exclusive. I’m not handling Cancel…why do I need to handle Cancel ? Also by exiting I meant that the test app is exiting…the driver is loaded and running. Let me explain better how it behaves (the driver is loaded in the memory and running) - open 3 command prompts - from the first : user_app mount x: (in the driver I create the link and mapping the drive letter to the device ) - from the second : dir x: (an IRP_MJ_READ arrives and is inserted in the queue and STATUS_PENDING is returned ) - from the third: dir x: (nothing arrives in the driver)
In the DispatchRead if instead of returning STATUS_PENDING I do a CompleteRequest the driver doesn’t block.
To see what happens I use DbgView, so I see when the IRP_MJ_READ arrives, when it is inserted in my queue successfully.
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply
I queue and return STATUS_PENDING only for the IRP’s with IRP_MJ_READ.
The IRP’s with the IOCTL’s (IRP_MJ_DEVICE_CONTROL) always get completed.
I have only one device created that first makes a symbolic link so that the
driver can be controlles from user-space (\??\DeviceName) and when it gets
a command from user-space to “mount” creates another symbolic link (
\DosDevices\DriveLetter:) so all the IOCTL’s are processed inside my
DeviceControl routine. (for example I get from the user-space a custom
IOCTL_MYDRIVER_MOUNT and probably from the File System Recognizer I get a
IOCTL_DISK_GET_LENGTH_INFO; both IOCTL’s are processed and completed; I
receive another IOCTL’s…not just the 2 I just mentioned before and they
are also processed and completed )
On 4/3/06, Razvan Hobeanu wrote: > > Maybe when you queue your IRPs you also queue the Irps containing the > IOCTL and so neither of them ever get the chance of being completed. Do you > send the IOCTL to a control device or to the volume device you create inside > your driver? If you have a control device, do you use different dispatch > code for Irps coming for the control device and those coming for the volume? > > Victor Asavei wrote: > > > > On 4/2/06, Peter Wieland wrote: > > > > I’m going to take a guess here: > > > > the file system has the directory llocked when you do the first dir x:<br>> > while it issues a read to the disk. You’ve pended this read. Since you’ve > > never mentioned anything about completing it, i’m presuming that it stays > > pended for a long time. > > > the second dir x:\ comes through and blocks because the file system is > already trying to read the metadata in on another thread. > > > > > > > I want to complete that read when an event happens (for example when I get > a IOCTL from my user-space app…but I can’t send any IOCTL’s to the driver > because it is blocked). > What I’m trying to do : > - I have a 2 part appilcation : the driver and a program that controls the > driver from user-space > - I have a compressed Image of an NTFS volume on the disk > - I load the driver > - using the user-space program I need to “mount” read-only the Image so > that I can access files from the Image > - I send the mount command to the driver with an IOCTL from the user-space > program; in the driver I create a SymbolicLink using a drive letter (for > example if the drive letter is x: I create the link \DosDevices\x:) > - when I issue ‘x:’ I think the File System Recognizer tries to identify > the filesystem and mount the drive, but since I don’t have the information > from the Image I need to pend the read operation and obtain the portion of > data from the Image; here is the problem…I need a way to somehow pend this > read operation but also to be able to communicate with the driver(the driver > shouldn’t be blocked) > If you want to test whether your driver can handle asynchronous I/O then > you should send asynch I/O to your driver. write an acutal test program > that opens an overlapped handle to the raw partition (x: not x:) and issue > your read requests directly through that using ReadFile & WriteFile. This > will show you what your driver can do. > > > > > > > Thanks for the suggestion…I will do that, but I’m curious…if I set the > device type to FILE_DEVICE_DISK the driver can’t do asynchronous I/O ? > > > -p > > > > ------------------------------ > > From:xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] > > *On Behalf Of *Victor Asavei > > Sent: Saturday, April 01, 2006 10:02 AM > > > > To: Windows System Software Devs Interest List > > Subject: Re: [ntdev] Pending IRP_MJ_READ > > > > > > > > > > > > On 4/1/06, Don Burn wrote: > > > > > > “Victor Asavei” < xxxxx@gmail.com> wrote in message > > news:xxxxx@ntdev… > > >> Yes,.we are not talking about the StartIo function and my aplication > > is > > >> used > > >> to control the driver with IOCTL’s from user-space so it just sends > > one > > >> IOCTL and then exits. When I try to send another(by running again the > > > > >> test > > >> app) nothing gets to the driver, it just blocks as it does if it gets > > a > > >> normal read operation (for example ‘dir x:’ tries to read the first > > LCN > > >> of > > >> the volume from the offset 0) > > > > Well the next obvious question is are you handling Cancel? Also, is the > > device exclusive? If you are just doing one IOCTL and exiting you need > > support for Cancel to clean things up. > > > The device is not exclusive. > I’m not handling Cancel…why do I need to handle Cancel ? > Also by exiting I meant that the test app is exiting…the driver is > loaded and running. > Let me explain better how it behaves (the driver is loaded in the memory > and running) > - open 3 command prompts > - from the first : user_app mount x: (in the driver I create the link and > mapping the drive letter to the device ) > - from the second : dir x: (an IRP_MJ_READ arrives and is inserted in the > queue and STATUS_PENDING is returned ) > - from the third: dir x: (nothing arrives in the driver) > > In the DispatchRead if instead of returning STATUS_PENDING I do a > CompleteRequest the driver doesn’t block. > > To see what happens I use DbgView, so I see when the IRP_MJ_READ arrives, > when it is inserted in my queue successfully. > > – > > Don Burn (MVP, Windows DDK) > > Windows 2k/XP/2k3 Filesystem and Driver Consulting > > Remove StopSpam from the email to reply > > > > > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > > > > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer > > > > > > — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List > Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > > ------------------------------ > New Yahoo! Messenger with Voice. Call regular phones from your PChttp:and save big. — Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List > Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > ></http:>
So you’re trying to issue the I/O control to X: along with the reads?
I don’t think that’s going to work. Everything is going to get
funnelled through the file system.
try making a second device object to send the IOCTL to.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Victor Asavei
Sent: Sunday, April 02, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Pending IRP_MJ_READ
On 4/2/06, Peter Wieland wrote:
I’m going to take a guess here:
the file system has the directory llocked when you do the first dir x:\ while it issues a read to the disk. You’ve pended this read. Since you’ve never mentioned anything about completing it, i’m presuming that it stays pended for a long time.
the second dir x:\ comes through and blocks because the file system is already trying to read the metadata in on another thread.
I want to complete that read when an event happens (for example when I get a IOCTL from my user-space app…but I can’t send any IOCTL’s to the driver because it is blocked). What I’m trying to do : - I have a 2 part appilcation : the driver and a program that controls the driver from user-space - I have a compressed Image of an NTFS volume on the disk - I load the driver - using the user-space program I need to “mount” read-only the Image so that I can access files from the Image - I send the mount command to the driver with an IOCTL from the user-space program; in the driver I create a SymbolicLink using a drive letter (for example if the drive letter is x: I create the link \DosDevices\x:) - when I issue ‘x:’ I think the File System Recognizer tries to identify the filesystem and mount the drive, but since I don’t have the information from the Image I need to pend the read operation and obtain the portion of data from the Image; here is the problem…I need a way to somehow pend this read operation but also to be able to communicate with the driver(the driver shouldn’t be blocked) If you want to test whether your driver can handle asynchronous I/O then you should send asynch I/O to your driver. write an acutal test program that opens an overlapped handle to the raw partition (x: not x:) and issue your read requests directly through that using ReadFile & WriteFile. This will show you what your driver can do.
Thanks for the suggestion…I will do that, but I’m curious…if I set the device type to FILE_DEVICE_DISK the driver can’t do asynchronous I/O ?
To: Windows System Software Devs Interest List Subject: Re: [ntdev] Pending IRP_MJ_READ
On 4/1/06, Don Burn wrote:
“Victor Asavei” < xxxxx@gmail.com mailto:xxxxx > wrote in message news:xxxxx@ntdev… >> Yes,.we are not talking about the StartIo function and my aplication is >> used >> to control the driver with IOCTL’s from user-space so it just sends one >> IOCTL and then exits. When I try to send another(by running again the >> test >> app) nothing gets to the driver, it just blocks as it does if it gets a >> normal read operation (for example ‘dir x:’ tries to read the first LCN >> of >> the volume from the offset 0)
Well the next obvious question is are you handling Cancel? Also, is the device exclusive? If you are just doing one IOCTL and exiting you need support for Cancel to clean things up.
The device is not exclusive. I’m not handling Cancel…why do I need to handle Cancel ? Also by exiting I meant that the test app is exiting…the driver is loaded and running. Let me explain better how it behaves (the driver is loaded in the memory and running) - open 3 command prompts - from the first : user_app mount x: (in the driver I create the link and mapping the drive letter to the device ) - from the second : dir x: (an IRP_MJ_READ arrives and is inserted in the queue and STATUS_PENDING is returned ) - from the third: dir x: (nothing arrives in the driver)
In the DispatchRead if instead of returning STATUS_PENDING I do a CompleteRequest the driver doesn’t block.
To see what happens I use DbgView, so I see when the IRP_MJ_READ arrives, when it is inserted in my queue successfully.
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply
Finally I have succedeed to create the device and get the reads for it. It
seems that when the FS sees an access to the device(for example my app that
sends the mount command to the device) it tries to mount it and locks any
access to it until the process that tried to do the mount dies.
Now I have 2 other problems :
I created a link to my device in \DosDevices\DriveLetter: (for example
\DosDevices\x:) but I can access x: only from the command prompt. I can
browse the drive, copy files, etc. Any idea how to make x: visible from
Explorer ?
I want to be able to unmount the drive when I get a specific IOCTL. When
I receive the command I delete the symbolic link (\DosDevices\x:) and x: is
not visible anymore from the command prompt, but when I try to unload the
driver using SCMAN stop and unload commands the driver gets in the
status_pending mode (device marked for deletion). I suspect that the problem
is that after the mount the filesystem attaches to the device (more exactly
\Filesystem\Ntfs). How can I unload/unmount correctly my driver in this
situation ?