From - Wed Oct 01 08:17:13 1997
Path: news.mitre.org!blanket.mitre.org!news.tufts.edu!cam-news-feed5.bbnplanet.com!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!europa.clark.net!208.134.241.18!newsfeed.internetmci.com!131.103.1.102!iagnet.net!128.125.253.136!usc!newshub.cts.com!thumper.tmisnet.com!newsfeed.cts.com!cmkrnl!jeh
From: jeh@cmkrnl.com (Jamie Hanrahan)
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: Cancelable Irp's
Message-ID: <1997Sep30.222254.8239@cmkrnl>
Date: 30 Sep 97 22:22:54 PST
References: <01bccde0$fd9d8ae0$822bb2cc@cruss>
Organization: Kernel Mode Systems, San Diego, CA
Lines: 45

In article <01bccde0$fd9d8ae0$822bb2cc@cruss>, "Christine Russ" <cruss@analogic.com> writes:
>      I wanted to post something that I just discovered.  I am using the
> device object queue for DMA requests (IoStartPacket/IoStartNextPacket).  At
> the beginning of the StartIo routine, I acquire the cancel spinlock, and
> see if the Irp->Cancel field is TRUE.  If it is TRUE, I just return and let
> the Cancel routine handle it.  If it is not TRUE,  I call
> IoSetCancelRoutine(Irp,NULL), to remove the IRP from the cancelable state
> for the remaining life of the IRP (or so I thought).  
>      I am finding that in my Dpc where dma requests are being completed,
> some of the Irp's that I am trying to complete successfully, have the
> Irp->Cancel parameter set to TRUE. 

Yes, this can happen.  Irp->Cancel simply means "somebody called 
IoCancelIrp on this IRP".  If the IRP has no CancelFunction pointer, 
IoCancelIrp simply sets Irp->Cancel and returns. 

Btw, IoCancelIrp is the only thing that ever sets Irp->Cancel, and as 
far as I know, the only way IoCancelIrp gets called is if either

	- the thread that issued the IO calls CancelIo (Win32)

	or, - the thread that issued the IO tries to exit

	or, - if the IRP was created by an upper-level driver, the 
	 driver that created the IRP can call IoCancelIrp on it, 
	 provided it knows that the IRP hasn't been completed


>  It also seems that it does not matter
> what I set in the Irp->IoStatus.Information field, the the Win32
> application thinks that no bytes were returned (I am using the Win32
> command, ReadFile).

Is this for all IRPs, or just for ones for which the Cancel bit is 
set? Also, were these IRPs issued through a file object created with 
FILE_FLAG_OVERLAPPED?  If yes, you have to pass an OVERLAPPED 
structure to the IO APIs, and fetch the number of bytes transferred 
via GetOverlappedResult .

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
        Internet: jeh@cmkrnl.com (JH645)  CompuServe: 74140,2055  
drivers, internals, networks, applications, and training for VMS and Windows NT
NT driver FAQ, links, and other information:  http://www.cmkrnl.com/

If you post a reply in news, please don't e-mail it too.