Hi all,
Could anybody explain a cause of the BSOD?
The problem occurs in post procedure of IRP_MJ_DIRECTORY_CONTROL
(IRP_MN_QUERY_DIRECTORY).
My actions are the following:
-
I watch the following class informations:
FileBothDirectoryInformation, FileDirectoryInformation,
FileFullDirectoryInformation, FileIdBothDirectoryInformation,
FileIdFullDirectoryInformation.
-
On pre procedure I get pointer to the buffer with FltLockUserBuffer
and MmGetSystemAddressForMdlSafe.
-
Then on post procedure I try to open files (not directory) from
FILE_XXXX_INFORMATION. I use FltCreateFileEx.
On this calling I randomly get BSOD
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff800016e330e, The address that the exception occurred at
Arg3: fffff88001f41ec8, Exception Record Address
Arg4: fffff88001f41720, Context Record Address
This BSOD is very unpredictable and occurs on different files, it may
work normally a long time. Post procedure works on system thread on
PASSIVE_LEVEL.
Does anybody know the cause?
Thanks
Valery
What does the address point to? Is it the OBJECT_ATTRIBUTES or the name or what? A stack would be useful too (is it FltMgr that fails or NTFS or FAT or what)? What about verifier?
If an access fault is always at the same place, it’s easy to find and fix.
If it happens at random places, from random calls, it could be heap
corruption; use Driver Verifier with Special Pool enabled.
A common cause of widely separated failure is that you are passing an
address which is not valid, and some of the time it actually IS valid (by
accident) so you get away with it, but sometimes it gets mapped out or
overwritten and you get failure. So are you sure the address you are
passing is guaranteed, absolutely guaranteed, to be valid in the context
in which you are using it?
joe
Hi all,
Could anybody explain a cause of the BSOD?
The problem occurs in post procedure of IRP_MJ_DIRECTORY_CONTROL
(IRP_MN_QUERY_DIRECTORY).
My actions are the following:
-
I watch the following class informations:
FileBothDirectoryInformation, FileDirectoryInformation,
FileFullDirectoryInformation, FileIdBothDirectoryInformation,
FileIdFullDirectoryInformation.
-
On pre procedure I get pointer to the buffer with FltLockUserBuffer
and MmGetSystemAddressForMdlSafe.
-
Then on post procedure I try to open files (not directory) from
FILE_XXXX_INFORMATION. I use FltCreateFileEx.
On this calling I randomly get BSOD
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff800016e330e, The address that the exception occurred at
Arg3: fffff88001f41ec8, Exception Record Address
Arg4: fffff88001f41720, Context Record Address
This BSOD is very unpredictable and occurs on different files, it may
work normally a long time. Post procedure works on system thread on
PASSIVE_LEVEL.
Does anybody know the cause?
Thanks
Valery
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
You should type the following into the debugger:
.cxr fffff88001f41720 ; k
Where the numeric value is the fourth parameter to the bug check.
This will give you a stack trace of the system at the time of the exception and it should point to the issue (which will be an invalid buffer, since your exception code is 0xC0000005 or ?access violation?).
Tony
OSR
Rod, Joe and Tony,
Thank you very much for reply and sorry I did not provide full information.
There is stack:
STACK_TEXT:
fffff88001f42100 fffff880012d6658 : 0000000000000000 fffffa8000063870 0000000000003fdf fffff880012d672e :
nt!ExAcquireResourceSharedLite+0x4e
fffff88001f42170 fffff880012f4ef0 : fffffa8000063870 0000000000000008 fffff88001f422d8 0000000000000000 :
fltmgr!FltpGetNextCallbackNodeForInstance+0x48
fffff88001f421c0 fffff880012f53e1 : 00000000000002f8 fffffa8001e93680 fffffa8000063870 0000000000002f80 :
fltmgr!TargetedIOCtrlGenerateECP+0x160
fffff88001f42230 fffff88001304a21 : fffffa8001e93680 fffff88001f42870 fffff88001f42870 fffff88001f428e8 :
fltmgr!FltCreateFileEx2+0xd1
fffff88001f42340 fffff8800130f169 : fffffa8001e93680 fffffa8000063870 fffff88001f42870 fffff88001f428e8 :
fltmgr!FltCreateFileEx+0x91
fffff88001f423d0 fffff880069a39ba : 0000000000000000 0000000000000000 fffffa8001d9b626 0000000000000002 :
fltmgr!FltvCreateFileEx+0xd9
fffff88001f42470 fffff880069a8910 : fffff88001f428d0 fffff88001f428e8 fffff980068d8f70 fffff88001f42870 :
MyFileFlt!MyOpenFileByName+0x32a
fffff88001f426e0 fffff880069a11bf : fffffa8000063870 0000000000000000 fffff980068d8f70 0000000000000000 :
MyFileFlt!MyFileModifier::ReadData+0x1f0
fffff88001f428d0 fffff880069a13c7 : fffffa8001abc610 fffff88001f424a8 fffff9800225ef60 0000000000000000 :
MyFileFlt!MyPost_DirectoryControl_Execution+0x64f
fffff88001f42b00 fffff88001301ef3 : fffffa8001e25900 fffffa8001e592d0 fffff9800225ef60 0000000000010212 :
MyFileFlt!MyPostDirCtrlThreadWrapper+0xb7
fffff88001f42c70 fffff800016e6a21 : fffff88001301eb0 fffff80001879600 fffffa80006bf680 fffff88000000000 :
fltmgr!FltpProcessGenericWorkItem+0x43
fffff88001f42cb0 fffff80001979cce : 0000000000000000 fffffa80006bf680 0000000000000080 fffffa80006b1040 :
nt!ExpWorkerThread+0x111
fffff88001f42d40 fffff800016cdfe6 : fffff8000184ee80 fffffa80006bf680 fffffa80006bfb60 0000000000000000 :
nt!PspSystemThreadStartup+0x5a
fffff88001f42d80 0000000000000000 : fffff88001f43000 fffff88001f3d000 fffff88001f429e0 0000000000000000 :
nt!KxStartSystemThread+0x16
My explanations:
On Post procedure I create thread via FltQueueGenericWorkItem. I don’t
use FltQueueDeferredIoWorkItem, because there is limitation for Paging
IO, and I use the same technique for IRP_MJ_READ/WRITE. So, post
procedure starts thread MyPostDirCtrlThreadWrapper and returns
FLT_POSTOP_MORE_PROCESSING_REQUIRED. When thread completes, it calls
FltCompletePendedPostOperation.
Verifier is turned on with standard settings.
When I researched the dump, I noticed strange value of FLT_RELATED_OBJECTS:
kd> dt MyFileFlt!pFltObjects
Local var @ 0xfffff88001f42b08 Type _FLT_RELATED_OBJECTS*
0xfffff88001f424a8 +0x000 Size : 0 +0x002 TransactionContext : 0 +0x008 Filter : 0x0000000000000080 _FLT_FILTER
+0x010 Volume : 0x0000000000000001 _FLT_VOLUME +0x018 Instance : 0x0000000000000001 _FLT_INSTANCE
+0x020 FileObject : 0x00000000`00000040 _FILE_OBJECT
+0x028 Transaction : (null)
But when I called FltCreateFileEx, value of Instance was correct and
this address exists in the stack (see arguments: fffffa80`00063870).
Does it mean this structure was cleared outside, or this is just a bug
of WinDbg?
Thanks
Valery
It is still not obvious to me where all these datastructures are coming from but:
Assuming that this is from a checked build I’d say that the odd pFltObjects is your problem. Ignore the reported parameter on the stack, this is x64 and it is a different world (Scott posted an exellent reference to eactly this issue over in windbg earlier this week).
Are you sure that you are pinning (FltReferenceContext) all the structures that you are passing (directly or indirectly) on to the posted items. Without knowing the system I couldn’t say but ask yourself what would happen if the file was closed before your operation fired? What about a volume teardown?
You also don’t mention how you are getting hold of pFltObjects (which I assume you have shown from the scope of one of the functions on that stack)?
I assume that you allocate it in the pre-call, pass it to the post call (since it has to be called <=APC and you are worried about paging) and then hand it off to the posted function. You cannot (of course) just pass the parameter you get to the posted function.
“Valery Druba” wrote in message news:xxxxx@ntfsd…
Rod, Joe and Tony,
Thank you very much for reply and sorry I did not provide full information.
There is stack:
STACK_TEXT:
fffff88001f42100 fffff880012d6658 : 0000000000000000 fffffa8000063870 0000000000003fdf fffff880012d672e : nt!ExAcquireResourceSharedLite+0x4e
fffff88001f42170 fffff880012f4ef0 : fffffa8000063870 0000000000000008 fffff88001f422d8 0000000000000000 : fltmgr!FltpGetNextCallbackNodeForInstance+0x48
fffff88001f421c0 fffff880012f53e1 : 00000000000002f8 fffffa8001e93680 fffffa8000063870 0000000000002f80 : fltmgr!TargetedIOCtrlGenerateECP+0x160
fffff88001f42230 fffff88001304a21 : fffffa8001e93680 fffff88001f42870 fffff88001f42870 fffff88001f428e8 : fltmgr!FltCreateFileEx2+0xd1
fffff88001f42340 fffff8800130f169 : fffffa8001e93680 fffffa8000063870 fffff88001f42870 fffff88001f428e8 : fltmgr!FltCreateFileEx+0x91
fffff88001f423d0 fffff880069a39ba : 0000000000000000 0000000000000000 fffffa8001d9b626 0000000000000002 : fltmgr!FltvCreateFileEx+0xd9
fffff88001f42470 fffff880069a8910 : fffff88001f428d0 fffff88001f428e8 fffff980068d8f70 fffff88001f42870 : MyFileFlt!MyOpenFileByName+0x32a
fffff88001f426e0 fffff880069a11bf : fffffa8000063870 0000000000000000 fffff980068d8f70 0000000000000000 : MyFileFlt!MyFileModifier::ReadData+0x1f0
fffff88001f428d0 fffff880069a13c7 : fffffa8001abc610 fffff88001f424a8 fffff9800225ef60 0000000000000000 : MyFileFlt!MyPost_DirectoryControl_Execution+0x64f
fffff88001f42b00 fffff88001301ef3 : fffffa8001e25900 fffffa8001e592d0 fffff9800225ef60 0000000000010212 : MyFileFlt!MyPostDirCtrlThreadWrapper+0xb7
fffff88001f42c70 fffff800016e6a21 : fffff88001301eb0 fffff80001879600 fffffa80006bf680 fffff88000000000 : fltmgr!FltpProcessGenericWorkItem+0x43
fffff88001f42cb0 fffff80001979cce : 0000000000000000 fffffa80006bf680 0000000000000080 fffffa80006b1040 : nt!ExpWorkerThread+0x111
fffff88001f42d40 fffff800016cdfe6 : fffff8000184ee80 fffffa80006bf680 fffffa80006bfb60 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff88001f42d80 0000000000000000 : fffff88001f43000 fffff88001f3d000 fffff88001f429e0 0000000000000000 : nt!KxStartSystemThread+0x16
My explanations:
On Post procedure I create thread via FltQueueGenericWorkItem. I don’t use FltQueueDeferredIoWorkItem, because there is limitation for Paging IO, and I use the same technique for IRP_MJ_READ/WRITE. So, post procedure starts thread MyPostDirCtrlThreadWrapper and returns FLT_POSTOP_MORE_PROCESSING_REQUIRED. When thread completes, it calls FltCompletePendedPostOperation.
Verifier is turned on with standard settings.
When I researched the dump, I noticed strange value of FLT_RELATED_OBJECTS:
kd> dt MyFileFlt!pFltObjects
Local var @ 0xfffff88001f42b08 Type _FLT_RELATED_OBJECTS*
0xfffff88001f424a8 <br> +0x000 Size : 0<br> +0x002 TransactionContext : 0<br> +0x008 Filter : 0x0000000000000080 _FLT_FILTER
+0x010 Volume : 0x0000000000000001 _FLT_VOLUME<br> +0x018 Instance : 0x0000000000000001 _FLT_INSTANCE
+0x020 FileObject : 0x0000000000000040 _FILE_OBJECT<br> +0x028 Transaction : (null) <br><br>But when I called FltCreateFileEx, value of Instance was correct and this address exists in the stack (see arguments: fffffa8000063870).
Does it mean this structure was cleared outside, or this is just a bug of WinDbg?
Thanks
Valery
Rod,
It looks like I actually don’t understand completely posting technique.
I really don’t pin members of pFltObject, I supposed they must not be
released until IRP is completed.
I take pFltObject from arguments of post procedure for
IRP_MJ_DIRECTORY_CONTROL. It is PCFLT_RELATED_OBJECTS argument.
May be I wrong, but it looks like this is really core of the problem.
Now I try to reproduce the BSOD, but unsuccessfully yet, and each time
my posted thread is finished before post procedure ends. But on my crash
dump, post procedure ended before posted thread.
Thanks
Valery
16.08.2012 11:21, Rod Widdowson пишет:
It is still not obvious to me where all these datastructures are
coming from but:
Assuming that this is from a checked build I’d say that the odd
pFltObjects is your problem. Ignore the reported parameter on the
stack, this is x64 and it is a different world (Scott posted an
exellent reference to eactly this issue over in windbg earlier this week).
Are you sure that you are pinning (FltReferenceContext) all the
structures that you are passing (directly or indirectly) on to the
posted items. Without knowing the system I couldn’t say but ask
yourself what would happen if the file was closed before your
operation fired? What about a volume teardown?
You also don’t mention how you are getting hold of pFltObjects (which
I assume you have shown from the scope of one of the functions on that
stack)?
I assume that you allocate it in the pre-call, pass it to the post
call (since it has to be called <=APC and you are worried about
paging) and then hand it off to the posted function. You cannot (of
course) just pass the parameter you get to the posted function.
“Valery Druba” wrote in message
> news:xxxxx@ntfsd…
> Rod, Joe and Tony,
>
> Thank you very much for reply and sorry I did not provide full
> information.
>
> There is stack:
> STACK_TEXT:
> fffff88001f42100 fffff880012d6658 : 0000000000000000 <br>> fffffa8000063870 0000000000003fdf fffff880012d672e :
> nt!ExAcquireResourceSharedLite+0x4e
> fffff88001f42170 fffff880012f4ef0 : fffffa8000063870 <br>> 0000000000000008 fffff88001f422d8 0000000000000000 :
> fltmgr!FltpGetNextCallbackNodeForInstance+0x48
> fffff88001f421c0 fffff880012f53e1 : 00000000000002f8 <br>> fffffa8001e93680 fffffa8000063870 0000000000002f80 :
> fltmgr!TargetedIOCtrlGenerateECP+0x160
> fffff88001f42230 fffff88001304a21 : fffffa8001e93680 <br>> fffff88001f42870 fffff88001f42870 fffff88001f428e8 :
> fltmgr!FltCreateFileEx2+0xd1
> fffff88001f42340 fffff8800130f169 : fffffa8001e93680 <br>> fffffa8000063870 fffff88001f42870 fffff88001f428e8 :
> fltmgr!FltCreateFileEx+0x91
> fffff88001f423d0 fffff880069a39ba : 0000000000000000 <br>> 0000000000000000 fffffa8001d9b626 0000000000000002 :
> fltmgr!FltvCreateFileEx+0xd9
> fffff88001f42470 fffff880069a8910 : fffff88001f428d0 <br>> fffff88001f428e8 fffff980068d8f70 fffff88001f42870 :
> MyFileFlt!MyOpenFileByName+0x32a
> fffff88001f426e0 fffff880069a11bf : fffffa8000063870 <br>> 0000000000000000 fffff980068d8f70 0000000000000000 :
> MyFileFlt!MyFileModifier::ReadData+0x1f0
> fffff88001f428d0 fffff880069a13c7 : fffffa8001abc610 <br>> fffff88001f424a8 fffff9800225ef60 0000000000000000 :
> MyFileFlt!MyPost_DirectoryControl_Execution+0x64f
> fffff88001f42b00 fffff88001301ef3 : fffffa8001e25900 <br>> fffffa8001e592d0 fffff9800225ef60 0000000000010212 :
> MyFileFlt!MyPostDirCtrlThreadWrapper+0xb7
> fffff88001f42c70 fffff800016e6a21 : fffff88001301eb0 <br>> fffff80001879600 fffffa80006bf680 fffff88000000000 :
> fltmgr!FltpProcessGenericWorkItem+0x43
> fffff88001f42cb0 fffff80001979cce : 0000000000000000 <br>> fffffa80006bf680 0000000000000080 fffffa80006b1040 :
> nt!ExpWorkerThread+0x111
> fffff88001f42d40 fffff800016cdfe6 : fffff8000184ee80 <br>> fffffa80006bf680 fffffa80006bfb60 0000000000000000 :
> nt!PspSystemThreadStartup+0x5a
> fffff88001f42d80 0000000000000000 : fffff88001f43000 <br>> fffff88001f3d000 fffff88001f429e0 0000000000000000 :
> nt!KxStartSystemThread+0x16
>
> My explanations:
> On Post procedure I create thread via FltQueueGenericWorkItem. I don’t
> use FltQueueDeferredIoWorkItem, because there is limitation for Paging
> IO, and I use the same technique for IRP_MJ_READ/WRITE. So, post
> procedure starts thread MyPostDirCtrlThreadWrapper and returns
> FLT_POSTOP_MORE_PROCESSING_REQUIRED. When thread completes, it calls
> FltCompletePendedPostOperation.
>
> Verifier is turned on with standard settings.
>
> When I researched the dump, I noticed strange value of
> FLT_RELATED_OBJECTS:
> kd> dt MyFileFlt!pFltObjects
> Local var @ 0xfffff88001f42b08 Type _FLT_RELATED_OBJECTS*
> 0xfffff88001f424a8<br>> +0x000 Size : 0<br>> +0x002 TransactionContext : 0<br>> +0x008 Filter : 0x0000000000000080 _FLT_FILTER
> +0x010 Volume : 0x0000000000000001 _FLT_VOLUME<br>> +0x018 Instance : 0x0000000000000001 _FLT_INSTANCE
> +0x020 FileObject : 0x0000000000000040 _FILE_OBJECT<br>> +0x028 Transaction : (null)<br>><br>> But when I called FltCreateFileEx, value of Instance was correct and <br>> this address exists in the stack (see arguments: fffffa8000063870).
> Does it mean this structure was cleared outside, or this is just a bug
> of WinDbg?
>
> Thanks
> Valery
>
>
> —
> 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
Valery,
If you are completing the request in the worker queue I’d imagine that the
instances will remain referenced. Certainly you can trust
FLT_CALLBACK_DATA until you complete it (by returning FLT_POST_OP_COMPLETE
or calling FltCompletePendedPostOperation).
I’d be inclined to take the file object from
CallBackData->Iopb->TargetFileObject. If you have other parameters you can
pop them into CallBackData->FilterContext.
But you seem to indicate that you are passing PCFLT_RELATED_OBJECTS to your
posted function. I have (I’ll admit) no idea about what scope it has but
I’d be worried that it does not outlive the function that it is called with.
Have you tried setting (in the lab) the priority of your worker function
down ? That might tear open any timing windows.
Rod,
Thank you very much for your help!
I hope I managed with this issue. The cause is that structure
PCFLT_RELATED_OBJECTS is not valid after finishing post procedure, even
if IRP is not completed.
I reproduced the situation when posted thread started after finishing
post procedure. In such case on FltCreateFileEx I can get BSOD or
STATUS_OBJECT_NOT_FOUND.
Thank you very much again for your advice.
Regards
Valery
16.08.2012 12:25, Rod Widdowson пишет:
Valery,
If you are completing the request in the worker queue I’d imagine that
the instances will remain referenced. Certainly you can trust
FLT_CALLBACK_DATA until you complete it (by returning
FLT_POST_OP_COMPLETE or calling FltCompletePendedPostOperation).
I’d be inclined to take the file object from
CallBackData->Iopb->TargetFileObject. If you have other parameters
you can pop them into CallBackData->FilterContext.
But you seem to indicate that you are passing PCFLT_RELATED_OBJECTS to
your posted function. I have (I’ll admit) no idea about what scope it
has but I’d be worried that it does not outlive the function that it
is called with.
Have you tried setting (in the lab) the priority of your worker
function down ? That might tear open any timing windows.
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