FASTFAT assertion

NTFSD
1

I sometimes get the next assertion hit:
*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Here’s the stack trace:
f57d84c4 804af2e5 81640a08 c03864ac f57d8504 nt!DbgBreakPoint
f57d87a0 bfe70f9c bfe70f02 bfe70eda 000007c2 nt!RtlAssert+0x9a
f57d87c0 bfe721ea 81640a08 81640a08 f57d8828
Fastfat!FatDeleteIrpContext_Real+0x28
f57d87d0 bfe8e38f 81640a08 a7c2fe70 c0000029
Fastfat!FatCompleteRequest_Real+0x38
f57d8828 bfe6eb1e 81640a08 a7c2fe70 c0000029
Fastfat!FatProcessException+0x346
f57d8870 80424968 81833020 a7c2fe70 000000c9 Fastfat!FatFsdCreate+0xa0
f57d8888 80607cdd 818338c0 a7c2fe70 00000000 nt!IopfCallDriver+0x4f
f57d88a4 eb28d79f a7c2fe70 c0000120 81833978 nt!IovCallDriver+0x77
f57d88cc eb28d3dd a7c2fe70 eb28ee00 81833978
Vba32dNT!CFilterDeviceExtension::OnCreate+0xcf
[r:\projects@vba4\monitor\fsffilter\filtdev.h @ 70]
f57d88e0 eb28c229 818338c0 a7c2fe70 81833978
Vba32dNT!CFilterDeviceExtension::_DispatchHandler+0x4d
[r:\projects@vba4\monitor\fsffilter\filtdev.h @ 34]
f57d88f4 80424968 818338c0 a7c2fe70 a7c2fe80
Vba32dNT!CDriver::_DispatchHandler+0x29
[r:\projects@vba4\monitor\fsffilter\template\driver.h @ 68]
f57d890c 8054f0b9 8054e667 81875020 80063400 nt!IopfCallDriver+0x4f
f57d8a8c 804a238a 81875038 00000000 f57d8b3c nt!IopParseDevice+0xa52
f57d8afc 80579ec9 00000000 f57d8bf8 00000040 nt!ObpLookupObjectName+0x5f8
f57d8c0c 8051e36f 00000000 00000000 77bfd701 nt!ObOpenObjectByName+0x119
f57d8ce0 8052a4d1 01d4d8b4 80100080 01d4d850 nt!IoCreateFile+0x425
f57d8d24 804be60a 01d4d8b4 80100080 01d4d850 nt!NtCreateFile+0x61
f57d8d24 77f7880b 01d4d8b4 80100080 01d4d850 nt!KiSystemService+0x10a
01d4d810 77e6ecab 01d4d8b4 80100080 01d4d850 ntdll!ZwCreateFile+0xb
01d4d8ac 77bfd7bc 00000000 80000000 00000003 kernel32!CreateFileW+0x343

Can anyone shed some light to the problem?

-htfv

2

Do you have a completion routine? If so, in your completion routine, do you
call back into FAT to query results about the file? If so, do you preserve
the contents of the TopLevelIrp field across that call?

For example, you could do this by doing the following:

oldTopLevelIrp = IoGetTopLevelIrp();
IoSetTopLevelIrp(NULL);
IoCallDriver(Fat, Irp);
// handle async completion here
IoSetTopLevelIrp(oldTopLevelIrp);

While this isn’t necessarily the CAUSE of this problem, it would certainly
be one standard problem in this area.

The assert is telling you that the IrpContext passed into
FatProcessException is invalid. This is a manifestation of a memory
corruption of some sort. One possibility here is that if you re-entered FAT
with the top level IRP field set, it might re-use the IRP (although, I must
admit, my quick glance at the code doesn’t support this theory.) The OTHER
big question here is why there’s an exception in the first place. Is it
possible that you are generating an exception in your filter that is being
caught by FAT? Do you protect against assertions in your code with a
__try/__except block around them so you can at least debug such problems?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Wednesday, September 04, 2002 11:12 AM
To: File Systems Developers
Subject: [ntfsd] FASTFAT assertion

I sometimes get the next assertion hit:
*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Here’s the stack trace:
f57d84c4 804af2e5 81640a08 c03864ac f57d8504 nt!DbgBreakPoint
f57d87a0 bfe70f9c bfe70f02 bfe70eda 000007c2 nt!RtlAssert+0x9a
f57d87c0 bfe721ea 81640a08 81640a08 f57d8828
Fastfat!FatDeleteIrpContext_Real+0x28
f57d87d0 bfe8e38f 81640a08 a7c2fe70 c0000029
Fastfat!FatCompleteRequest_Real+0x38
f57d8828 bfe6eb1e 81640a08 a7c2fe70 c0000029
Fastfat!FatProcessException+0x346
f57d8870 80424968 81833020 a7c2fe70 000000c9 Fastfat!FatFsdCreate+0xa0
f57d8888 80607cdd 818338c0 a7c2fe70 00000000 nt!IopfCallDriver+0x4f
f57d88a4 eb28d79f a7c2fe70 c0000120 81833978 nt!IovCallDriver+0x77
f57d88cc eb28d3dd a7c2fe70 eb28ee00 81833978
Vba32dNT!CFilterDeviceExtension::OnCreate+0xcf
[r:\projects@vba4\monitor\fsffilter\filtdev.h @ 70]
f57d88e0 eb28c229 818338c0 a7c2fe70 81833978
Vba32dNT!CFilterDeviceExtension::_DispatchHandler+0x4d
[r:\projects@vba4\monitor\fsffilter\filtdev.h @ 34]
f57d88f4 80424968 818338c0 a7c2fe70 a7c2fe80
Vba32dNT!CDriver::_DispatchHandler+0x29
[r:\projects@vba4\monitor\fsffilter\template\driver.h @ 68]
f57d890c 8054f0b9 8054e667 81875020 80063400 nt!IopfCallDriver+0x4f
f57d8a8c 804a238a 81875038 00000000 f57d8b3c nt!IopParseDevice+0xa52
f57d8afc 80579ec9 00000000 f57d8bf8 00000040 nt!ObpLookupObjectName+0x5f8
f57d8c0c 8051e36f 00000000 00000000 77bfd701 nt!ObOpenObjectByName+0x119
f57d8ce0 8052a4d1 01d4d8b4 80100080 01d4d850 nt!IoCreateFile+0x425
f57d8d24 804be60a 01d4d8b4 80100080 01d4d850 nt!NtCreateFile+0x61
f57d8d24 77f7880b 01d4d8b4 80100080 01d4d850 nt!KiSystemService+0x10a
01d4d810 77e6ecab 01d4d8b4 80100080 01d4d850 ntdll!ZwCreateFile+0xb
01d4d8ac 77bfd7bc 00000000 80000000 00000003 kernel32!CreateFileW+0x343

Can anyone shed some light to the problem?

-htfv

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

3

Alexey:

you will notice that the completion of the IRP_MJ_CREATE in this case is
called as a result of a abnormal termination, i.e
either FatCreateIrpContext() , either FatCommonCreate raised an exception.
Now, fat filter driver builds a special
structure, called IRP_STRUCTURE in which it stores all required data to
carry out IO from the original IRP , as well
as some goodies. The structure is validated through a magic,
FAT_NTC_IRP_CONTEXT, which is stored in IrpContext.NodeType.

At IO completion time, this memory used by this structure is returned to
system pools. Prior doing this , the node type is
checked. if the node tpye aint FAT_NTC_IRP_CONTEXT, then most likely somone
trased the IrpContext struct, or
the pointer is invalid.

Now, it’s hard to exactly tell what is going on there, but if you findd the
cause why and who FatCreateIrpContext() , or FatCommonCreate() raises , it
will be easy to pinpoint the mistake in your filter. Most likely you modify
the IRP in a bad way,
but noon can tell for sure. just start by pinpointing the exact portion of
code which raised the exception.

Ciao, Dan

----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Wednesday, September 04, 2002 6:12 PM
Subject: [ntfsd] FASTFAT assertion

> I sometimes get the next assertion hit:
> Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
> Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986
>
> Here’s the stack trace:
> f57d84c4 804af2e5 81640a08 c03864ac f57d8504 nt!DbgBreakPoint
> f57d87a0 bfe70f9c bfe70f02 bfe70eda 000007c2 nt!RtlAssert+0x9a
> f57d87c0 bfe721ea 81640a08 81640a08 f57d8828
> Fastfat!FatDeleteIrpContext_Real+0x28
> f57d87d0 bfe8e38f 81640a08 a7c2fe70 c0000029
> Fastfat!FatCompleteRequest_Real+0x38
> f57d8828 bfe6eb1e 81640a08 a7c2fe70 c0000029
> Fastfat!FatProcessException+0x346
> f57d8870 80424968 81833020 a7c2fe70 000000c9 Fastfat!FatFsdCreate+0xa0
> f57d8888 80607cdd 818338c0 a7c2fe70 00000000 nt!IopfCallDriver+0x4f
> f57d88a4 eb28d79f a7c2fe70 c0000120 81833978 nt!IovCallDriver+0x77
> f57d88cc eb28d3dd a7c2fe70 eb28ee00 81833978
> Vba32dNT!CFilterDeviceExtension::OnCreate+0xcf
> [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 70]
> f57d88e0 eb28c229 818338c0 a7c2fe70 81833978
> Vba32dNT!CFilterDeviceExtension::_DispatchHandler+0x4d
> [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 34]
> f57d88f4 80424968 818338c0 a7c2fe70 a7c2fe80
> Vba32dNT!CDriver::_DispatchHandler+0x29
> [r:\projects@vba4\monitor\fsffilter\template\driver.h @ 68]
> f57d890c 8054f0b9 8054e667 81875020 80063400 nt!IopfCallDriver+0x4f
> f57d8a8c 804a238a 81875038 00000000 f57d8b3c nt!IopParseDevice+0xa52
> f57d8afc 80579ec9 00000000 f57d8bf8 00000040 nt!ObpLookupObjectName+0x5f8
> f57d8c0c 8051e36f 00000000 00000000 77bfd701 nt!ObOpenObjectByName+0x119
> f57d8ce0 8052a4d1 01d4d8b4 80100080 01d4d850 nt!IoCreateFile+0x425
> f57d8d24 804be60a 01d4d8b4 80100080 01d4d850 nt!NtCreateFile+0x61
> f57d8d24 77f7880b 01d4d8b4 80100080 01d4d850 nt!KiSystemService+0x10a
> 01d4d810 77e6ecab 01d4d8b4 80100080 01d4d850 ntdll!ZwCreateFile+0xb
> 01d4d8ac 77bfd7bc 00000000 80000000 00000003 kernel32!CreateFileW+0x343
>
> Can anyone shed some light to the problem?
>
> -htfv
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

4

I don’t touch IRP. Well, except of calling
IoCopyCurrentIrpStackLocationToNext, IoSetCompletionRoutine,
IoMarkIrpPending but that’s common, isn’t it? I do some processing when
IRP_MJ_CREATE goes down and on it’s completion so that’s probably a problem.
But the only problem I can imagine – I touch wrong memory. On the other
hand Driver Verifier can reveal such problems very often but it’s silent.

-htfv

----- Original Message -----
From: “Dan Partelly”
To: “File Systems Developers”
Sent: Wednesday, September 04, 2002 6:44 PM
Subject: [ntfsd] Re: FASTFAT assertion

> Alexey:
>
> you will notice that the completion of the IRP_MJ_CREATE in this case is
> called as a result of a abnormal termination, i.e
> either FatCreateIrpContext() , either FatCommonCreate raised an exception.
> Now, fat filter driver builds a special
> structure, called IRP_STRUCTURE in which it stores all required data to
> carry out IO from the original IRP , as well
> as some goodies. The structure is validated through a magic,
> FAT_NTC_IRP_CONTEXT, which is stored in IrpContext.NodeType.
>
> At IO completion time, this memory used by this structure is returned to
> system pools. Prior doing this , the node type is
> checked. if the node tpye aint FAT_NTC_IRP_CONTEXT, then most likely
somone
> trased the IrpContext struct, or
> the pointer is invalid.
>
> Now, it’s hard to exactly tell what is going on there, but if you findd
the
> cause why and who FatCreateIrpContext() , or FatCommonCreate() raises , it
> will be easy to pinpoint the mistake in your filter. Most likely you
modify
> the IRP in a bad way,
> but noon can tell for sure. just start by pinpointing the exact portion of
> code which raised the exception.
>
> Ciao, Dan
>
>
>
> ----- Original Message -----
> From: “Alexey Logachyov”
> To: “File Systems Developers”
> Sent: Wednesday, September 04, 2002 6:12 PM
> Subject: [ntfsd] FASTFAT assertion
>
>
> > I sometimes get the next assertion hit:
> > Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
> > Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986
> >
> > Here’s the stack trace:
> > f57d84c4 804af2e5 81640a08 c03864ac f57d8504 nt!DbgBreakPoint
> > f57d87a0 bfe70f9c bfe70f02 bfe70eda 000007c2 nt!RtlAssert+0x9a
> > f57d87c0 bfe721ea 81640a08 81640a08 f57d8828
> > Fastfat!FatDeleteIrpContext_Real+0x28
> > f57d87d0 bfe8e38f 81640a08 a7c2fe70 c0000029
> > Fastfat!FatCompleteRequest_Real+0x38
> > f57d8828 bfe6eb1e 81640a08 a7c2fe70 c0000029
> > Fastfat!FatProcessException+0x346
> > f57d8870 80424968 81833020 a7c2fe70 000000c9 Fastfat!FatFsdCreate+0xa0
> > f57d8888 80607cdd 818338c0 a7c2fe70 00000000 nt!IopfCallDriver+0x4f
> > f57d88a4 eb28d79f a7c2fe70 c0000120 81833978 nt!IovCallDriver+0x77
> > f57d88cc eb28d3dd a7c2fe70 eb28ee00 81833978
> > Vba32dNT!CFilterDeviceExtension::OnCreate+0xcf
> > [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 70]
> > f57d88e0 eb28c229 818338c0 a7c2fe70 81833978
> > Vba32dNT!CFilterDeviceExtension::_DispatchHandler+0x4d
> > [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 34]
> > f57d88f4 80424968 818338c0 a7c2fe70 a7c2fe80
> > Vba32dNT!CDriver::_DispatchHandler+0x29
> > [r:\projects@vba4\monitor\fsffilter\template\driver.h @ 68]
> > f57d890c 8054f0b9 8054e667 81875020 80063400 nt!IopfCallDriver+0x4f
> > f57d8a8c 804a238a 81875038 00000000 f57d8b3c nt!IopParseDevice+0xa52
> > f57d8afc 80579ec9 00000000 f57d8bf8 00000040
nt!ObpLookupObjectName+0x5f8
> > f57d8c0c 8051e36f 00000000 00000000 77bfd701 nt!ObOpenObjectByName+0x119
> > f57d8ce0 8052a4d1 01d4d8b4 80100080 01d4d850 nt!IoCreateFile+0x425
> > f57d8d24 804be60a 01d4d8b4 80100080 01d4d850 nt!NtCreateFile+0x61
> > f57d8d24 77f7880b 01d4d8b4 80100080 01d4d850 nt!KiSystemService+0x10a
> > 01d4d810 77e6ecab 01d4d8b4 80100080 01d4d850 ntdll!ZwCreateFile+0xb
> > 01d4d8ac 77bfd7bc 00000000 80000000 00000003 kernel32!CreateFileW+0x343
> >
> > Can anyone shed some light to the problem?
> >
> > -htfv
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>

5

I see. Well, the exception seems to be STATUS_INVALID_UNWIND_TARGET. Frankly
, I have no ideea when this is raised, nor do I know what exactly means, but
I have a feeling it has something to do with stack unwinding (smart, no ?
Like the name aint suggestive) in exception handlers. But I dont think this
will be very helpfull, since I think this is just a consequence of
processing the original exception.

You mention “some processing”. Whats this processing ?

Dan

----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Thursday, September 05, 2002 8:57 AM
Subject: [ntfsd] Re: FASTFAT assertion

> I don’t touch IRP. Well, except of calling
> IoCopyCurrentIrpStackLocationToNext, IoSetCompletionRoutine,
> IoMarkIrpPending but that’s common, isn’t it? I do some processing when
> IRP_MJ_CREATE goes down and on it’s completion so that’s probably a
problem.
> But the only problem I can imagine – I touch wrong memory. On the other
> hand Driver Verifier can reveal such problems very often but it’s silent.
>
> -htfv
>
> ----- Original Message -----
> From: “Dan Partelly”
> To: “File Systems Developers”
> Sent: Wednesday, September 04, 2002 6:44 PM
> Subject: [ntfsd] Re: FASTFAT assertion
>
>
> > Alexey:
> >
> > you will notice that the completion of the IRP_MJ_CREATE in this case is
> > called as a result of a abnormal termination, i.e
> > either FatCreateIrpContext() , either FatCommonCreate raised an
exception.
> > Now, fat filter driver builds a special
> > structure, called IRP_STRUCTURE in which it stores all required data to
> > carry out IO from the original IRP , as well
> > as some goodies. The structure is validated through a magic,
> > FAT_NTC_IRP_CONTEXT, which is stored in IrpContext.NodeType.
> >
> > At IO completion time, this memory used by this structure is returned to
> > system pools. Prior doing this , the node type is
> > checked. if the node tpye aint FAT_NTC_IRP_CONTEXT, then most likely
> somone
> > trased the IrpContext struct, or
> > the pointer is invalid.
> >
> > Now, it’s hard to exactly tell what is going on there, but if you findd
> the
> > cause why and who FatCreateIrpContext() , or FatCommonCreate() raises ,
it
> > will be easy to pinpoint the mistake in your filter. Most likely you
> modify
> > the IRP in a bad way,
> > but noon can tell for sure. just start by pinpointing the exact portion
of
> > code which raised the exception.
> >
> > Ciao, Dan
> >
> >
> >
> > ----- Original Message -----
> > From: “Alexey Logachyov”
> > To: “File Systems Developers”
> > Sent: Wednesday, September 04, 2002 6:12 PM
> > Subject: [ntfsd] FASTFAT assertion
> >
> >
> > > I sometimes get the next assertion hit:
> > > Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
> > > Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986
> > >
> > > Here’s the stack trace:
> > > f57d84c4 804af2e5 81640a08 c03864ac f57d8504 nt!DbgBreakPoint
> > > f57d87a0 bfe70f9c bfe70f02 bfe70eda 000007c2 nt!RtlAssert+0x9a
> > > f57d87c0 bfe721ea 81640a08 81640a08 f57d8828
> > > Fastfat!FatDeleteIrpContext_Real+0x28
> > > f57d87d0 bfe8e38f 81640a08 a7c2fe70 c0000029
> > > Fastfat!FatCompleteRequest_Real+0x38
> > > f57d8828 bfe6eb1e 81640a08 a7c2fe70 c0000029
> > > Fastfat!FatProcessException+0x346
> > > f57d8870 80424968 81833020 a7c2fe70 000000c9 Fastfat!FatFsdCreate+0xa0
> > > f57d8888 80607cdd 818338c0 a7c2fe70 00000000 nt!IopfCallDriver+0x4f
> > > f57d88a4 eb28d79f a7c2fe70 c0000120 81833978 nt!IovCallDriver+0x77
> > > f57d88cc eb28d3dd a7c2fe70 eb28ee00 81833978
> > > Vba32dNT!CFilterDeviceExtension::OnCreate+0xcf
> > > [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 70]
> > > f57d88e0 eb28c229 818338c0 a7c2fe70 81833978
> > > Vba32dNT!CFilterDeviceExtension::_DispatchHandler+0x4d
> > > [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 34]
> > > f57d88f4 80424968 818338c0 a7c2fe70 a7c2fe80
> > > Vba32dNT!CDriver::_DispatchHandler+0x29
> > > [r:\projects@vba4\monitor\fsffilter\template\driver.h @ 68]
> > > f57d890c 8054f0b9 8054e667 81875020 80063400 nt!IopfCallDriver+0x4f
> > > f57d8a8c 804a238a 81875038 00000000 f57d8b3c nt!IopParseDevice+0xa52
> > > f57d8afc 80579ec9 00000000 f57d8bf8 00000040
> nt!ObpLookupObjectName+0x5f8
> > > f57d8c0c 8051e36f 00000000 00000000 77bfd701
nt!ObOpenObjectByName+0x119
> > > f57d8ce0 8052a4d1 01d4d8b4 80100080 01d4d850 nt!IoCreateFile+0x425
> > > f57d8d24 804be60a 01d4d8b4 80100080 01d4d850 nt!NtCreateFile+0x61
> > > f57d8d24 77f7880b 01d4d8b4 80100080 01d4d850 nt!KiSystemService+0x10a
> > > 01d4d810 77e6ecab 01d4d8b4 80100080 01d4d850 ntdll!ZwCreateFile+0xb
> > > 01d4d8ac 77bfd7bc 00000000 80000000 00000003
kernel32!CreateFileW+0x343
> > >
> > > Can anyone shed some light to the problem?
> > >
> > > -htfv
> > >
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

6

I found the problem. Some of my internal structures where not guarded by any
synchronizing objects. So, under on some heavy conditions those were teared
down.

Anyway, thanks for your help.

-htfv

----- Original Message -----
From: “Dan Partelly”
To: “File Systems Developers”
Sent: Thursday, September 05, 2002 2:18 PM
Subject: [ntfsd] Re: FASTFAT assertion

> I see. Well, the exception seems to be STATUS_INVALID_UNWIND_TARGET.
Frankly
> , I have no ideea when this is raised, nor do I know what exactly means,
but
> I have a feeling it has something to do with stack unwinding (smart, no ?
> Like the name aint suggestive) in exception handlers. But I dont think
this
> will be very helpfull, since I think this is just a consequence of
> processing the original exception.
>
> You mention “some processing”. Whats this processing ?
>
> Dan
>
> ----- Original Message -----
> From: “Alexey Logachyov”
> To: “File Systems Developers”
> Sent: Thursday, September 05, 2002 8:57 AM
> Subject: [ntfsd] Re: FASTFAT assertion
>
>
> > I don’t touch IRP. Well, except of calling
> > IoCopyCurrentIrpStackLocationToNext, IoSetCompletionRoutine,
> > IoMarkIrpPending but that’s common, isn’t it? I do some processing when
> > IRP_MJ_CREATE goes down and on it’s completion so that’s probably a
> problem.
> > But the only problem I can imagine – I touch wrong memory. On the other
> > hand Driver Verifier can reveal such problems very often but it’s
silent.
> >
> > -htfv
> >
> > ----- Original Message -----
> > From: “Dan Partelly”
> > To: “File Systems Developers”
> > Sent: Wednesday, September 04, 2002 6:44 PM
> > Subject: [ntfsd] Re: FASTFAT assertion
> >
> >
> > > Alexey:
> > >
> > > you will notice that the completion of the IRP_MJ_CREATE in this case
is
> > > called as a result of a abnormal termination, i.e
> > > either FatCreateIrpContext() , either FatCommonCreate raised an
> exception.
> > > Now, fat filter driver builds a special
> > > structure, called IRP_STRUCTURE in which it stores all required data
to
> > > carry out IO from the original IRP , as well
> > > as some goodies. The structure is validated through a magic,
> > > FAT_NTC_IRP_CONTEXT, which is stored in IrpContext.NodeType.
> > >
> > > At IO completion time, this memory used by this structure is returned
to
> > > system pools. Prior doing this , the node type is
> > > checked. if the node tpye aint FAT_NTC_IRP_CONTEXT, then most likely
> > somone
> > > trased the IrpContext struct, or
> > > the pointer is invalid.
> > >
> > > Now, it’s hard to exactly tell what is going on there, but if you
findd
> > the
> > > cause why and who FatCreateIrpContext() , or FatCommonCreate() raises
,
> it
> > > will be easy to pinpoint the mistake in your filter. Most likely you
> > modify
> > > the IRP in a bad way,
> > > but noon can tell for sure. just start by pinpointing the exact
portion
> of
> > > code which raised the exception.
> > >
> > > Ciao, Dan
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: “Alexey Logachyov”
> > > To: “File Systems Developers”
> > > Sent: Wednesday, September 04, 2002 6:12 PM
> > > Subject: [ntfsd] FASTFAT assertion
> > >
> > >
> > > > I sometimes get the next assertion hit:
> > > > Assertion failed: IrpContext->NodeTypeCode ==
FAT_NTC_IRP_CONTEXT
> > > > Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986
> > > >
> > > > Here’s the stack trace:
> > > > f57d84c4 804af2e5 81640a08 c03864ac f57d8504 nt!DbgBreakPoint
> > > > f57d87a0 bfe70f9c bfe70f02 bfe70eda 000007c2 nt!RtlAssert+0x9a
> > > > f57d87c0 bfe721ea 81640a08 81640a08 f57d8828
> > > > Fastfat!FatDeleteIrpContext_Real+0x28
> > > > f57d87d0 bfe8e38f 81640a08 a7c2fe70 c0000029
> > > > Fastfat!FatCompleteRequest_Real+0x38
> > > > f57d8828 bfe6eb1e 81640a08 a7c2fe70 c0000029
> > > > Fastfat!FatProcessException+0x346
> > > > f57d8870 80424968 81833020 a7c2fe70 000000c9
Fastfat!FatFsdCreate+0xa0
> > > > f57d8888 80607cdd 818338c0 a7c2fe70 00000000 nt!IopfCallDriver+0x4f
> > > > f57d88a4 eb28d79f a7c2fe70 c0000120 81833978 nt!IovCallDriver+0x77
> > > > f57d88cc eb28d3dd a7c2fe70 eb28ee00 81833978
> > > > Vba32dNT!CFilterDeviceExtension::OnCreate+0xcf
> > > > [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 70]
> > > > f57d88e0 eb28c229 818338c0 a7c2fe70 81833978
> > > > Vba32dNT!CFilterDeviceExtension::_DispatchHandler+0x4d
> > > > [r:\projects@vba4\monitor\fsffilter\filtdev.h @ 34]
> > > > f57d88f4 80424968 818338c0 a7c2fe70 a7c2fe80
> > > > Vba32dNT!CDriver::_DispatchHandler+0x29
> > > > [r:\projects@vba4\monitor\fsffilter\template\driver.h @ 68]
> > > > f57d890c 8054f0b9 8054e667 81875020 80063400 nt!IopfCallDriver+0x4f
> > > > f57d8a8c 804a238a 81875038 00000000 f57d8b3c nt!IopParseDevice+0xa52
> > > > f57d8afc 80579ec9 00000000 f57d8bf8 00000040
> > nt!ObpLookupObjectName+0x5f8
> > > > f57d8c0c 8051e36f 00000000 00000000 77bfd701
> nt!ObOpenObjectByName+0x119
> > > > f57d8ce0 8052a4d1 01d4d8b4 80100080 01d4d850 nt!IoCreateFile+0x425
> > > > f57d8d24 804be60a 01d4d8b4 80100080 01d4d850 nt!NtCreateFile+0x61
> > > > f57d8d24 77f7880b 01d4d8b4 80100080 01d4d850
nt!KiSystemService+0x10a
> > > > 01d4d810 77e6ecab 01d4d8b4 80100080 01d4d850 ntdll!ZwCreateFile+0xb
> > > > 01d4d8ac 77bfd7bc 00000000 80000000 00000003
> kernel32!CreateFileW+0x343
> > > >
> > > > Can anyone shed some light to the problem?
> > > >
> > > > -htfv
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> > > > To unsubscribe send a blank email to %%email.unsub%%
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>