Hi Yatindra, since I am using DriverWorks as a framework I will rework the
code into WDM:
IRB freeIrb;
freeIrb.u.FreeAddressRange.nAddressesToFree = nAddressesToFree; // this is
always 1 for me
freeIrb.u.FreeAddressRange.p1394AddressRange = pOurAddressRange; // array
of type ADDRESS_RANGE (length 1), filled up by bus driver when it allocated
address space via REQUEST_ALLOCATE_ADDRESS_RANGE
freeIrb.u.FreeAddressRange.pAddressRange = m_Handle2AddressRange; // handle
returned to me from the bus driver when it allocated address range
freeIrb->FunctionNumber = REQUEST_FREE_ADDRESS_RANGE;
// This is then bundled in an IRP: cutting and pasting some code for doing
this (again, it uses DriverWorks routines, but this is what it comes down
to):
IO_STATUS_BLOCK ioStatus;
KEVENT event;
PIO_STACK_LOCATION irpStack;
PIRP irp;
KeInitializeEvent(&event, NotificationEvent, FALSE);
irp = IoBuildDeviceIoControlRequest( IOCTL_1394_CLASS, m_pLowerDevice,
NULL, 0, NULL, 0, TRUE, &event, &ioStatus);
if (irp != NULL)
{
irpStack = IoGetNextIrpStackLocation(irp);
irpStack->Parameters.Others.Argument1 = irb;
irpStack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
status = IoCallDriver(m_pLowerDevice, irp);
if (status == STATUS_PENDING)
{
KeWaitForSingleObject(
&event,
Executive,
KernelMode,
FALSE,
NULL);
status = ioStatus.Status;
}
}
else
{
status = STATUS_INSUFFICIENT_RESOURCES;
}
return status;
As you can see, this is pretty straightforward code. I’m sure I’m missing
something, but I can’t see why the ohci1394.sys gets hit with a 0xD5 when
driver verifier is on, and why this is when I try it with another product as
well (same stack trace). It is quite possible (and maybe probable) that we
are both commiting the same error…but I cannot see what!
kind regards,
Philip Lukidis
----- Original Message -----
From: yatindra vaishnav
To: Windows System Software Devs Interest List
Sent: Saturday, March 06, 2004 7:30 AM
Subject: Re: [ntdev] D5 bugcheck in ohci1394.sys when freeing address range
hi Philip,
Can u send the code snippet for the same?
Good Luck,
>From: “Philip Lukidis”
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re: [ntdev] D5 bugcheck in ohci1394.sys when freeing address range
>Date: Fri, 5 Mar 2004 09:01:31 -0500
>
>Related info: I have seen the same bugcheck with the same stack trace
>using another 1394 audio product. It is very possible that we are
>committing the same error, or something else is going on here. (same
>conditions, SMP machine, WinXP SP1, verifying ohci1394.sys and 1394bus.sys
>with all options except low resources and DMA).
>
>Philip Lukidis
>
>----- Original Message -----
>From: “Philip Lukidis”
>To: “Windows System Software Devs Interest List”
>Sent: Thursday, March 04, 2004 4:46 PM
>Subject: Re: [ntdev] D5 bugcheck in ohci1394.sys when freeing address range
>
>
> > Hi yatindra, thanks for answering. I’m am not the one who has allocated
>the
> > address range in the first place, the bus driver did it at my request.
>All
> > I am doing is passing a handle it gave me, an array of type
ADDRESS_RANGE
> > describing the address range which it allocated before and the length of
> > said array. Upon return, I normally free my own related FIFO structures
> > myself, but of course ohci1394.sys bugchecks. I can’t think of any
faulty
> > data I am passing the ohci driver.
> >
> > I can’t think of how I could cause ohci1394.sys to access freed
memory…
> >
> > Philip Lukidis
> >
> > ----- Original Message -----
> > From: yatindra vaishnav
> > To: Windows System Software Devs Interest List
> > Sent: Thursday, March 04, 2004 12:07 PM
> > Subject: RE: [ntdev] D5 bugcheck in ohci1394.sys when freeing address
>range
> >
> >
> > HI Philip,
> > Try to find the pointer validity and mismatch in your application it is
> > mostly due to that only. It is sure that ur driver is not crashing the
> > system, so ur driver making other to crash the system, just do code walk
> > thru. you will get that problem.
> >
> > Good Luck,
> >
> >
> >
> > >From: “Philip Lukidis”
> > >Reply-To: “Windows System Software Devs Interest List”
> > >To: “Windows System Software Devs Interest List”
> > >Subject: [ntdev] D5 bugcheck in ohci1394.sys when freeing address range
> > >Date: Thu, 4 Mar 2004 08:44:07 -0500
> > >
> > >Hi. I am developing a custom 1394 audio device, which works in Win2k
and
> > >WinXP. I recently decided to start verifying the 1394 stack when I
>verify
> > >my own driver using driver verifier (all options except DMA and low
> > >resources).
> > >
> > >On a WinXP SP1 machine (SMP, 512 MB => is this too low for 3 drivers
to
> > be
> > >verified?), I have observed a D5 bugcheck in ohci1394.sys.
> > >This fault occurred after I tried to free my address range. This
> > >fault is a Driver Verifier special pool reference after that memory had
> > been
> > >freed (trace below post).
> > >
> > >I have not yet had time to try with Win2k SP4, or suppressing 1 proc.
I
> > >quickly checked the KB and did not find an article on this.
> > >
> > >Has anyone else run into this? Thanks for any help.
> > >
> > >Philip Lukidis
> > >
> > >
> >
>
> *******************************************************************
> >
> > >
> > >
> > >
> > > Bugcheck Analysis
> > >
> > >
> > >
> >
>
> *************************************************************************
> >
> > >
> > >
> > >Use !analyze -v to get detailed debugging information.
> > >
> > >BugCheck D5, {82a4cfb0, 0, f84c22a0, 0}
> > >
> > >Probably caused by : ohci1394.sys ( ohci1394!OhciIOCtl+80e )
> > >
> > >Followup: MachineOwner
> > >---------
> > >
> > >nt!RtlpBreakWithStatusInstruction:
> > >8051d778 cc int 3
> > >1: kd> !analyze -v
> >
>
> *******************************************************************
> >
> > >
> > >
> > >
> > > Bugcheck Analysis
> > >
> > >
> > >
> >
>
> *************************************************************************
> >
> > >
> > >
> > >DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
> > >Memory was referenced after it was freed.
> > >This cannot be protected by try-except.
> > >When possible, the guilty driver’s name (Unicode string) is printed on
> > >the bugcheck screen and saved in KiBugCheckDriver.
> > >Arguments:
> > >Arg1: 82a4cfb0, memory referenced
> > >Arg2: 00000000, value 0 = read operation, 1 = write operation
> > >Arg3: f84c22a0, if non-zero, the address which referenced memory.
> > >Arg4: 00000000, (reserved)
> > >
> > >Debugging Details:
> > >------------------
> > >
> > >
> > >READ_ADDRESS: 82a4cfb0 Special pool
> > >
> > >FAULTING_IP:
> > >ohci1394!OhciIOCtl+80e
> > >f84c22a0 817808affceaad cmp dword ptr [eax+0x8],0xadeafcaf
> > >
> > >MM_INTERNAL_CODE: 0
> > >
> > >IMAGE_NAME: ohci1394.sys
> > >
> > >DEBUG_FLR_IMAGE_TIMESTAMP: 3d6ddc4f
> > >
> > >MODULE_NAME: ohci1394
> > >
> > >FAULTING_MODULE: f84bf000 ohci1394
> > >
> > >DEFAULT_BUCKET_ID: DRIVER_FAULT
> > >
> > >BUGCHECK_STR: 0xD5
> > >
> > >LAST_CONTROL_TRANSFER: from 804eb3c1 to f84c22a0
> > >
> > >TRAP_FRAME: f88f25fc – (.trap fffffffff88f25fc)
> > >ErrCode = 00000000
> > >eax=82a4cfa8 ebx=81ef20e0 ecx=0022021d edx=fff3021a esi=f88f2838
> > >edi=00000103
> > >eip=f84c22a0 esp=f88f2670 ebp=f88f2698 iopl=0 nv up ei ng nz na
>pe
> > >nc
> > >cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > >efl=00010282
> > >ohci1394!OhciIOCtl+0x80e:
> > >f84c22a0 817808affceaad cmp dword ptr [eax+0x8],0xadeafcaf
> > >Resetting default scope
> > >
> > >STACK_TEXT:
> > >f88f2698 804eb3c1 81ef2028 8271ef20 806bb2e4 ohci1394!OhciIOCtl+0x80e
> > >f88f26a8 80633110 82660fa8 f88f2838 8237c678 nt!IopfCallDriver+0x31
> > >f88f26cc f84d259f f88f2880 f88f2838 8237c678 nt!IovCallDriver+0x9e
> > >f88f26f4 f84d25cb 8237c910 008f2838 8271ef20
> > >1394BUS!Bus1394FreeAddressRange+0x189
> > >f88f2708 f84d0f2a f88f2838 8271ef20 81e96a40
> > >1394BUS!Bus1394DispatchAddressMapRequest+0x29
> > >f88f2738 804eb3c1 8237c678 8271ef20 806bb2e4 1394BUS!Bus1394IOCtl+0x29e
> > >f88f2748 80633110 8271efd0 8271eff4 81dcb0d8 nt!IopfCallDriver+0x31
> > >f88f276c 8063d2a3 81dcb020 81ea3c08 81dbfb00 nt!IovCallDriver+0x9e
> > >f88f277c 804eb3c1 81dcb020 8271ef20 806bb2e4
> > nt!ViDriverDispatchGeneric+0x27
> > >f88f278c 80633110 81dcb3b0 81dcca78 81dbfb00 nt!IopfCallDriver+0x31
> > >f88f27b0 bac63e10 81dcb95c f88f27d0 bac63cb3 nt!IovCallDriver+0x9e
> > >
> > >—
> > >Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > Easiest Money Transfer to India . Send Money To 6000 Indian Towns.
Easiest
> > Way To Send Money Home! —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > 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: xxxxx@hotmail.com
> > 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: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Easiest Money Transfer to India . Send Money To 6000 Indian Towns. Easiest
Way To Send Money Home! —
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com