Hi guys,
Is this a known issue that NTFS will not complete IRP_MJ_LOCK_CONTROL / IRP_MN_LOCK (or UNLOCK_SINGLE - not sure) on condition that ByteOffset + *Length cause an overflow? I’ve seen that on Win7/x64 with BANGFS. In my lock control handler I’ve changed ByteOffset from 0 to 512, and left *Length parameter unchanged (-1LL). After passing IRP down to NTFS IoCallDriver returned STATUS_INVALID_LOCK_RANGE (well, ok, kinda expected), but the IRP itself has not been completed (and my completion routine has never been called, even though STATUS_INVALID_LOCK_RANGE returned from IoCallDriver suggests that IRP should have been completed by the time IoCallDriver returned). I checked the IRP in debugger, and it appears to be a legit, live IRP that has not been completed.
Is this NTFS bug, or am I missing something obvious?
Vladimir
On 3/4/2011 4:30 PM, xxxxx@gmail.com wrote:
Hi guys,
Is this a known issue that NTFS will not complete IRP_MJ_LOCK_CONTROL / IRP_MN_LOCK (or UNLOCK_SINGLE - not sure) on condition that ByteOffset + *Length cause an overflow? I’ve seen that on Win7/x64 with BANGFS. In my lock control handler I’ve changed ByteOffset from 0 to 512, and left *Length parameter unchanged (-1LL). After passing IRP down to NTFS IoCallDriver returned STATUS_INVALID_LOCK_RANGE (well, ok, kinda expected), but the IRP itself has not been completed (and my completion routine has never been called, even though STATUS_INVALID_LOCK_RANGE returned from IoCallDriver suggests that IRP should have been completed by the time IoCallDriver returned). I checked the IRP in debugger, and it appears to be a legit, live IRP that has not been completed.
Is this NTFS bug, or am I missing something obvious?
I would recommend stepping into the dispatch routine for NTFS in WinDbg
and seeing how this particular case is handled. It will be quite evident
if the IoCompleteRequest routine is not called.
Pete
Vladimir
NTFSD is sponsored by OSR
For our schedule of debugging and file system 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
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Hi Peter,
I will do more investigations. I totally forgot that there is a bunch of other filters between mine, and NTFS 
That said, I’m 99.99% sure that one of the drivers below me has a bug: IRP most definitely doesn’t get completed. It’ easy let this one fall through the cracks, since most of the time locking is handled via fast I/O path, that doesn’t require any IRP completion, so under normal circumstances testing would not reveal this particular bug. Will update when I figure out something. In the meaning time, I’ve got a fix: just make sure that BRL offset + length that is passed down doesn’t overflow, so this is no longer a high priority issue *for me*.
Thanks,
Vladimir
Verifier should be able to identify a faulty driver that is not calling IoCompleteRequest properly (I’ve done it in the past to work around this bug in both CDFS and NTFS, so it’s not hard to figure out.)
Tony
OSR
Thank you Tony! You are (as usual) a huge time saver
So, it looks like this is in deed NTFS issue:
************************************************************
Driver Verifier detected violation:
An IRP dispatch handler has returned without passing down or completing
this Irp or someone forgot to return STATUS_PENDING.
CulpritAddress = FFFFF8800148B4C0, Irp = FFFFF980337BCBD0.
************************************************************
Break instruction exception - code 80000003 (first chance)
nt!ViErrorFinishReport+0x69:
fffff80003708409 cc int 3 7: kd\> u FFFFF8800148B4C0 Ntfs!NtfsFsdLockControl: fffff8800148b4c0 488bc4 mov rax,rsp
fffff8800148b4c3 48895808 mov qword ptr [rax+8],rbx fffff8800148b4c7 48895010 mov qword ptr [rax+10h],rdx
fffff8800148b4cb 56 push rsi fffff8800148b4cc 57 push rdi
fffff8800148b4cd 4154 push r12 fffff8800148b4cf 4883ec50 sub rsp,50h
fffff880`0148b4d3 4c8be2 mov r12,rdx