I’m developing volume filter driver which handles READ/WRITE requests and passes them down to lower driver or creates new IRP and send on FSD on other volume on which there is my archive(with data). So, the problem is that, on WXP, Vista, W2K3 it works fine, but it hangs in boottime on W2K8. I’ve investigated the lock and found that if i take the Irp->Flags from original IRP and copy to my own IRP it works it works. So, the question is, are lower drivers like disk.sys dependend on Irp->Flags like: IRP_PAGING_IO, and how this Flags affect on Irp processing by disk.sys.
wrote in message news:xxxxx@ntdev… > Hi, All! > > I’m developing volume filter driver which handles READ/WRITE requests and passes them down to lower driver or creates new IRP and send on FSD on other volume on which there is my archive(with data). So, the problem is that, on WXP, Vista, W2K3 it works fine, but it hangs in boottime on W2K8. I’ve investigated the lock and found that if i take the Irp->Flags from original IRP and copy to my own IRP it works it works. So, the question is, are lower drivers like disk.sys dependend on Irp->Flags like: IRP_PAGING_IO, and how this Flags affect on Irp processing by disk.sys. >
What is the Flags value in the Irp that hangs your system?
Haibo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rambler.ru
Sent: Tuesday, March 24, 2009 11:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IRP_PAGING_IO used in disk.sys
But why it works for all other OSes?
Once again, when i change Irp->Flags on newly created Irp to be the same
like in original, it unlocks and W2K8 boots furthe.
Could anybody answer on my question, please? I’m in stack?
So, know, when i receive any original Irp with any flags, i just set flags IRP_PAGING_IO, IRP_NOCACHE, IRP_SYNHRONOUS_PAGING_IO for every by me made Irps and it works.
Surely I’ve managed to sent the disk read/write IRPs down the stack without these flags.
Just create the IRP from scratch using IoAllocateIrp.
->Tail.Overlay.Thread is really a must. Without this, in some cases, the IRP becomes hung forever inside the atapi.sys driver, hanging the machine. I don’t know why.
wrote in message news:xxxxx@ntdev… > So, know, when i receive any original Irp with any flags, i just set flags IRP_PAGING_IO, IRP_NOCACHE, IRP_SYNHRONOUS_PAGING_IO for every by me made Irps and it works. > > Could anybody answer why it so? >
" ->Tail.Overlay.Thread is really a must. Without this, in some cases, the IRP becomes hung forever inside the atapi.sys driver, hanging the machine. I don’t know why. "
But this is for removable device. In my case it is not removable.
FOr the background, I was sending some partial irps from a disk filter driver to my device. It was working fine until yesterday but today (no change of code) when I send the partial irp IoCallDriver returns STATUS_PENDING but my IoCompletion routine never gets called back. I can read write to my device from windows explorer but the partial irps from the filter drivers are not coming back.
After some read Irp from NTFS MOUNT thread on of them never completes.
As I said, i read data either from boot volume or from my archive on other volume, but my archive reading implementation is single thread, it locks during calling main function and unlocks after Irp is completed. So, disk.sys returns me status pending and waits for something, perhaps for receiving secodn Irp, but my archive implementation doesn’t allow me do it.
What can disk.sys wait for? Perhaps some of critical VMM irps, i don’t know.
> But this is for removable device. In my case it is not removable.
I discovered that, on XP and 2003, any IRPs going down the disk (even HarddiskVolume) stack must have valid or NULL ->Tail.Overlay.Thread - not junk in this field.
Filling this field in all my paths fixed the nasty bug with “machine hangs due to the IRP stuck pending forever in the ATAPI driver”.
I don’t know why. Just heuristic.
Copying this field from the master IRP fixed the issue.
completion routine should signal the event and return STATUS_MORE_PROCESSING_REQUIRED
completion routine should NOT do if( Irp->PendingReturned) IoMarkIrpPending(Irp); (this snippet is only for a case if CR returns STATUS_SUCCESS)
you must wait for the event (signaled in the CR) just after IoCallDriver
after your postprocessing, you must call IoCompleteRequest once more
you must return some non-pending status to the upper caller.
You can optimize the things by only doing the wait if IoCallDriver returned STATUS_PENDING
In any case the correct status to return to caller is the value of Irp->IoStatus.Status at the moment just before your call to IoCompleteRequest. So:
Status = IoCallDriver
if( Status == STATUS_PENDING )
wait for your event
// here Irp->IoStatus.Status is valid - either success or error
do the postprocessing
Status = Irp->IoStatus.Status;
IoCompleteRequest
return Status;
I am curious how Tail.Overlay.Thread wil have junk in it. If you roll your own irp it will be null, if the io manager sends the irp it will have a valid value.
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Maxim S. Shatskih Sent: Saturday, March 28, 2009 12:25 PM To: Windows System Software Devs Interest List Subject: Re:[ntdev] IRP_PAGING_IO used in disk.sys
> But this is for removable device. In my case it is not removable.
I discovered that, on XP and 2003, any IRPs going down the disk (even HarddiskVolume) stack must have valid or NULL ->Tail.Overlay.Thread - not junk in this field.
Filling this field in all my paths fixed the nasty bug with “machine hangs due to the IRP stuck pending forever in the ATAPI driver”.
I don’t know why. Just heuristic.
Copying this field from the master IRP fixed the issue.
Yes, the entire IRP is zeroed out when you call this API and then the relevant fields (Type, Size, StackCount, etc) are initialized. You can easily see this for yourself by looking at the result from IoAllocateIrp with dt -r _IRP
d
-----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih Sent: Saturday, March 28, 2009 7:17 PM To: Windows System Software Devs Interest List Subject: Re:[ntdev] Re:IRP_PAGING_IO used in disk.sys
>I am curious how Tail.Overlay.Thread wil have junk in it. If you roll your own irp it will be null, if the io >manager sends the irp it will have a valid value.