BSOD at Kei386EoiHelper,

NTFSD
1

Hi,

Few senior person might have guessed it yesterday only, while helping me on my last post. So my code to send a rename IRP to NTFS start working and I got my first BSOD too. from call stack it seems that it fails at nt!Kei386EoiHelper (I know, my code is culprit),

In another post, Anton Bassov said that “this is invoked upon returning from interrupt”. So does it mean that I forget to set something which is required by this function while returning from an interrupt? If yes than kindly suggest what it could possibly be?

following is the output from WinDbg

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00190292
Arg2: f81f2704
Arg3: f81f2400
Arg4: 804e8ec8

Debugging Details:

EXCEPTION_RECORD: f81f2704 – (.exr fffffffff81f2704)
ExceptionAddress: 804e8ec8 (nt!IoIsOperationSynchronous+0x0000000e)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 656e6f7a
Attempt to read from address 656e6f7a

CONTEXT: f81f2400 – (.cxr fffffffff81f2400)
eax=81c76a00 ebx=81c76a00 ecx=656e6f4e edx=81c76a00 esi=f81f27e8 edi=00000000
eip=804e8ec8 esp=f81f27cc ebp=f81f27cc iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!IoIsOperationSynchronous+0xe:
804e8ec8 f6412c02 test byte ptr [ecx+2Ch],2 ds:0023:656e6f7a=??
Resetting default scope

PROCESS_NAME: CallingApp.exe (This process sends a IOCTL to driver)

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

READ_ADDRESS: 656e6f7a

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: STRING_DEREFERENCE

LAST_CONTROL_TRANSFER: from f83a9a9e to 804e8ec8

STACK_TEXT:
f81f27cc f83a9a9e 81c76a00 f81f2818 81ce6bc8 nt!IoIsOperationSynchronous+0xe
f81f2834 804e3d77 823e4770 81c76a00 822aa7e8 Ntfs!NtfsFsdSetInformation+0x47
f81f2844 f5b22cab 0dac366f 81ce6bc8 822aa7e8 nt!IopfCallDriver+0x31
f81f28fc f5b213b5 00000000 8203bd10 00000000 MyDriver!MyZwRenameFile+0x38b [d:\vss\stealthviewer\stealthdrv\stealth.c @ 1698]
f81f2c24 f5b21d71 821d8638 c00000ef f81f2c58 MyDriver!DeviceDispatcher+0x545 [d:\vss\stealthviewer\stealthdrv\stealth.c @ 704]
f81f2c34 804e3d77 81d34b60 821d8638 806ee2d0 MyDriver!DriverDispatcher+0x21 [d:\vss\stealthviewer\stealthdrv\stealth.c @ 1062]
f81f2c44 8056a9ab 821d86a8 81fa5288 821d8638 nt!IopfCallDriver+0x31
f81f2c58 8057d9f7 81d34b60 821d8638 81fa5288 nt!IopSynchronousServiceTail+0x60
f81f2d00 8057fbfa 000000f0 00000000 00000000 nt!IopXxxControlFile+0x611
f81f2d34 804df06b 000000f0 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f81f2d34 7c90eb94 000000f0 00000000 00000000 nt!KiFastCallEntry+0xf8
00f7fe68 7c90d8ef 7c801671 000000f0 00000000 ntdll!KiFastSystemCallRet
00f7fe6c 7c801671 000000f0 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
00f7fecc 1000f36b 000000f0 0022e090 00f7ff58 kernel32!DeviceIoControl+0xdd
00f7ff90 10033114 00000000 10058b3c 00f7ffec

FOLLOWUP_IP:
Ntfs!NtfsFsdSetInformation+47
f83a9a9e 50 push eax

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: Ntfs!NtfsFsdSetInformation+47

kd> kb

ChildEBP RetAddr Args to Child
f81f1da8 805328e7 00000003 f81f2104 00000000 nt!RtlpBreakWithStatusInstruction
f81f1df4 805333be 00000003 c0000005 00000000 nt!KiBugCheckDebugBreak+0x19
f81f21d4 805339ae 00000024 00190292 f81f2704 nt!KeBugCheck2+0x574
f81f21f4 f83b4051 00000024 00190292 f81f2704 nt!KeBugCheckEx+0x1b
f81f2224 f83ad2a2 00000000 f81f2250 804e2b52 Ntfs!NtfsExceptionFilter+0x1cd
f81f2230 804e2b52 f81f2258 00000000 f81f2258 Ntfs!NtfsFsdSetInformation+0xc1
f81f2258 804db9fd f81f2704 f81f2824 f81f2400 nt!_except_handler3+0x61
f81f227c 804db9ca f81f2704 f81f2824 f81f2400 nt!ExecuteHandler2+0x26
f81f232c 8050c72e f81f2704 f81f2400 656e6f7a nt!ExecuteHandler+0x24
f81f26e8 804dfada f81f2704 00000000 f81f2758 nt!KiDispatchException+0x13e
f81f2750 804dfa86 f81f27cc 804e8ec8 badb0d00 nt!CommonDispatchException+0x4d
f81f2774 f8a509aa f8a50d20 f81f27af 00000000 nt!Kei386EoiHelper+0x18a
f81f27cc f83a9a9e 81c76a00 f81f2818 81ce6bc8 kdcom!KdCompPollByte+0x10
f81f27cc f83a9a9e 81c76a00 f81f2818 81ce6bc8 Ntfs!NtfsFsdSetInformation+0x47
f81f2834 804e3d77 823e4770 81c76a00 822aa7e8 Ntfs!NtfsFsdSetInformation+0x47
f81f2844 f5b22cab 0dac366f 81ce6bc8 822aa7e8 nt!IopfCallDriver+0x31
f81f28fc f5b213b5 00000000 8203bd10 00000000 MyDriver!MyZwRenameFile+0x38b [d:\vss\stealthviewer\stealthdrv\stealth.c @ 1698]
f81f2c24 f5b21d71 821d8638 c00000ef f81f2c58 MyDriver!DeviceDispatcher+0x545 [d:\vss\stealthviewer\stealthdrv\stealth.c @ 704]
f81f2c34 804e3d77 81d34b60 821d8638 806ee2d0 MyDriver!DriverDispatcher+0x21 [d:\vss\stealthviewer\stealthdrv\stealth.c @ 1062]
f81f2c44 8056a9ab 821d86a8 81fa5288 821d8638 nt!IopfCallDriver+0x31

In case its not that straight, Please provide some pointers to investigate.

Thanks
Aditya

2

As per WinDbg an exception occurred at IoIsOperationSynchronous while reading some address. from KB output Kei386EoiHelper comes just before CommonDispatchException call.

3

you cannot use kb, while you got an exception - you have to use .cxr command
to find out where was the exception (as !analyze wrote you! look at the dump
once again)
why don’t you debug IoIsOperationSynchronous function and try to find it out
bu yourself? (“u nt!IoIsOperationSynchronous”)

nt!IoIsOperationSynchronous:
804ee54e 8bff mov edi,edi
804ee550 55 push ebp
804ee551 8bec mov ebp,esp
804ee553 8b4508 mov eax,dword ptr [ebp+8]
804ee556 8b4860 mov ecx,dword ptr [eax+60h]
804ee559 8b4918 mov ecx,dword ptr [ecx+18h]
804ee55c f6412c02 test byte ptr [ecx+2Ch],2
804ee560 7506 jne nt!IoIsOperationSynchronous+0x1a (804ee568)

It looks like you have an invalid FileObject in IRP - ECX should contain
FileObject, but your ecx is “ecx=656e6f4e”. Is it a kernel pointer? No, it
looks like a text for me (“None”). ecx+2ch reads FileObject->Flags (see “dt
nt!_FILE_OBJECT”).

-pk

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 13. ledna 2009 8:19
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] BSOD at Kei386EoiHelper,

As per WinDbg an exception occurred at IoIsOperationSynchronous while
reading some address. from KB output Kei386EoiHelper comes just before
CommonDispatchException call.

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

4

I identified it,

I debug it and found that it was crashing inside Ntfs!NtfsCompleteRequest, i debug that and found that it is calling my completion routine and durin that I was freeing the IRP as it was allocated by me. and with that call it shows BSOD.

What we suppose to do with the irp allocated in following manner, isn’t it a memory leak, if I am not freeing it? or else does IO manager is taking care of it along with the memory allocated by me for SystemBuffer?

I am returning more_processing_required from my completion routine.

IrpSize = IoSizeOfIrp( pNtfsDevice->StackSize );
Irp = ExAllocatePool(NonPagedPool, IrpSize);

if (Irp == NULL)
leave;

IoInitializeIrp(Irp, IrpSize, pNtfsDevice->StackSize+1);

Thanks
Aditya

5

@Petr Kurtin

Thanks for the suggestion, I debugged this function and found that it is not crashing the system, but it actually crash after some time in a call to NtfsCompleteRequest. I commented freeing the Irp from my completion routine and it works (File name changed), but after some minutes it crashed again with following info.

DRIVER_CORRUPTED_EXPOOL (c5)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is
caused by drivers that have corrupted the system pool. Run the driver
verifier against any new (or suspect) drivers, and if that doesn’t turn up
the culprit, then use gflags to enable special pool.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 8054b907, address which referenced memory

Debugging Details:

BUGCHECK_STR: 0xC5_2

CURRENT_IRQL: 2

FAULTING_IP:
nt!ExDeferredFreePool+156
8054b907 8913 mov dword ptr [ebx],edx

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: cctray.exe

TRAP_FRAME: f6106ae4 – (.trap fffffffff6106ae4)
ErrCode = 00000002
eax=81c9d1e8 ebx=00000000 ecx=81c9d180 edx=82374020 esi=80562040 edi=000001ff
eip=8054b907 esp=f6106b58 ebp=f6106b98 iopl=0 nv up ei ng nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297
nt!ExDeferredFreePool+0x156:
8054b907 8913 mov dword ptr [ebx],edx ds:0023:00000000=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
f6106698 805328e7 00000003 f61069f4 00000000 nt!RtlpBreakWithStatusInstruction
f61066e4 805333be 00000003 00000000 8054b907 nt!KiBugCheckDebugBreak+0x19
f6106ac4 804e2158 0000000a 00000000 00000002 nt!KeBugCheck2+0x574
f6106ac4 8054b907 0000000a 00000000 00000002 nt!KiTrap0E+0x233
f6106b98 8054ba1e 81c6fc00 02d084c8 00000000 nt!ExDeferredFreePool+0x156
f6106bd8 f68bbdf6 81cbf6d0 00000000 f68c2f02 nt!ExFreePoolWithTag+0x489
WARNING: Stack unwind information not available. Following frames may be wrong.
f6106c3c f68c365f e2d646f0 00000001 00001017 KmxSbx+0x2df6
f6106c7c 80610983 00000000 00000008 f6106ccc KmxSbx+0xa65f
f6106cb0 80609a3e 00000008 f6106ccc f6106d64 nt!CmpCallCallBacks+0x50
f6106d44 804df06b 00000390 0167988c 00000002 nt!NtQueryValueKey+0x2ac
f6106d44 7c90eb94 00000390 0167988c 00000002 nt!KiFastCallEntry+0xf8
01679770 7c90e20a 77dd6edc 00000390 0167988c ntdll!KiFastSystemCallRet
01679774 77dd6edc 00000390 0167988c 00000002 ntdll!NtQueryValueKey+0xc
01679860 77dd7054 00000390 0167988c 016798b0 ADVAPI32!LocalBaseRegQueryValue+0x17a
01679898 02cf632a 00000000 02d084c8 00000000 ADVAPI32!RegQueryValueExW+0xa2
01679b10 0058004b 00540057 00450053 00580043 calic!Ordinal27+0x757a
01679b14 00540057 00450053 00580043 005a0058 0x58004b
01679b18 00450053 00580043 005a0058 005a0043 0x540057
01679c18 7c910551 01d207d8 7c91056d 00000008 0x450053
01679ccc 01217414 024d11ad 00000090 00000000 ntdll!RtlFreeHeap+0x1e9
01679cdc 01d29454 01217414 024e939f 01217414 0x1217414
01679cf4 024f6960 00000000 00000043 024d162b msi!CMsiView::ParseSelectSQL+0xdd
01679cfc 00000000 024d162b 01d24b48 00000000 0x24f6960

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExDeferredFreePool+156
8054b907 8913 mov dword ptr [ebx],edx

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

SYMBOL_NAME: nt!ExDeferredFreePool+156

MODULE_NAME: Pool_Corruption

FAILURE_BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+156

BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+156

Followup: Pool_corruption

I guess it has everything to do with setting up proper completion and releasing memory? Any pointers?

Thanks
Aditya

6

> NTFS_FILE_SYSTEM (24)

If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.

Please do this as asked.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

> As per WinDbg an exception occurred at IoIsOperationSynchronous while reading some address.

This is usually if the IRP is submitted with NULL file object in a stack location for the function code which mandates the file object.

You can disassemble IoIsOperationSynchronous, it is very short and usually BSODs on a file object.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

8

> DRIVER_CORRUPTED_EXPOOL (c5)

Switch Verifier on, it can track many memory corruptions very early.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

9

I don’t know about your current code.

But after seeing your code in previous threads, following are my previous
observations:–

  1. you have a IoEvent on which you are waiting after issuing the
    IoCallDriver
  2. I suppose IoEvent storage is on the stack of thread which is calling
    IoCallDriver.
  3. The thread which is calling IoCallDriver is running at PASSIVE_LEVEL.

Now when your completion routine gets called, it will free the IRP and will
signal the event which is on stack of
your thread which was running in PASSIVE_LEVEL and waiting on a event.

Completion routines are called at the same IRQL at which lower device stack
has invoked completion.

So may be there are chances that your completion routine is running at
DISPATCH_LEVEL and you accessing IoEvent which is on stack of PASSIVE_LEVEL
thread. There are chances of swapping out of that thread’s stack becoz it is
waiting on a dispatcher object.

Now my suggestions.
What do you want to achieve by setting a completion routine.

If it is just for freeing the IRP, then better use
“IoBuildSynchronousFsdRequest”.
You can provide a pointer to an event on which you can wait (if return
status is pending) and I/O manager
takes the responsibility of freeing the IRP once it is completed.

Regards
Deepak

On Tue, Jan 13, 2009 at 3:14 PM, wrote:

> @Petr Kurtin
>
> Thanks for the suggestion, I debugged this function and found that it is
> not crashing the system, but it actually crash after some time in a call to
> NtfsCompleteRequest. I commented freeing the Irp from my completion routine
> and it works (File name changed), but after some minutes it crashed again
> with following info.
>
>
> DRIVER_CORRUPTED_EXPOOL (c5)
> An attempt was made to access a pageable (or completely invalid) address at
> an
> interrupt request level (IRQL) that is too high. This is
> caused by drivers that have corrupted the system pool. Run the driver
> verifier against any new (or suspect) drivers, and if that doesn’t turn up
> the culprit, then use gflags to enable special pool.
> Arguments:
> Arg1: 00000000, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000001, value 0 = read operation, 1 = write operation
> Arg4: 8054b907, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xC5_2
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!ExDeferredFreePool+156
> 8054b907 8913 mov dword ptr [ebx],edx
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> PROCESS_NAME: cctray.exe
>
> TRAP_FRAME: f6106ae4 – (.trap fffffffff6106ae4)
> ErrCode = 00000002
> eax=81c9d1e8 ebx=00000000 ecx=81c9d180 edx=82374020 esi=80562040
> edi=000001ff
> eip=8054b907 esp=f6106b58 ebp=f6106b98 iopl=0 nv up ei ng nz ac pe
> cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010297
> nt!ExDeferredFreePool+0x156:
> 8054b907 8913 mov dword ptr [ebx],edx
> ds:0023:00000000=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25
>
> STACK_TEXT:
> f6106698 805328e7 00000003 f61069f4 00000000
> nt!RtlpBreakWithStatusInstruction
> f61066e4 805333be 00000003 00000000 8054b907 nt!KiBugCheckDebugBreak+0x19
> f6106ac4 804e2158 0000000a 00000000 00000002 nt!KeBugCheck2+0x574
> f6106ac4 8054b907 0000000a 00000000 00000002 nt!KiTrap0E+0x233
> f6106b98 8054ba1e 81c6fc00 02d084c8 00000000 nt!ExDeferredFreePool+0x156
> f6106bd8 f68bbdf6 81cbf6d0 00000000 f68c2f02 nt!ExFreePoolWithTag+0x489
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f6106c3c f68c365f e2d646f0 00000001 00001017 KmxSbx+0x2df6
> f6106c7c 80610983 00000000 00000008 f6106ccc KmxSbx+0xa65f
> f6106cb0 80609a3e 00000008 f6106ccc f6106d64 nt!CmpCallCallBacks+0x50
> f6106d44 804df06b 00000390 0167988c 00000002 nt!NtQueryValueKey+0x2ac
> f6106d44 7c90eb94 00000390 0167988c 00000002 nt!KiFastCallEntry+0xf8
> 01679770 7c90e20a 77dd6edc 00000390 0167988c ntdll!KiFastSystemCallRet
> 01679774 77dd6edc 00000390 0167988c 00000002 ntdll!NtQueryValueKey+0xc
> 01679860 77dd7054 00000390 0167988c 016798b0
> ADVAPI32!LocalBaseRegQueryValue+0x17a
> 01679898 02cf632a 00000000 02d084c8 00000000 ADVAPI32!RegQueryValueExW+0xa2
> 01679b10 0058004b 00540057 00450053 00580043 calic!Ordinal27+0x757a
> 01679b14 00540057 00450053 00580043 005a0058 0x58004b
> 01679b18 00450053 00580043 005a0058 005a0043 0x540057
> 01679c18 7c910551 01d207d8 7c91056d 00000008 0x450053
> 01679ccc 01217414 024d11ad 00000090 00000000 ntdll!RtlFreeHeap+0x1e9
> 01679cdc 01d29454 01217414 024e939f 01217414 0x1217414
> 01679cf4 024f6960 00000000 00000043 024d162b
> msi!CMsiView::ParseSelectSQL+0xdd
> 01679cfc 00000000 024d162b 01d24b48 00000000 0x24f6960
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!ExDeferredFreePool+156
> 8054b907 8913 mov dword ptr [ebx],edx
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: Pool_corruption
>
> IMAGE_NAME: Pool_Corruption
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> SYMBOL_NAME: nt!ExDeferredFreePool+156
>
> MODULE_NAME: Pool_Corruption
>
> FAILURE_BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+156
>
> BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+156
>
> Followup: Pool_corruption
>
> I guess it has everything to do with setting up proper completion and
> releasing memory? Any pointers?
>
> Thanks
> Aditya
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

10

Here are some of my tips:

Arg1: 00000000, memory referenced

NULL pointer submission somewhere in your code. Check for that.

  1. Look at the documented IRP/FO fields, in the MSDN, and don’t be a hero
    trying to modify or touch other fields than those. This could lead to
    unforeseen consequences, and most hard to debug, because you’ll get the BSOD
    even after minutes after the corruption

  2. IoIsOperationSynchronous

In this case the I/O manger looks for conditions to determine if the FO was
opened for synch operations.
It looks at the file object specified in the IRP
It looks if this is an inherited operation, (e.g. : the create/open is
inherited synch flags)
The IRP flags suggest a synch operation (IRP_SYNCH_OPERATION,
IRP_SYNCH_PAGING_IO)

Conclusion: IRP members and FO flags should all be set correctly by IO
manager and you which takes you to my second tip ( 2) )

  1. Look at APC status , IRQL = ? Very important stuff for irp’s gone down
    the stack and a thread waiting for completion.

  2. To achieve all this document yourself some more, and read more articles,
    not just about rename ops.
    Your problem is not one that you are stuck in like a system wide deadlock,
    or something that need investigation from the community, and after a lot of
    debugging and crashes you decide to turn here.
    It is rather: “how do I rename a file in kernel mode using IRP’s ?”
    A proper answer will not be provided in 1000000000 replies because there is
    an entire architecture that you must take into account. Your question is
    actually superficial and simple, and of no substance, it’s the kind of
    question that needs all the src of the driver to be answered.
    You need to consider IRP dispatching, completion routines, pending / async
    operations, irql, apc, thread/process context, memory, flags, stack, page
    faults, locks, concurrence, etc. . . to write a proper driver code, no
    matter what it implements. It’s not just about filling an IRP and dump it
    for processing.

Sorry for a more though 5-th tip.

I wish you good luck.

With respect,
Gabriel Bercea

GaMiTech Software Development
Mobile contact: (+40)0740049634
eMail: xxxxx@gmail.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, January 13, 2009 11:35 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] BSOD at Kei386EoiHelper,

I identified it,

I debug it and found that it was crashing inside Ntfs!NtfsCompleteRequest, i
debug that and found that it is calling my completion routine and durin that
I was freeing the IRP as it was allocated by me. and with that call it shows
BSOD.

What we suppose to do with the irp allocated in following manner, isn’t it a
memory leak, if I am not freeing it? or else does IO manager is taking care
of it along with the memory allocated by me for SystemBuffer?

I am returning more_processing_required from my completion routine.

IrpSize = IoSizeOfIrp( pNtfsDevice->StackSize );
Irp = ExAllocatePool(NonPagedPool, IrpSize);

if (Irp == NULL)
leave;

IoInitializeIrp(Irp, IrpSize, pNtfsDevice->StackSize+1);

Thanks
Aditya

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

11

@Gabriel Bercea

I I Sir, will keep all this in mind. your 5th point is tough but true. Probably the hugemongus pressure on me is causing this. After few post I too realized that the post was already answered in either OSR or WDK Docs. My apologies for filling lots of inbox frequently.

@Deepak

Thanks for ur inputs,

What do you want to achieve by setting a completion routine.

I read WDK doc for IoCompleteRequest and it states that "Note that a higher-level driver that sets up a driver-created IRP must supply an IoCompletion routine to release the IRP it created. " So I create a completion routine,as my driver is creating this IRP.

If in case it is not true, i.e; there is no need to set a completion routine, will IO Manager take care of system buffer, I allocated non paged memory and assign it to system buffer.

I thought of using IoBuildSynchronousXXX but as per WDK docs it can take few major code and that list does not include IRP_MJ_SET_INFORMATION. Can we use it IoBuildSynchronousXXX for Set_info?

Thanks
Aditya

12

On Tue, Jan 13, 2009 at 4:37 PM, wrote:

> @Gabriel Bercea
>
> I I Sir, will keep all this in mind. your 5th point is tough but true.
> Probably the hugemongus pressure on me is causing this. After few post I too
> realized that the post was already answered in either OSR or WDK Docs. My
> apologies for filling lots of inbox frequently.
>
> @Deepak
>
> Thanks for ur inputs,
>
> What do you want to achieve by setting a completion routine.
>
> I read WDK doc for IoCompleteRequest and it states that "Note that a
> higher-level driver that sets up a driver-created IRP must supply an
> IoCompletion routine to release the IRP it created. " So I create a
> completion routine,as my driver is creating this IRP.
>

You need to do IoSetCompletionRoutine when you are building IRP using other
than IoBuildSynchronousXXX.

> If in case it is not true, i.e; there is no need to set a completion
> routine, will IO Manager take care of system buffer, I allocated non paged
> memory and assign it to system buffer.
>
> I thought of using IoBuildSynchronousXXX but as per WDK docs it can take
> few major code and that list does not include IRP_MJ_SET_INFORMATION. Can we
> use it IoBuildSynchronousXXX for Set_info?

You are right , as per the docs IoBuildSynchronousXXX won’t work for
IRP_MJ_SET_INFORMATION.

Ok, what is the storage of your event object on which your thread is
waiting.
Is it on thread’s stack or in NonPagedPool?
If it is on thread’s stack then read documentation of
“IoSetCompletionRoutine”

VOID
IoSetCompletionRoutine(
IN PIRP Irp,
IN PIO_COMPLETION_ROUTINE CompletionRoutine,
IN PVOID Context,
IN BOOLEAN InvokeOnSuccess,
IN BOOLEAN InvokeOnError,
IN BOOLEAN InvokeOnCancel
);

…

Context
Pointer to a driver-determined context to pass to the IoCompletion routine.
Context information must be stored in nonpaged memory, because the
IoCompletion routine is called at IRQL <= DISPATCH_LEVEL.

In your code, your context is an EVENT object. Is it on stack or from
NonPagefPool?

Regards
Deepak

>
>
> Thanks
> Aditya
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

13

@Deepak

You need to do IoSetCompletionRoutine when you are building IRP using other than IoBuildSynchronousXXX.

>I have to use something other, as I need it for set_information. Yes my Event is at stack, I’ll change it. Thanks for pointing it.

@Everyone

Its working, or probably it seems so at this point of time (till next crash). :slight_smile:

When I was using IoFreeIrp in my completion and calling IoCompleteRequest from my dispatch it BSODs. with some error states that an attempt to free some memory which is already freed (Thanks Maxim for reminding me of Verifier). I changed my code, not freeing IRP from completion and just calling IoCompleteRequest from dispatch. With this change it is working now.

I checked a lot in DDK and found that IoBuildSynchronousFsdRequest helps says that a driver must not call IoFreeIrp as it is frees by Io Manager. And no such claim is made by IoBuild async XXX function.

My requirement(Rename) was to use IoAllocateIrp or to initialize some memory and use IoInitializeIrp, now WDK help of these function does not state, what should we do with these irp once they are completed. If it documented in some other API please let me know.

I checked in wdk::filespy source and in fspylib.c found that it is Allocating an Irp for query_information using IoAllocateIrp (setting flag as synchronize_api), setting a completion routine, calling next driver, waiting on a event (at stack) in case of status pending. Completion routine at same .c file frees the irp using IoFreeIrp and returned more_processing_required. Its been mentioned in comments that later IoCompleteRequest will be called.

I tried similar thing (except for major code) in my driver and got a BSOD. So though my code is working currently, I am still curious to know the exact and correct procedure i.e. what a driver is supposed to do with the IRP at completion (sync and async).
If it is mentioned in some book or at some article; Please let me know, I’ll be grateful for this.

Thank you all for the patience and support,
Aditya

14

> I checked in wdk::filespy source and in fspylib.c found that it is Allocating an Irp for query_information

using IoAllocateIrp (setting flag as synchronize_api), setting a completion routine, calling next driver,
waiting on a event (at stack) in case of status pending. Completion routine at same .c file frees the irp
using IoFreeIrp and returned more_processing_required. Its been mentioned in comments that later
IoCompleteRequest will be called.

This is the usual way.

I tried similar thing (except for major code) in my driver and got a BSOD

What was the BSOD?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

15

It surly should crash, My error.

I was actually calling IoCompleteRequest on the freed IRP instead of the original one. Sure shot BSOD.

Now the code is modified to free all resources in completion with IRP itself and returning more processing required. And obviously not calling IoCompleteRequest on the freed IRP.

Thank you very much every one,
Aditya