Thank you.
That is what I was writing (all the work in the other thread) when I
received your message.
Anyway, it is undocumented - disable special kernel APC when
IRP_MJ_CLOSE.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Friday, February 03, 2006 3:48 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] problem with IO completion
This is you case- creating and sending IRP in IRP_MJ_CLOSE dispatch
routine while APC are disabled, and this IRP hangs.
To avoid hanging you may do all the work in the other thread( i.e.
system worker thread ) and wait for the IRP completion( using
KeWaitForSingleObject ) in the MRxCloseSrvOpen .
“Yakov Kaabak” wrote in message
news:xxxxx@ntdev…
I don’t know. This has nothing to do with my situation. My
situation is: issue the DeviceIoControl request from within IRP_MJ_CLOSE
handler and wait for its completion. On the other hand, the
documentation about IRP_MJ_CLOSE says nothing about APCs. In my case
the _KTHREAD.SpecialApcDisable is set to -1 in the beginning of
MmCleanProcessAddressSpace (it is the close request on executable file
during process shutdown), but not only: I tried to bypass this
instruction
nt!MmCleanProcessAddressSpace+0x98:
80590b8f 66ff4d72 dec word ptr [ebp+0x72]
in windbg but with no effect.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Friday, February 03, 2006 2:55 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] problem with IO completion
“OS does not insert APC on the close request completion” means-
during completion of the IRP_MJ_CLOSE request OS does not insert an APC,
but simple call KeSeteEvent and return w/o calling KeInsertQueueApc. I
does not mean “OS does not insert APC for every IRP completion”.
I suppose this is you case- ObDerefrenceObject is called with
disabled APC for a thread, and IRP_MJ_CLOSE is sent, and this IRP(
IRP_MJ_CLOSE ) must be completed w/o dead lock, because APC is not
inserted in case of the completing IRP_MJ_CLOSE, unless someone sent
another IRP and wait for it completion from the IRP_MJ_CLOSE dispatch
function.
Am I wrong?
“Yakov Kaabak” wrote in message
news:xxxxx@ntdev…
Slava,
Your “OS does not insert APC on the close request
completion” seems to be wrong, because in my situation, everything works
wonderfully unless is called from ExitThread, that is when I just copy a
file, and my function is called to close it (not from process
termination sequence), OS DOES insert APC and everything works. Anyway,
it isn’t documented.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Friday, February 03, 2006 1:25 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] problem with IO completion
It seems to be a feature. There is a special processing
for the IRP_MJ_CLOSE operation, because close request may be a result of
the other APC( e.g. ObDerefrenceObject is called in the APC ), therefore
APC insertion may be disabled during close request completion. OS does
not insert APC on the close request completion.
“Yakov Kaabak” wrote in
message news:xxxxx@ntdev…
Thank Mark and Slava for response. No one
guessed true reason. The reason lies within KiInsertQueueApc function.
When doing its job of inserting APC into thread, it checks its
_KTHREAD.SpecialApcDisable field. If this field is not zero, the
function exits immediately, therefore APC is not inserted. When this
problem arises, the file being closed is executable being in
process-termination sequence. The MRxCloseSrvOpen is called from
ExitThread function, and the _KTHREAD.SpecialApcDisable is set to -1.
THAT is the reason.
It doesn’t seem to be documented in the DDK. (I
mean that there is nothing about when thread is exiting special kernel
APC are disabled).
Is it bug in documentation or bug in Windows? Or
is it a feature?
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Friday, February 03, 2006 2:52 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] problem with IO completion
You right.
But it was written that an APC was inserted(
i.e. IoCompleteRequest was called, therefore there is no lock in the
ZwCloseHandle ). I suppose there is some case- if Irp->PendingReturned
is not set and there is an error in Irp processing then UserEvent is not
set in the signal state( may I wrong? ).
May be IoMarkIrpPending was lost.
“Roddy, Mark”
wrote in message news:xxxxx@ntdev…
I don’t think that would matter: the
event ought to have been signaled in either the success or failure case.
The OP can look at the event and see if it is signaled or not. Is it
possible that whatever Filehandle represents is held open by this
thread, and that the IRP is not being completed because it is
deadlocked?
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Thursday, February 02, 2006 5:21
PM
To: Windows System Software Devs
Interest List
Subject: Re:[ntdev] problem with IO
completion
I suppose that an error was during an
Irp processing and because you sent a FileObject in the Irp stack
location, this file object was set to a signal state instead of the
Event( as in case of a success processing ).
“Yakov Kaabak”
wrote in message news:xxxxx@ntdev…
I have written RDBSS-based file system
driver (mini-redirector).
It sort of works, but there is a
problem.
Here is code fragment from its
MRxCloseSrvOpen function:
IO_STATUS_BLOCK iostatus;
PIRP Irp;
KEVENT ioEvent;
PIO_STACK_LOCATION stack;
NTSTATUS status;
CLOSE_PARAMETERS_BLOCK cpb;
KdPrint((DRIVERNAME " -
CloseHostHandle: FileHandle = %08x\n",
FileHandle));
cpb.FileHandle = FileHandle;
KeInitializeEvent(&ioEvent,
NotificationEvent, FALSE);
Irp =
IoBuildDeviceIoControlRequest(PCITG_SF_CLOSEHANDLE,
pDeviceExtension->pPciTgDO, &cpb, sizeof (CLOSE_PARAMETERS_BLOCK),
NULL, 0,
TRUE, &ioEvent,
&iostatus);
if (!Irp)
{
return
STATUS_INSUFFICIENT_RESOURCES;
}
stack =
IoGetNextIrpStackLocation(Irp);
stack->FileObject =
pDeviceExtension->pPciTgFO;
status =
IoCallDriver(pDeviceExtension->pPciTgDO, Irp);
if (status == STATUS_PENDING)
{
KeWaitForSingleObject(&ioEvent, Executive, KernelMode, FALSE, NULL);
status =
iostatus.Status;
}
return status;
Now suppose I run a file (executable)
from this driver’s domain.
From this driver’s standpoint that means
open, several reads and close.
On close the code above is executed, but
it hangs forever on KeWaitForSingleObject. IoCompleteRequest IS called
on this IRP. I traced in windbg through IoCompleteRequest, and
everything seems to be OK (up to APC insertion).
If I copy the file rather than run,
everything looks OK. The code above is executed up to return statement.
I run all this with Verifier’s Enhanced
Io checking enabled, and Verifier doesn’t complain.
—
Questions? First check the Kernel Driver
FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev
as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown
lmsubst tag argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com