SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)

Hello,
I a have little bit of an issue with a pending create Irp and I/O processing

In my create dispatch, I need to make an extra create request, and do a little I/O on that.

I follow Maxim’s rules from this post: http://www.osronline.com/showThread.cfm?link=60510, that are mentioned below:

Another idea:

  • catch CREATE in the filter.
  • save the original filename, RelatedFileObject and the stack location
  • patch them with the new filename, RelatedFileObject and new stack location flags
  • pass the IRP down
  • wait for it
  • work with a file
  • send CLEANUP manually (using the same IRP, for instance)
  • send CLOSE manually
  • reset file object’s flag FO_CLEANUP_COMPLETE
  • restore the original filename, RelatedFileObject and the stack location
  • now pass CREATE of the user-requested file down.

The thing is that not all my processing can be done in the create dispatch, instead of the step called: “work with file” , so I mark the initial Irp as pending, and return status pending, so the extra processing will be done in a worker thread.

The processing work good.
Basically I build some Irp’s for read/write request using IoBuildAsynchronousFsdRequest.

I make the 2 cleanup/close requests on the file and clear the FO_CLEANUP_COMPLETE on the initial file object. I make these 2 request on different Irp’s from the initial one because that one is marked as pending.

After this I restore Irp previous values. I complete the Irp synchronously.
Until here nothing goes wrong. I call IoCompleteRequest on the initial Irp and exit the thread.

After som short I get the above bugchek with this on the stack:
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f8cc2d2c 80500dd4 81bc8298 80561640 81bc8b20 nt!CcScheduleReadAhead+0x2d9
f8cc2d74 804e426b 81bc8298 00000000 81bc8b20 nt!CcScheduleReadAhead+0x240
f8cc2dac 8057d0f1 81bc8298 00000000 00000000 nt!ExQueueWorkItem+0x104
f8cc2ddc 804f827a 804e4196 00000000 00000000 nt!PsCreateSystemThread+0x70
00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107

Why may that be ?
I am guessing that I didn’t do the second step correctly: " save the original filename, RelatedFileObject and the stack location " .
Or is it because the IO manager still has some caching to do on that file ?

I saved Original File Name, RelatedFile Obect and, from the stack the following:
Flags, Control, SecurityContext, FileAttributes, Options, ShareAccess, DeviceObject.

As for the IRP initial packet I saved and restored

KPROCESSOR_MODE RequestorMode;
ULONG Flags;
PETHREAD RequestorThread;
PIO_STATUS_BLOCK UserIosb;
KAPC Apc;
CCHAR ApcEnvirontment;
PVOID CompletionKey;
PVOID UserApcContext;
PIO_APC_ROUTINE UserApcRoutine;
PVOID IssuingProcess;

Any tips ?

>The thing is that not all my processing can be done in the create dispatch,

instead of the step called: “work with file” , so I mark the initial Irp as
pending, and return status pending, so the extra processing will be done in a
worker thread.

If you do this, how can you later pass IRP down (in non-arbitrary context!!) to FSD? Now thread waits in IO manager for completion, so you have no chance to send it down.
-bg

I see. It is post-processing of create so ignore my previous post.

Do you interrupt completion when you pend create IRP? If not you don’t own IRP so you cannot again complete it.
-bg

ok thanks.
So my options would be, to make the I/O operations in the create dispatch right ?

>

I see. It is post-processing of create so ignore my previous post. Do you interrupt completion when >you pend create IRP? If not you don’t own IRP so you cannot again complete it.

Not quite. It is post -processing, but not with the original request. Before I send the IRP down in create dispatch, I change the File Name, so my file object is not the one requested by the user.

Now on this FILE object i do I/o in the thread, and the I restore original file name, and then I pass it down.

Only now the initial request is really done.
i get status success. I save the initial Irp->Tail.Overlay.Thread as I mentioned

my iocompletion is oK. I return status_more_processing required.

I tryed also another aproach.
In my dispatch create, I call IoMarkIrpPending, from the first time, without making my working file object, and return STATUS_PENDING.

Now in my worker thread, I get a fileobject with IoCreateFileSpecifiDeviceObjectHint and ObReferenceObjectByHandle.

I do all work on this FileObject.

After I/O is done I complete the initial IRP exactly as did in the previous mentionings.

This time everything is working fine.

So I am guesing that it is not the arbitrary thread context, because, the IoManager will bring an APC to the thread waiting for the initial create request, and as I can see this is the waited result.

I think you are right. On vista, the application hangs, waiting for the initial request I am guesing, because I am completing the Irp from worker thread.

How should I then implement it ?
I should do the extra I/O only in post-create right ?

I would do everything synchronously before passing the original CREATE
down, even though it will disable Longhorn’s overlapped creates.

The thing is that otherwise you will probably pass CREATE down in a wrong
process/thread context, which can confuse some filters and maybe even FSDs.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Hello,
> I a have little bit of an issue with a pending create Irp and I/O processing
>
> In my create dispatch, I need to make an extra create request, and do a
little I/O on that.
>
> I follow Maxim’s rules from this post:
http://www.osronline.com/showThread.cfm?link=60510, that are mentioned below:
>
> Another idea:
> - catch CREATE in the filter.
> - save the original filename, RelatedFileObject and the stack location
> - patch them with the new filename, RelatedFileObject and new stack location
flags
> - pass the IRP down
> - wait for it
> - work with a file
> - send CLEANUP manually (using the same IRP, for instance)
> - send CLOSE manually
> - reset file object’s flag FO_CLEANUP_COMPLETE
> - restore the original filename, RelatedFileObject and the stack location
> - now pass CREATE of the user-requested file down.
>
> The thing is that not all my processing can be done in the create dispatch,
instead of the step called: “work with file” , so I mark the initial Irp as
pending, and return status pending, so the extra processing will be done in a
worker thread.
>
> The processing work good.
> Basically I build some Irp’s for read/write request using
IoBuildAsynchronousFsdRequest.
>
> I make the 2 cleanup/close requests on the file and clear the
FO_CLEANUP_COMPLETE on the initial file object. I make these 2 request on
different Irp’s from the initial one because that one is marked as pending.
>
> After this I restore Irp previous values. I complete the Irp synchronously.
> Until here nothing goes wrong. I call IoCompleteRequest on the initial Irp
and exit the thread.
>
> After som short I get the above bugchek with this on the stack:
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
wrong.
> f8cc2d2c 80500dd4 81bc8298 80561640 81bc8b20 nt!CcScheduleReadAhead+0x2d9
> f8cc2d74 804e426b 81bc8298 00000000 81bc8b20 nt!CcScheduleReadAhead+0x240
> f8cc2dac 8057d0f1 81bc8298 00000000 00000000 nt!ExQueueWorkItem+0x104
> f8cc2ddc 804f827a 804e4196 00000000 00000000 nt!PsCreateSystemThread+0x70
> 00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107
>
> Why may that be ?
> I am guessing that I didn’t do the second step correctly: " save the original
filename, RelatedFileObject and the stack location " .
> Or is it because the IO manager still has some caching to do on that file ?
>
> I saved Original File Name, RelatedFile Obect and, from the stack the
following:
> Flags, Control, SecurityContext, FileAttributes, Options, ShareAccess,
DeviceObject.
>
> As for the IRP initial packet I saved and restored
>
> KPROCESSOR_MODE RequestorMode;
> ULONG Flags;
> PETHREAD RequestorThread;
> PIO_STATUS_BLOCK UserIosb;
> KAPC Apc;
> CCHAR ApcEnvirontment;
> PVOID CompletionKey;
> PVOID UserApcContext;
> PIO_APC_ROUTINE UserApcRoutine;
> PVOID IssuingProcess;
>
>
> Any tips ?
>
>
>

There is not enough information here, some relevant source and !analyze -v
output could help.

//Daniel

The initial IRP will be going down on a different context for sure, being forwarded from the system worker thread. I will try to figure a way of doing the processing in post-create.
I tried making a stream file object, the I allocated an IRP with IoAllocateIrp, but I never succeded. IoCallDriver always blue screened with NTFS file system exception.
What are the rules in making a create request with stream file objects ? I never got to read good documentation anywhere. Is it possible to make a create request with a stream file object from a worker thread, with an allocated IRP ?

I think stream file object never uses MJ_CREATE request.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> The initial IRP will be going down on a different context for sure,
being forwarded from the system worker thread. I will try to figure a way of
doing the processing in post-create.
> I tried making a stream file object, the I allocated an IRP with
IoAllocateIrp, but I never succeded. IoCallDriver always blue screened with
NTFS file system exception.
> What are the rules in making a create request with stream file objects ? I
never got to read good documentation anywhere. Is it possible to make a create
request with a stream file object from a worker thread, with an allocated IRP ?
>
>

In this case the only way out that I see it is, that in post-create, call IoCreateFileSpecifyDeviceObjectHint with the lower Device as the hint, and now pend the create request, make extra I/O in worker thread and let complete initial request there.