Access violation using WDF & USB Isochronous Pipes

NTDEV
1

I’m running into an Access Violation problem using WDF with Isochronous.
I’ve had no problems performing Bulk, Interrupt and Control transfers, but
Isochronous transfers are causing me a headache.

I’ve been through the DDK documentation and I’m confident I’m following the
instructions correctly.
I’m trying to read 160 bytes, broken down into 10, 16 byte packets. I build
the URB and when I try to send synchronously I get an access violation.

In this example I create a URB in a new buffer, and create a new buffer to
hold the 160bytes, and simply try to read data into the new buffer.

I’ve posted the code segment + the output from windbg.

I’d appreciate any help, even just a pointer in the right direction for some
good documentation on chasing down this problem.

Chris.

CODE SEGMENT

//create new URB in buffer
ULONG ulURB, i;
PURB purbURB; //pointer to new URB in new Buffer
PVOID pvTemp; //pointer to new buffer used to recieve data from read
request
ulURB = GET_ISO_URB_SIZE(10);

purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
purbURB->UrbIsochronousTransfer.Hdr.Function =
URB_FUNCTION_ISOCH_TRANSFER ;
purbURB->UrbIsochronousTransfer.Hdr.Length = (short)ulURB;
purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
purbURB->UrbIsochronousTransfer.TransferFlags =
USBD_TRANSFER_DIRECTION_IN;
purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
purbURB->UrbIsochronousTransfer.StartFrame =
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;
purbURB->UrbIsochronousTransfer.UrbLink = NULL;

for(i = 0; i <10; i++){
KdPrint((“Setting Iso Desc %d\n”, i));
purbURB->UrbIsochronousTransfer.IsoPacket[i].Offset = i*16;
purbURB->UrbIsochronousTransfer.IsoPacket[i].Length = 16;
}

KdPrint((“Sending Packet\n”));
status =
WdfUsbTargetPipeSendUrbSynchronously(upPipe,NULL,&(pDevContext->wrsoReadWriteOptions),purbURB);
ExFreePool((PVOID)purbURB);
ExFreePool(pvTemp);
if (NT_SUCCESS(status)) {
KdPrint((“Send success\n”));

}else{
KdPrint((“Send Failed\n”));
}

WINDBG OUTPUT

Setting Iso Desc 0
Setting Iso Desc 1
Setting Iso Desc 2
Setting Iso Desc 3
Setting Iso Desc 4
Setting Iso Desc 5
Setting Iso Desc 6
Setting Iso Desc 7
Setting Iso Desc 8
Setting Iso Desc 9
Sending Packet
Access violation - code c0000005 (!!! second chance !!!)
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

2
  1. I would zero out the URB allocation before initializing the fields.
  2. looking at the following code which has the violation

f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

I would dump eax and eax+10a and compare the values to purbURB and
pvTemp and see if they are within the range of those 2 allocations. Also
see if 0x10a is an offset into the urb, perhaps into the IsoPacket
array.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Sunday, April 16, 2006 4:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Access violation using WDF & USB Isochronous Pipes

I’m running into an Access Violation problem using WDF with Isochronous.

I’ve had no problems performing Bulk, Interrupt and Control transfers,
but
Isochronous transfers are causing me a headache.

I’ve been through the DDK documentation and I’m confident I’m following
the
instructions correctly.
I’m trying to read 160 bytes, broken down into 10, 16 byte packets. I
build
the URB and when I try to send synchronously I get an access violation.

In this example I create a URB in a new buffer, and create a new buffer
to
hold the 160bytes, and simply try to read data into the new buffer.

I’ve posted the code segment + the output from windbg.

I’d appreciate any help, even just a pointer in the right direction for
some
good documentation on chasing down this problem.

Chris.

CODE SEGMENT

//create new URB in buffer
ULONG ulURB, i;
PURB purbURB; //pointer to new URB in new Buffer
PVOID pvTemp; //pointer to new buffer used to recieve data from
read
request
ulURB = GET_ISO_URB_SIZE(10);

purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
purbURB->UrbIsochronousTransfer.Hdr.Function =
URB_FUNCTION_ISOCH_TRANSFER ;
purbURB->UrbIsochronousTransfer.Hdr.Length = (short)ulURB;
purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
purbURB->UrbIsochronousTransfer.TransferFlags =
USBD_TRANSFER_DIRECTION_IN;
purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
purbURB->UrbIsochronousTransfer.StartFrame =
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;
purbURB->UrbIsochronousTransfer.UrbLink = NULL;

for(i = 0; i <10; i++){
KdPrint((“Setting Iso Desc %d\n”, i));
purbURB->UrbIsochronousTransfer.IsoPacket[i].Offset = i*16;
purbURB->UrbIsochronousTransfer.IsoPacket[i].Length = 16;
}

KdPrint((“Sending Packet\n”));
status =
WdfUsbTargetPipeSendUrbSynchronously(upPipe,NULL,&(pDevContext->wrsoRead
WriteOptions),purbURB);
ExFreePool((PVOID)purbURB);
ExFreePool(pvTemp);
if (NT_SUCCESS(status)) {
KdPrint((“Send success\n”));

}else{
KdPrint((“Send Failed\n”));
}

WINDBG OUTPUT

Setting Iso Desc 0
Setting Iso Desc 1
Setting Iso Desc 2
Setting Iso Desc 3
Setting Iso Desc 4
Setting Iso Desc 5
Setting Iso Desc 6
Setting Iso Desc 7
Setting Iso Desc 8
Setting Iso Desc 9
Sending Packet
Access violation - code c0000005 (!!! second chance !!!)
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Well I managed to get a little further, but not much,

I adjusted the code to zero out both buffers,.

CODE_SEGMENT

//create new URB in buffer
ULONG ulURB, i;
PURB purbURB; //pointer to new URB in new Buffer
PVOID pvTemp; //pointer to new buffer used to recieve data from read
request
UCHAR* ucData;
ulURB = GET_ISO_URB_SIZE(10);

purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
//0 out both buffers
ucData = (UCHAR*)purbURB;
for(i = 0; i KdPrint((“Zero purbURB %d\n”, i));
(ucData + i) = 0;
}

ucData = (UCHAR)pvTemp;
for(i = 0; i <160; i++){
KdPrint((“Zero pvTemp %d\n”, i));
(ucData + i) = 0;
}
KdPrint((“Address of URB = 0x%x\n”, purbURB));
KdPrint((“URB GET_ISO_URB_SIZE Macro result = 0x%x\n”, ulURB));
KdPrint((“Current frame 0x%x\n”, URB_FUNCTION_GET_CURRENT_FRAME_NUMBER));

purbURB->UrbIsochronousTransfer.Hdr.Function =
URB_FUNCTION_ISOCH_TRANSFER ;
purbURB->UrbIsochronousTransfer.Hdr.Length = (USHORT)ulURB ;
purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
purbURB->UrbIsochronousTransfer.TransferFlags =
USBD_TRANSFER_DIRECTION_IN;
purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
purbURB->UrbIsochronousTransfer.StartFrame =
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;
purbURB->UrbIsochronousTransfer.UrbLink = NULL;

for(i = 0; i <10; i++){
KdPrint((“Setting Iso Desc %d\n”, i));
purbURB->UrbIsochronousTransfer.IsoPacket[i].Offset = i16;
purbURB->UrbIsochronousTransfer.IsoPacket[i].Length = 16;
}

KdPrint((“Sending Packet\n”));
status =
WdfUsbTargetPipeSendUrbSynchronously(upPipe,NULL,&(pDevContext->wrsoReadWriteOptions),purbURB);
ExFreePool((PVOID)purbURB);
ExFreePool(pvTemp);
if (NT_SUCCESS(status)) {
KdPrint((“Send success\n”));

}else{
KdPrint((“Send Failed\n”));
}
CODE_SEGMENT_END

I dumped the registers, the value of eax doesn’t seem valid, ebx is the
address of the URB.
Also the offset of 0x10a is bigger than the URB size 0xd8, calculated using
GET_ISO_URB_SIZE(numpackets) macro.

WINDGB_OUTPUT + REGISTERS

Address of URB = 0x8276ef28
URB GET_ISO_URB_SIZE Macro result = 0xd8
Current frame 0x7
Setting Iso Desc 0
Setting Iso Desc 1
Setting Iso Desc 2
Setting Iso Desc 3
Setting Iso Desc 4
Setting Iso Desc 5
Setting Iso Desc 6
Setting Iso Desc 7
Setting Iso Desc 8
Setting Iso Desc 9
Sending Packet
Access violation - code c0000005 (!!! second chance !!!)
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
kd> r
eax=ffffffff ebx=8276ef28 ecx=00000000 edx=00000394 esi=81dc59f0
edi=00000378
eip=f97f8c4b esp=f452565c ebp=f4525680 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

WINDGB_OUTPUT + REGISTERS_END

Also the I grabbed the memory of the URB, which looks OK.

MEMORY @ 8276ef28

8276ef28 d8 00 0a 00 00 00 00 00 50 d6 f5 81 02 00 00 00 9c 39
…P…9
8276ef3a fe 81 01 00 00 00 a0 00 00 00 60 4f a3 82 e8 ad f4 81
…O......<br>8276ef4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <br>..................<br>8276ef5e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <br>..................<br>8276ef70 07 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 10 00 <br>..................<br>8276ef82 00 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 00 <br>..................<br>8276ef94 20 00 00 00 10 00 00 00 00 00 00 00 30 00 00 00 10 00 <br>...........0.....<br>8276efa6 00 00 00 00 00 00 40 00 00 00 10 00 00 00 00 00 00 00 <br>......@...........<br>8276efb8 50 00 00 00 10 00 00 00 00 00 00 00 60 00 00 00 10 00 <br>P...........…
8276efca 00 00 00 00 00 00 70 00 00 00 10 00 00 00 00 00 00 00
…p…
8276efdc 80 00 00 00 10 00 00 00 00 00 00 00 90 00 00 00 10 00
…
8276efee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
…
8276f000 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
???

MEMORY_END

One point of cunfusion I have is the URB header length. It is not clear
from the documentation if this field is the total length of the URB
including the ISO Packet array, the footprint in memory of the entire
structure or the sum of the size of all the structure componants.

I guess I’ll sleep on it and take another look from the beginning tomorrow.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
1) I would zero out the URB allocation before initializing the fields.
2) looking at the following code which has the violation

f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

I would dump eax and eax+10a and compare the values to purbURB and
pvTemp and see if they are within the range of those 2 allocations. Also
see if 0x10a is an offset into the urb, perhaps into the IsoPacket
array.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Sunday, April 16, 2006 4:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Access violation using WDF & USB Isochronous Pipes

I’m running into an Access Violation problem using WDF with Isochronous.

I’ve had no problems performing Bulk, Interrupt and Control transfers,
but
Isochronous transfers are causing me a headache.

I’ve been through the DDK documentation and I’m confident I’m following
the
instructions correctly.
I’m trying to read 160 bytes, broken down into 10, 16 byte packets. I
build
the URB and when I try to send synchronously I get an access violation.

In this example I create a URB in a new buffer, and create a new buffer
to
hold the 160bytes, and simply try to read data into the new buffer.

I’ve posted the code segment + the output from windbg.

I’d appreciate any help, even just a pointer in the right direction for
some
good documentation on chasing down this problem.

Chris.

CODE SEGMENT

//create new URB in buffer
ULONG ulURB, i;
PURB purbURB; //pointer to new URB in new Buffer
PVOID pvTemp; //pointer to new buffer used to recieve data from
read
request
ulURB = GET_ISO_URB_SIZE(10);

purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
purbURB->UrbIsochronousTransfer.Hdr.Function =
URB_FUNCTION_ISOCH_TRANSFER ;
purbURB->UrbIsochronousTransfer.Hdr.Length = (short)ulURB;
purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
purbURB->UrbIsochronousTransfer.TransferFlags =
USBD_TRANSFER_DIRECTION_IN;
purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
purbURB->UrbIsochronousTransfer.StartFrame =
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;
purbURB->UrbIsochronousTransfer.UrbLink = NULL;

for(i = 0; i <10; i++){
KdPrint((“Setting Iso Desc %d\n”, i));
purbURB->UrbIsochronousTransfer.IsoPacket[i].Offset = i*16;
purbURB->UrbIsochronousTransfer.IsoPacket[i].Length = 16;
}

KdPrint((“Sending Packet\n”));
status =
WdfUsbTargetPipeSendUrbSynchronously(upPipe,NULL,&(pDevContext->wrsoRead
WriteOptions),purbURB);
ExFreePool((PVOID)purbURB);
ExFreePool(pvTemp);
if (NT_SUCCESS(status)) {
KdPrint((“Send success\n”));

}else{
KdPrint((“Send Failed\n”));
}

WINDBG OUTPUT

Setting Iso Desc 0
Setting Iso Desc 1
Setting Iso Desc 2
Setting Iso Desc 3
Setting Iso Desc 4
Setting Iso Desc 5
Setting Iso Desc 6
Setting Iso Desc 7
Setting Iso Desc 8
Setting Iso Desc 9
Sending Packet
Access violation - code c0000005 (!!! second chance !!!)
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

I think Hdr.Length is fine. I am pretty sure you need to use
NonPagedPool for your URB and buffer though.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Sunday, April 16, 2006 9:35 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

Well I managed to get a little further, but not much,

I adjusted the code to zero out both buffers,.

CODE_SEGMENT

//create new URB in buffer
ULONG ulURB, i;
PURB purbURB; //pointer to new URB in new Buffer
PVOID pvTemp; //pointer to new buffer used to recieve data from
read
request
UCHAR* ucData;
ulURB = GET_ISO_URB_SIZE(10);

purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
//0 out both buffers
ucData = (UCHAR*)purbURB;
for(i = 0; i KdPrint((“Zero purbURB %d\n”, i));
(ucData + i) = 0;
}

ucData = (UCHAR)pvTemp;
for(i = 0; i <160; i++){
KdPrint((“Zero pvTemp %d\n”, i));
(ucData + i) = 0;
}
KdPrint((“Address of URB = 0x%x\n”, purbURB));
KdPrint((“URB GET_ISO_URB_SIZE Macro result = 0x%x\n”, ulURB));
KdPrint((“Current frame 0x%x\n”,
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER));

purbURB->UrbIsochronousTransfer.Hdr.Function =
URB_FUNCTION_ISOCH_TRANSFER ;
purbURB->UrbIsochronousTransfer.Hdr.Length = (USHORT)ulURB ;
purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
purbURB->UrbIsochronousTransfer.TransferFlags =
USBD_TRANSFER_DIRECTION_IN;
purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
purbURB->UrbIsochronousTransfer.StartFrame =
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;
purbURB->UrbIsochronousTransfer.UrbLink = NULL;

for(i = 0; i <10; i++){
KdPrint((“Setting Iso Desc %d\n”, i));
purbURB->UrbIsochronousTransfer.IsoPacket[i].Offset = i16;
purbURB->UrbIsochronousTransfer.IsoPacket[i].Length = 16;
}

KdPrint((“Sending Packet\n”));
status =
WdfUsbTargetPipeSendUrbSynchronously(upPipe,NULL,&(pDevContext->wrsoRead
WriteOptions),purbURB);
ExFreePool((PVOID)purbURB);
ExFreePool(pvTemp);
if (NT_SUCCESS(status)) {
KdPrint((“Send success\n”));

}else{
KdPrint((“Send Failed\n”));
}
CODE_SEGMENT_END

I dumped the registers, the value of eax doesn’t seem valid, ebx is the
address of the URB.
Also the offset of 0x10a is bigger than the URB size 0xd8, calculated
using
GET_ISO_URB_SIZE(numpackets) macro.

WINDGB_OUTPUT + REGISTERS

Address of URB = 0x8276ef28
URB GET_ISO_URB_SIZE Macro result = 0xd8
Current frame 0x7
Setting Iso Desc 0
Setting Iso Desc 1
Setting Iso Desc 2
Setting Iso Desc 3
Setting Iso Desc 4
Setting Iso Desc 5
Setting Iso Desc 6
Setting Iso Desc 7
Setting Iso Desc 8
Setting Iso Desc 9
Sending Packet
Access violation - code c0000005 (!!! second chance !!!)
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
kd> r
eax=ffffffff ebx=8276ef28 ecx=00000000 edx=00000394 esi=81dc59f0
edi=00000378
eip=f97f8c4b esp=f452565c ebp=f4525680 iopl=0 nv up ei ng nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

WINDGB_OUTPUT + REGISTERS_END

Also the I grabbed the memory of the URB, which looks OK.

MEMORY @ 8276ef28

8276ef28 d8 00 0a 00 00 00 00 00 50 d6 f5 81 02 00 00 00 9c 39
…P…9
8276ef3a fe 81 01 00 00 00 a0 00 00 00 60 4f a3 82 e8 ad f4 81
…O......<br>8276ef4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <br>..................<br>8276ef5e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <br>..................<br>8276ef70 07 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 10 00 <br>..................<br>8276ef82 00 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 00 <br>..................<br>8276ef94 20 00 00 00 10 00 00 00 00 00 00 00 30 00 00 00 10 00 <br>...........0.....<br>8276efa6 00 00 00 00 00 00 40 00 00 00 10 00 00 00 00 00 00 00 <br>......@...........<br>8276efb8 50 00 00 00 10 00 00 00 00 00 00 00 60 00 00 00 10 00 <br>P...........…
8276efca 00 00 00 00 00 00 70 00 00 00 10 00 00 00 00 00 00 00
…p…
8276efdc 80 00 00 00 10 00 00 00 00 00 00 00 90 00 00 00 10 00
…
8276efee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
…
8276f000 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
???

MEMORY_END

One point of cunfusion I have is the URB header length. It is not clear

from the documentation if this field is the total length of the URB
including the ISO Packet array, the footprint in memory of the entire
structure or the sum of the size of all the structure componants.

I guess I’ll sleep on it and take another look from the beginning
tomorrow.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
1) I would zero out the URB allocation before initializing the fields.
2) looking at the following code which has the violation

f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

I would dump eax and eax+10a and compare the values to purbURB and
pvTemp and see if they are within the range of those 2 allocations. Also
see if 0x10a is an offset into the urb, perhaps into the IsoPacket
array.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Sunday, April 16, 2006 4:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Access violation using WDF & USB Isochronous Pipes

I’m running into an Access Violation problem using WDF with Isochronous.

I’ve had no problems performing Bulk, Interrupt and Control transfers,
but
Isochronous transfers are causing me a headache.

I’ve been through the DDK documentation and I’m confident I’m following
the
instructions correctly.
I’m trying to read 160 bytes, broken down into 10, 16 byte packets. I
build
the URB and when I try to send synchronously I get an access violation.

In this example I create a URB in a new buffer, and create a new buffer
to
hold the 160bytes, and simply try to read data into the new buffer.

I’ve posted the code segment + the output from windbg.

I’d appreciate any help, even just a pointer in the right direction for
some
good documentation on chasing down this problem.

Chris.

CODE SEGMENT

//create new URB in buffer
ULONG ulURB, i;
PURB purbURB; //pointer to new URB in new Buffer
PVOID pvTemp; //pointer to new buffer used to recieve data from
read
request
ulURB = GET_ISO_URB_SIZE(10);

purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
purbURB->UrbIsochronousTransfer.Hdr.Function =
URB_FUNCTION_ISOCH_TRANSFER ;
purbURB->UrbIsochronousTransfer.Hdr.Length = (short)ulURB;
purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
purbURB->UrbIsochronousTransfer.TransferFlags =
USBD_TRANSFER_DIRECTION_IN;
purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
purbURB->UrbIsochronousTransfer.StartFrame =
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;
purbURB->UrbIsochronousTransfer.UrbLink = NULL;

for(i = 0; i <10; i++){
KdPrint((“Setting Iso Desc %d\n”, i));
purbURB->UrbIsochronousTransfer.IsoPacket[i].Offset = i*16;
purbURB->UrbIsochronousTransfer.IsoPacket[i].Length = 16;
}

KdPrint((“Sending Packet\n”));
status =
WdfUsbTargetPipeSendUrbSynchronously(upPipe,NULL,&(pDevContext->wrsoRead
WriteOptions),purbURB);
ExFreePool((PVOID)purbURB);
ExFreePool(pvTemp);
if (NT_SUCCESS(status)) {
KdPrint((“Send success\n”));

}else{
KdPrint((“Send Failed\n”));
}

WINDBG OUTPUT

Setting Iso Desc 0
Setting Iso Desc 1
Setting Iso Desc 2
Setting Iso Desc 3
Setting Iso Desc 4
Setting Iso Desc 5
Setting Iso Desc 6
Setting Iso Desc 7
Setting Iso Desc 8
Setting Iso Desc 9
Sending Packet
Access violation - code c0000005 (!!! second chance !!!)
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

> Also the I grabbed the memory of the URB, which looks OK.

MEMORY @ 8276ef28

Try “dt 8276ef28 _URB”

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

6

xxxxx@cox.net wrote:

I’ve posted the code segment + the output from windbg.

I’d appreciate any help, even just a pointer in the right direction for some
good documentation on chasing down this problem.

Chris.

CODE SEGMENT

//create new URB in buffer
ULONG ulURB, i;
PURB purbURB; //pointer to new URB in new Buffer
PVOID pvTemp; //pointer to new buffer used to recieve data from read
request
ulURB = GET_ISO_URB_SIZE(10);

purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
purbURB->UrbIsochronousTransfer.Hdr.Function =
URB_FUNCTION_ISOCH_TRANSFER ;
purbURB->UrbIsochronousTransfer.Hdr.Length = (short)ulURB;
purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
purbURB->UrbIsochronousTransfer.TransferFlags =
USBD_TRANSFER_DIRECTION_IN;
purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
purbURB->UrbIsochronousTransfer.StartFrame =
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;

You know, that last statement doesn’t do what you think it does
URB_FUNCTION_GET_CURRENT_FRAME_NUMBER, as the name implies, is a URB
function, that gets passed in a separate URB via the Hdr.Function
field. That symbol happens to have the value 7, so what you’re saying
there is that this particular transfer should wait until the frame
number is equal to 7, mod 256.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

Thanks for the heads up Tim,
I grabbed the correct current frame using;

WdfUsbTargetDeviceRetrieveCurrentFrameNumber(
IN WDFUSBDEVICE UsbDevice,
OUT PULONG CurrentFrameNumber
);

however the Access Violation remains.

I used the “dt” command on the _URB as suggested and all looks well. The
only thing I didn’t expect was the initialized _MDL, I passed NULL as the
MDL param, so WDF must have initialized it for me, however it does look
accurate.

Before I setup the URB I grab all the WDF interface and Pipe Data, along
with the Pipe handle. I then determine the transfer type based on the Pipe
Type, setup the URB accordingly and send.

The Interrupt and Bulk transfers have never caused me any problems, so I’m
confident in the code up to the point where I build the Isochronous URB.
The only difference apart from the transfer type is the Interface index. In
my successfull Interrupt and Bulk transfers I’ve always accessed endpoints
in interface index 0. In the Isochronous transfer I’m trying to read from
and endpoint in Interface index 1.

The device is configured for multiple interfaces.

So as far as I understand, the Access Violation occurs at

Access violation - code c0000005 (!!! second chance !!!)
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

With “movzx eax,byte ptr [eax+0x10a]” being the offending operation, at an
offset of “+0x1d5” from the nearest Symbol “USBPORT!USBPORT_AllocTransfer”.

Where movzx will copy the contents of eax+0x10a into eax with a zero extend.

The current value of eax ma be the cause of the porblem;

kd> r
eax=ffffffff ebx=82b96f28 ecx=00000000 edx=00000394 esi=81caa958
edi=00000378
eip=f97f8c4b esp=f482865c ebp=f4828680 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

So I’ll try and trace the back to see how it got in that state, then I
should be able to figure out which of the initial args to
WdfUsbTargetDeviceSendUrbSynchronously
it’s unhappy with.

I’m a Newbie at this, so I’m quite confident that my implementation of the
_URB_ISOCH_TRANSFER
is most likely the problem. I’ll also double check that _MDL.

Chris

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>I’ve posted the code segment + the output from windbg.
>>
>>I’d appreciate any help, even just a pointer in the right direction for
>>some
>>good documentation on chasing down this problem.
>>
>>Chris.
>>
>>CODE SEGMENT
>>
>>//create new URB in buffer
>> ULONG ulURB, i;
>> PURB purbURB; //pointer to new URB in new Buffer
>> PVOID pvTemp; //pointer to new buffer used to recieve data from read
>>request
>> ulURB = GET_ISO_URB_SIZE(10);
>>
>> purbURB = (PURB)ExAllocatePoolWithTag(PagedPool, ulURB, ‘meme’);
>> pvTemp = ExAllocatePoolWithTag(PagedPool, 160, ‘mema’);
>> purbURB->UrbIsochronousTransfer.Hdr.Function =
>>URB_FUNCTION_ISOCH_TRANSFER ;
>> purbURB->UrbIsochronousTransfer.Hdr.Length = (short)ulURB;
>> purbURB->UrbIsochronousTransfer.PipeHandle = hUSBPipe;
>> purbURB->UrbIsochronousTransfer.TransferFlags =
>>USBD_TRANSFER_DIRECTION_IN;
>> purbURB->UrbIsochronousTransfer.NumberOfPackets = 10;
>> purbURB->UrbIsochronousTransfer.TransferBufferLength = 160;
>> purbURB->UrbIsochronousTransfer.TransferBuffer = pvTemp;
>> purbURB->UrbIsochronousTransfer.TransferBufferMDL = NULL;
>> purbURB->UrbIsochronousTransfer.StartFrame =
>>URB_FUNCTION_GET_CURRENT_FRAME_NUMBER;
>>
>>
>
> You know, that last statement doesn’t do what you think it does
> URB_FUNCTION_GET_CURRENT_FRAME_NUMBER, as the name implies, is a URB
> function, that gets passed in a separate URB via the Hdr.Function
> field. That symbol happens to have the value 7, so what you’re saying
> there is that this particular transfer should wait until the frame
> number is equal to 7, mod 256.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

8

xxxxx@cox.net wrote:

Thanks for the heads up Tim,
I grabbed the correct current frame using;

WdfUsbTargetDeviceRetrieveCurrentFrameNumber(
IN WDFUSBDEVICE UsbDevice,
OUT PULONG CurrentFrameNumber
);

however the Access Violation remains.

And, as Doron suggested, did you change your to allocations to use
NonPagedPool instead of PagedPool?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

Yes,

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>Thanks for the heads up Tim,
>> I grabbed the correct current frame using;
>>
>>WdfUsbTargetDeviceRetrieveCurrentFrameNumber(
>> IN WDFUSBDEVICE UsbDevice,
>> OUT PULONG CurrentFrameNumber
>> );
>>
>>however the Access Violation remains.
>>
>>
>
> And, as Doron suggested, did you change your to allocations to use
> NonPagedPool instead of PagedPool?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

10

xxxxx@cox.net wrote:

Yes,

Is this a USB 2.0 device? What’s the isochronous rate?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

I’ll need to reboot my test PC and grab that info.

Just so I can get this down, before I reboot;

I un assembled prior to and inclusding the problem command;

USBPORT!USBPORT_AllocTransfer+0x1c0:
f97f8c36 8900 mov [eax],eax
f97f8c38 7420 jz USBPORT!USBPORT_AllocTransfer+0x1e4
(f97f8c5a)
f97f8c3a 8b45ec mov eax,[ebp-0x14]
f97f8c3d 03c6 add eax,esi
f97f8c3f 898694000000 mov [esi+0x94],eax
f97f8c45 8b45f0 mov eax,[ebp-0x10]
f97f8c48 8b4014 mov eax,[eax+0x14]
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

The last line is the problem line with the access violation.

If you read the third to last line,
f97f8c45 8b45f0 mov eax,[ebp-0x10]

The value held at [ebp-0x10] is actually the USBD_PIPE_HANDLE in the URB
(coincidence?)

REGISTERS, SEE EBP
kd> r
eax=ffffffff ebx=82b96f28 ecx=00000000 edx=00000394 esi=81caa958
edi=00000378
eip=f97f8c4b esp=f482865c ebp=f4828680 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

DDS_REF OF EBP-0x10 = F4828670, SEE USBD_PIPE_HANDLE of 0x82111854 at
location 0xf4828670

kd> dds F4828670
f4828670 82111854
f4828674 00000001
f4828678 00000278
f482867c 00000378

DT OF URB @ 82b96f28. SEE PipeHandle.

kd> dt 82b96f28 _URB_ISOCH_TRANSFER
+0x000 Hdr : _URB_HEADER
+0x010 PipeHandle : 0x82111854
+0x014 TransferFlags : 1
+0x018 TransferBufferLength : 0xa0
+0x01c TransferBuffer : 0x82cbaf60
+0x020 TransferBufferMDL : 0x81d48b00 _MDL
+0x024 UrbLink : (null)
+0x028 hca : _URB_HCD_AREA
+0x048 StartFrame : 0x99240
+0x04c NumberOfPackets : 0xa
+0x050 ErrorCount : 0
+0x054 IsoPacket : [1] _USBD_ISO_PACKET_DESCRIPTOR

The next command says
f97f8c48 8b4014 mov eax,[eax+0x14]

Take the value at location [eax+0x14] and put it in eax.
eax currently holds the USBD_PIPE_HANDLE , so we are specifically being
asked for the value held at a memory location 20 bytes after the memory
location indicated by the pipe handle.

MEMORY VIEW

kd> dds 0x82111854
82111854 48706950
82111858 01830507
8211185c 00010000
82111860 00000002
82111864 00000000
82111868 ffffffff
8211186c 820cd574
82111870 8211184c
82111874 00000000

As you can see, this value is FFFFFFFF, which is what we see in eax as it
tries to perform
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

So that is where the FFFFFFFF in eax comes from.

The next question is… How do I determine the purpose of this value based
only knowing that it exists 20 bytes into the PipeHandle address?
Or maybe the next question should be, am I chasing the wrong thing here?

In the meantime I’ll get the USB version and Isoch rate.

Chris

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>Yes,
>>
>>
>
> Is this a USB 2.0 device? What’s the isochronous rate?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

12

Are you sure the pipe handle is still valid? Perhaps you selected
another setting and now the pipe handle that you previously captured is
no longer valid. Remember that when you change settings on an
interface, all the previous values (WDFUSBPIPE, USBD_PIPE_HANDLE) are
now gone.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 6:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

I’ll need to reboot my test PC and grab that info.

Just so I can get this down, before I reboot;

I un assembled prior to and inclusding the problem command;

USBPORT!USBPORT_AllocTransfer+0x1c0:
f97f8c36 8900 mov [eax],eax
f97f8c38 7420 jz USBPORT!USBPORT_AllocTransfer+0x1e4
(f97f8c5a)
f97f8c3a 8b45ec mov eax,[ebp-0x14]
f97f8c3d 03c6 add eax,esi
f97f8c3f 898694000000 mov [esi+0x94],eax
f97f8c45 8b45f0 mov eax,[ebp-0x10]
f97f8c48 8b4014 mov eax,[eax+0x14]
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

The last line is the problem line with the access violation.

If you read the third to last line,
f97f8c45 8b45f0 mov eax,[ebp-0x10]

The value held at [ebp-0x10] is actually the USBD_PIPE_HANDLE in the
URB
(coincidence?)

REGISTERS, SEE EBP
kd> r
eax=ffffffff ebx=82b96f28 ecx=00000000 edx=00000394 esi=81caa958
edi=00000378
eip=f97f8c4b esp=f482865c ebp=f4828680 iopl=0 nv up ei ng nz na
pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

DDS_REF OF EBP-0x10 = F4828670, SEE USBD_PIPE_HANDLE of 0x82111854 at
location 0xf4828670

kd> dds F4828670
f4828670 82111854
f4828674 00000001
f4828678 00000278
f482867c 00000378

DT OF URB @ 82b96f28. SEE PipeHandle.

kd> dt 82b96f28 _URB_ISOCH_TRANSFER
+0x000 Hdr : _URB_HEADER
+0x010 PipeHandle : 0x82111854
+0x014 TransferFlags : 1
+0x018 TransferBufferLength : 0xa0
+0x01c TransferBuffer : 0x82cbaf60
+0x020 TransferBufferMDL : 0x81d48b00 _MDL
+0x024 UrbLink : (null)
+0x028 hca : _URB_HCD_AREA
+0x048 StartFrame : 0x99240
+0x04c NumberOfPackets : 0xa
+0x050 ErrorCount : 0
+0x054 IsoPacket : [1] _USBD_ISO_PACKET_DESCRIPTOR

The next command says
f97f8c48 8b4014 mov eax,[eax+0x14]

Take the value at location [eax+0x14] and put it in eax.
eax currently holds the USBD_PIPE_HANDLE , so we are specifically being
asked for the value held at a memory location 20 bytes after the memory
location indicated by the pipe handle.

MEMORY VIEW

kd> dds 0x82111854
82111854 48706950
82111858 01830507
8211185c 00010000
82111860 00000002
82111864 00000000
82111868 ffffffff
8211186c 820cd574
82111870 8211184c
82111874 00000000

As you can see, this value is FFFFFFFF, which is what we see in eax as
it
tries to perform
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

So that is where the FFFFFFFF in eax comes from.

The next question is… How do I determine the purpose of this value
based
only knowing that it exists 20 bytes into the PipeHandle address?
Or maybe the next question should be, am I chasing the wrong thing here?

In the meantime I’ll get the USB version and Isoch rate.

Chris

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>Yes,
>>
>>
>
> Is this a USB 2.0 device? What’s the isochronous rate?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

Tim/Doron

I found the problem.

The USB device in question is a BlueTooth dongle.

The Isochronous pipe I was attempting to read was Interface 1, alternate
setting 0, Pipe address 0x83.
The doc http://www.bluetooth.org/foundry/adopters/document/HCI_USB/
shows the USB spec for Bluetooth, page 788 has a table
showing the isochronous pipe config settings.

The Interface config I was trying to use is shown as having max packet
0, and is labeled as “No Voice Channels”.
Reading from Interface 1, alternate setting 0, endpoint 0x83 gives me
the access violation.
If I change Interface 1 to use alternate setting 1 I can read from
endpoint 0x83 without causing the access violation.

I’m going to perform more tests, reading and writing to Interface 1 on
settings 1,2,3,4 and 5, but so far it look s like reading from interface 1
setting 0 is what was causing the problem.

I’ll let you know how I get on.

Thanks for the help.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Are you sure the pipe handle is still valid? Perhaps you selected
another setting and now the pipe handle that you previously captured is
no longer valid. Remember that when you change settings on an
interface, all the previous values (WDFUSBPIPE, USBD_PIPE_HANDLE) are
now gone.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 6:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

I’ll need to reboot my test PC and grab that info.

Just so I can get this down, before I reboot;

I un assembled prior to and inclusding the problem command;

USBPORT!USBPORT_AllocTransfer+0x1c0:
f97f8c36 8900 mov [eax],eax
f97f8c38 7420 jz USBPORT!USBPORT_AllocTransfer+0x1e4
(f97f8c5a)
f97f8c3a 8b45ec mov eax,[ebp-0x14]
f97f8c3d 03c6 add eax,esi
f97f8c3f 898694000000 mov [esi+0x94],eax
f97f8c45 8b45f0 mov eax,[ebp-0x10]
f97f8c48 8b4014 mov eax,[eax+0x14]
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

The last line is the problem line with the access violation.

If you read the third to last line,
f97f8c45 8b45f0 mov eax,[ebp-0x10]

The value held at [ebp-0x10] is actually the USBD_PIPE_HANDLE in the
URB
(coincidence?)

REGISTERS, SEE EBP
kd> r
eax=ffffffff ebx=82b96f28 ecx=00000000 edx=00000394 esi=81caa958
edi=00000378
eip=f97f8c4b esp=f482865c ebp=f4828680 iopl=0 nv up ei ng nz na
pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

DDS_REF OF EBP-0x10 = F4828670, SEE USBD_PIPE_HANDLE of 0x82111854 at
location 0xf4828670

kd> dds F4828670
f4828670 82111854
f4828674 00000001
f4828678 00000278
f482867c 00000378

DT OF URB @ 82b96f28. SEE PipeHandle.

kd> dt 82b96f28 _URB_ISOCH_TRANSFER
+0x000 Hdr : _URB_HEADER
+0x010 PipeHandle : 0x82111854
+0x014 TransferFlags : 1
+0x018 TransferBufferLength : 0xa0
+0x01c TransferBuffer : 0x82cbaf60
+0x020 TransferBufferMDL : 0x81d48b00 _MDL
+0x024 UrbLink : (null)
+0x028 hca : _URB_HCD_AREA
+0x048 StartFrame : 0x99240
+0x04c NumberOfPackets : 0xa
+0x050 ErrorCount : 0
+0x054 IsoPacket : [1] _USBD_ISO_PACKET_DESCRIPTOR

The next command says
f97f8c48 8b4014 mov eax,[eax+0x14]

Take the value at location [eax+0x14] and put it in eax.
eax currently holds the USBD_PIPE_HANDLE , so we are specifically being
asked for the value held at a memory location 20 bytes after the memory
location indicated by the pipe handle.

MEMORY VIEW

kd> dds 0x82111854
82111854 48706950
82111858 01830507
8211185c 00010000
82111860 00000002
82111864 00000000
82111868 ffffffff
8211186c 820cd574
82111870 8211184c
82111874 00000000

As you can see, this value is FFFFFFFF, which is what we see in eax as
it
tries to perform
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

So that is where the FFFFFFFF in eax comes from.

The next question is… How do I determine the purpose of this value
based
only knowing that it exists 20 bytes into the PipeHandle address?
Or maybe the next question should be, am I chasing the wrong thing here?

In the meantime I’ll get the USB version and Isoch rate.

Chris

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>Yes,
>>
>>
>
> Is this a USB 2.0 device? What’s the isochronous rate?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

14

If the setting does not use any bandwidth, how do expect transfers to
work?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 8:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

Tim/Doron

I found the problem.

The USB device in question is a BlueTooth dongle.

The Isochronous pipe I was attempting to read was Interface 1,
alternate
setting 0, Pipe address 0x83.
The doc http://www.bluetooth.org/foundry/adopters/document/HCI_USB/
shows the USB spec for Bluetooth, page 788 has a table
showing the isochronous pipe config settings.

The Interface config I was trying to use is shown as having max
packet
0, and is labeled as “No Voice Channels”.
Reading from Interface 1, alternate setting 0, endpoint 0x83 gives
me
the access violation.
If I change Interface 1 to use alternate setting 1 I can read from
endpoint 0x83 without causing the access violation.

I’m going to perform more tests, reading and writing to Interface 1
on
settings 1,2,3,4 and 5, but so far it look s like reading from interface
1
setting 0 is what was causing the problem.

I’ll let you know how I get on.

Thanks for the help.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Are you sure the pipe handle is still valid? Perhaps you selected
another setting and now the pipe handle that you previously captured is
no longer valid. Remember that when you change settings on an
interface, all the previous values (WDFUSBPIPE, USBD_PIPE_HANDLE) are
now gone.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 6:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

I’ll need to reboot my test PC and grab that info.

Just so I can get this down, before I reboot;

I un assembled prior to and inclusding the problem command;

USBPORT!USBPORT_AllocTransfer+0x1c0:
f97f8c36 8900 mov [eax],eax
f97f8c38 7420 jz USBPORT!USBPORT_AllocTransfer+0x1e4
(f97f8c5a)
f97f8c3a 8b45ec mov eax,[ebp-0x14]
f97f8c3d 03c6 add eax,esi
f97f8c3f 898694000000 mov [esi+0x94],eax
f97f8c45 8b45f0 mov eax,[ebp-0x10]
f97f8c48 8b4014 mov eax,[eax+0x14]
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

The last line is the problem line with the access violation.

If you read the third to last line,
f97f8c45 8b45f0 mov eax,[ebp-0x10]

The value held at [ebp-0x10] is actually the USBD_PIPE_HANDLE in the
URB
(coincidence?)

REGISTERS, SEE EBP
kd> r
eax=ffffffff ebx=82b96f28 ecx=00000000 edx=00000394 esi=81caa958
edi=00000378
eip=f97f8c4b esp=f482865c ebp=f4828680 iopl=0 nv up ei ng nz na
pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

DDS_REF OF EBP-0x10 = F4828670, SEE USBD_PIPE_HANDLE of 0x82111854 at
location 0xf4828670

kd> dds F4828670
f4828670 82111854
f4828674 00000001
f4828678 00000278
f482867c 00000378

DT OF URB @ 82b96f28. SEE PipeHandle.

kd> dt 82b96f28 _URB_ISOCH_TRANSFER
+0x000 Hdr : _URB_HEADER
+0x010 PipeHandle : 0x82111854
+0x014 TransferFlags : 1
+0x018 TransferBufferLength : 0xa0
+0x01c TransferBuffer : 0x82cbaf60
+0x020 TransferBufferMDL : 0x81d48b00 _MDL
+0x024 UrbLink : (null)
+0x028 hca : _URB_HCD_AREA
+0x048 StartFrame : 0x99240
+0x04c NumberOfPackets : 0xa
+0x050 ErrorCount : 0
+0x054 IsoPacket : [1] _USBD_ISO_PACKET_DESCRIPTOR

The next command says
f97f8c48 8b4014 mov eax,[eax+0x14]

Take the value at location [eax+0x14] and put it in eax.
eax currently holds the USBD_PIPE_HANDLE , so we are specifically being
asked for the value held at a memory location 20 bytes after the memory
location indicated by the pipe handle.

MEMORY VIEW

kd> dds 0x82111854
82111854 48706950
82111858 01830507
8211185c 00010000
82111860 00000002
82111864 00000000
82111868 ffffffff
8211186c 820cd574
82111870 8211184c
82111874 00000000

As you can see, this value is FFFFFFFF, which is what we see in eax as
it
tries to perform
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

So that is where the FFFFFFFF in eax comes from.

The next question is… How do I determine the purpose of this value
based
only knowing that it exists 20 bytes into the PipeHandle address?
Or maybe the next question should be, am I chasing the wrong thing here?

In the meantime I’ll get the USB version and Isoch rate.

Chris

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>Yes,
>>
>>
>
> Is this a USB 2.0 device? What’s the isochronous rate?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

15

Doron / Tim

My fault for not noticing the 0 bandwidth, but in my defense…

I’d expect a timeout or failure of the transfer such as an ntstatus failure
message from the WdfUsbTargetDeviceSendUrbSynchronously. The Access
Violation had me believing I’d submitted an invalid/corrupted data, all the
parameters I passed were valid, with the exception there was no bandwidth
available.

If I was to write a generic USB driver I’d have to check the Endpoint
MaxPacket value every time I perform an Isochronous operation, that would
add permanent overhead. If the read/write to an endpoint without bandwidth
would fail graciously the overhead would be eliminated.

I’m a VoIP engineer by profession and I provide technical support to other
engineers maintaining/installing VoIP systems.
I know how frustrating it can be walking Newbie’s through resolving
problems, particularly if it’s one they created themselves.

I appreciate all the help.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
If the setting does not use any bandwidth, how do expect transfers to
work?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 8:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

Tim/Doron

I found the problem.

The USB device in question is a BlueTooth dongle.

The Isochronous pipe I was attempting to read was Interface 1,
alternate
setting 0, Pipe address 0x83.
The doc http://www.bluetooth.org/foundry/adopters/document/HCI_USB/
shows the USB spec for Bluetooth, page 788 has a table
showing the isochronous pipe config settings.

The Interface config I was trying to use is shown as having max
packet
0, and is labeled as “No Voice Channels”.
Reading from Interface 1, alternate setting 0, endpoint 0x83 gives
me
the access violation.
If I change Interface 1 to use alternate setting 1 I can read from
endpoint 0x83 without causing the access violation.

I’m going to perform more tests, reading and writing to Interface 1
on
settings 1,2,3,4 and 5, but so far it look s like reading from interface
1
setting 0 is what was causing the problem.

I’ll let you know how I get on.

Thanks for the help.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Are you sure the pipe handle is still valid? Perhaps you selected
another setting and now the pipe handle that you previously captured is
no longer valid. Remember that when you change settings on an
interface, all the previous values (WDFUSBPIPE, USBD_PIPE_HANDLE) are
now gone.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 6:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

I’ll need to reboot my test PC and grab that info.

Just so I can get this down, before I reboot;

I un assembled prior to and inclusding the problem command;

USBPORT!USBPORT_AllocTransfer+0x1c0:
f97f8c36 8900 mov [eax],eax
f97f8c38 7420 jz USBPORT!USBPORT_AllocTransfer+0x1e4
(f97f8c5a)
f97f8c3a 8b45ec mov eax,[ebp-0x14]
f97f8c3d 03c6 add eax,esi
f97f8c3f 898694000000 mov [esi+0x94],eax
f97f8c45 8b45f0 mov eax,[ebp-0x10]
f97f8c48 8b4014 mov eax,[eax+0x14]
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

The last line is the problem line with the access violation.

If you read the third to last line,
f97f8c45 8b45f0 mov eax,[ebp-0x10]

The value held at [ebp-0x10] is actually the USBD_PIPE_HANDLE in the
URB
(coincidence?)

REGISTERS, SEE EBP
kd> r
eax=ffffffff ebx=82b96f28 ecx=00000000 edx=00000394 esi=81caa958
edi=00000378
eip=f97f8c4b esp=f482865c ebp=f4828680 iopl=0 nv up ei ng nz na
pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

DDS_REF OF EBP-0x10 = F4828670, SEE USBD_PIPE_HANDLE of 0x82111854 at
location 0xf4828670

kd> dds F4828670
f4828670 82111854
f4828674 00000001
f4828678 00000278
f482867c 00000378

DT OF URB @ 82b96f28. SEE PipeHandle.

kd> dt 82b96f28 _URB_ISOCH_TRANSFER
+0x000 Hdr : _URB_HEADER
+0x010 PipeHandle : 0x82111854
+0x014 TransferFlags : 1
+0x018 TransferBufferLength : 0xa0
+0x01c TransferBuffer : 0x82cbaf60
+0x020 TransferBufferMDL : 0x81d48b00 _MDL
+0x024 UrbLink : (null)
+0x028 hca : _URB_HCD_AREA
+0x048 StartFrame : 0x99240
+0x04c NumberOfPackets : 0xa
+0x050 ErrorCount : 0
+0x054 IsoPacket : [1] _USBD_ISO_PACKET_DESCRIPTOR

The next command says
f97f8c48 8b4014 mov eax,[eax+0x14]

Take the value at location [eax+0x14] and put it in eax.
eax currently holds the USBD_PIPE_HANDLE , so we are specifically being
asked for the value held at a memory location 20 bytes after the memory
location indicated by the pipe handle.

MEMORY VIEW

kd> dds 0x82111854
82111854 48706950
82111858 01830507
8211185c 00010000
82111860 00000002
82111864 00000000
82111868 ffffffff
8211186c 820cd574
82111870 8211184c
82111874 00000000

As you can see, this value is FFFFFFFF, which is what we see in eax as
it
tries to perform
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

So that is where the FFFFFFFF in eax comes from.

The next question is… How do I determine the purpose of this value
based
only knowing that it exists 20 bytes into the PipeHandle address?
Or maybe the next question should be, am I chasing the wrong thing here?

In the meantime I’ll get the USB version and Isoch rate.

Chris

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>Yes,
>>
>>
>
> Is this a USB 2.0 device? What’s the isochronous rate?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

16

At some point, the client driver writer has to know what is going on.
It is a fine line between runtime validation and speed when designing a
DDI. Such a check IMO belongs in the client driver b/c it is specific
to the client’s protocol with the endpoint and not a generic check.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Tuesday, April 18, 2006 12:27 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

Doron / Tim

My fault for not noticing the 0 bandwidth, but in my defense…

I’d expect a timeout or failure of the transfer such as an ntstatus
failure
message from the WdfUsbTargetDeviceSendUrbSynchronously. The Access
Violation had me believing I’d submitted an invalid/corrupted data, all
the
parameters I passed were valid, with the exception there was no
bandwidth
available.

If I was to write a generic USB driver I’d have to check the Endpoint
MaxPacket value every time I perform an Isochronous operation, that
would
add permanent overhead. If the read/write to an endpoint without
bandwidth
would fail graciously the overhead would be eliminated.

I’m a VoIP engineer by profession and I provide technical support to
other
engineers maintaining/installing VoIP systems.
I know how frustrating it can be walking Newbie’s through resolving
problems, particularly if it’s one they created themselves.

I appreciate all the help.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
If the setting does not use any bandwidth, how do expect transfers to
work?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 8:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

Tim/Doron

I found the problem.

The USB device in question is a BlueTooth dongle.

The Isochronous pipe I was attempting to read was Interface 1,
alternate
setting 0, Pipe address 0x83.
The doc http://www.bluetooth.org/foundry/adopters/document/HCI_USB/
shows the USB spec for Bluetooth, page 788 has a table
showing the isochronous pipe config settings.

The Interface config I was trying to use is shown as having max
packet
0, and is labeled as “No Voice Channels”.
Reading from Interface 1, alternate setting 0, endpoint 0x83 gives
me
the access violation.
If I change Interface 1 to use alternate setting 1 I can read from
endpoint 0x83 without causing the access violation.

I’m going to perform more tests, reading and writing to Interface 1
on
settings 1,2,3,4 and 5, but so far it look s like reading from interface
1
setting 0 is what was causing the problem.

I’ll let you know how I get on.

Thanks for the help.

Chris

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Are you sure the pipe handle is still valid? Perhaps you selected
another setting and now the pipe handle that you previously captured is
no longer valid. Remember that when you change settings on an
interface, all the previous values (WDFUSBPIPE, USBD_PIPE_HANDLE) are
now gone.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Monday, April 17, 2006 6:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Access violation using WDF & USB Isochronous Pipes

I’ll need to reboot my test PC and grab that info.

Just so I can get this down, before I reboot;

I un assembled prior to and inclusding the problem command;

USBPORT!USBPORT_AllocTransfer+0x1c0:
f97f8c36 8900 mov [eax],eax
f97f8c38 7420 jz USBPORT!USBPORT_AllocTransfer+0x1e4
(f97f8c5a)
f97f8c3a 8b45ec mov eax,[ebp-0x14]
f97f8c3d 03c6 add eax,esi
f97f8c3f 898694000000 mov [esi+0x94],eax
f97f8c45 8b45f0 mov eax,[ebp-0x10]
f97f8c48 8b4014 mov eax,[eax+0x14]
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

The last line is the problem line with the access violation.

If you read the third to last line,
f97f8c45 8b45f0 mov eax,[ebp-0x10]

The value held at [ebp-0x10] is actually the USBD_PIPE_HANDLE in the
URB
(coincidence?)

REGISTERS, SEE EBP
kd> r
eax=ffffffff ebx=82b96f28 ecx=00000000 edx=00000394 esi=81caa958
edi=00000378
eip=f97f8c4b esp=f482865c ebp=f4828680 iopl=0 nv up ei ng nz na
pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
USBPORT!USBPORT_AllocTransfer+0x1d5:
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]
ds:0023:00000109=??

DDS_REF OF EBP-0x10 = F4828670, SEE USBD_PIPE_HANDLE of 0x82111854 at
location 0xf4828670

kd> dds F4828670
f4828670 82111854
f4828674 00000001
f4828678 00000278
f482867c 00000378

DT OF URB @ 82b96f28. SEE PipeHandle.

kd> dt 82b96f28 _URB_ISOCH_TRANSFER
+0x000 Hdr : _URB_HEADER
+0x010 PipeHandle : 0x82111854
+0x014 TransferFlags : 1
+0x018 TransferBufferLength : 0xa0
+0x01c TransferBuffer : 0x82cbaf60
+0x020 TransferBufferMDL : 0x81d48b00 _MDL
+0x024 UrbLink : (null)
+0x028 hca : _URB_HCD_AREA
+0x048 StartFrame : 0x99240
+0x04c NumberOfPackets : 0xa
+0x050 ErrorCount : 0
+0x054 IsoPacket : [1] _USBD_ISO_PACKET_DESCRIPTOR

The next command says
f97f8c48 8b4014 mov eax,[eax+0x14]

Take the value at location [eax+0x14] and put it in eax.
eax currently holds the USBD_PIPE_HANDLE , so we are specifically being
asked for the value held at a memory location 20 bytes after the memory
location indicated by the pipe handle.

MEMORY VIEW

kd> dds 0x82111854
82111854 48706950
82111858 01830507
8211185c 00010000
82111860 00000002
82111864 00000000
82111868 ffffffff
8211186c 820cd574
82111870 8211184c
82111874 00000000

As you can see, this value is FFFFFFFF, which is what we see in eax as
it
tries to perform
f97f8c4b 0fb6800a010000 movzx eax,byte ptr [eax+0x10a]

So that is where the FFFFFFFF in eax comes from.

The next question is… How do I determine the purpose of this value
based
only knowing that it exists 20 bytes into the PipeHandle address?
Or maybe the next question should be, am I chasing the wrong thing here?

In the meantime I’ll get the USB version and Isoch rate.

Chris

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@cox.net wrote:
>
>>Yes,
>>
>>
>
> Is this a USB 2.0 device? What’s the isochronous rate?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer