Error message: "exception - code 80000003 (first chance)" ?

[bluestar]

Dear Sir:

I used the below to run on XP and it can send successfully.
But I run on Vista and WinDbg will show below message when
tracing into WdfUsbTargetPipeWriteSynchronously.

"WARNING: This break is not a step/trace completion.
The last command has been cleared to prevent
accidental continuation of this unrelated event.
Check the event, location and thread before resuming.
Break instruction exception - code 80000003 (first chance)"

What's wrong with my code or I miss something?
Could anyone tell me how to fix this issue?

Thanks for your kindly help.

//---------------------------------------------------------------------------------//
typedef struct _CMD_BLOCK_WRAPPER {
ULONG uldCBWSignature;
ULONG uldCBWTag;
ULONG uldCBWDataTransferLength;
UCHAR ucbmCBWFlags;
UCHAR ucbCBWLUN;
UCHAR ucbCBWCBLength;
UCHAR ucCBWCB[0x10];
} CMD_BLOCK_WRAPPER, *PCMD_BLOCK_WRAPPER ;
//---------------------------------------------------------------------------------//
NTSTATUS status = STATUS_SUCCESS;
PDEVICE_CONTEXT pDeviceContext;
WDF_MEMORY_DESCRIPTOR outputDesc;
size_t INLength;
ULONG nReturn , nDataBufferOffset;
ULONGLONG ullTimeOut;
BOOLEAN bDir; //true: Read_IN; false: Write_OUT
PVOID INBuffer = 0;
PSCSI_PASS_THROUGH pSCSI_CMD;
CMD_BLOCK_WRAPPER CBW;
LARGE_INTEGER CurrentTime;
WDF_REQUEST_SEND_OPTIONS objOptions;

pDeviceContext = GetDeviceContext(WdfIoQueueGetDevice(Queue));
status = WdfRequestRetrieveInputBuffer(Request, InputBufferLength,
&INBuffer, &INLength);
if (!NT_SUCCESS(status)) {
*((PULONG)BytesReadOrWritten) = 0;
goto Exit;
}
bDir = FALSE; //true: Read_IN; false: Write_OUT
pSCSI_CMD = (PSCSI_PASS_THROUGH)INBuffer;
KeQuerySystemTime(&CurrentTime);
CBW.uldCBWSignature = 0x43425355;
CBW.uldCBWTag = CurrentTime.u.LowPart;
CBW.uldCBWDataTransferLength = pSCSI_CMD->DataTransferLength;
if(pSCSI_CMD->DataIn == SCSI_IOCTL_DATA_IN )
{
CBW.ucbmCBWFlags = 0x80;
bDir = TRUE; //true: Read_IN; false: Write_OUT
}
else if (pSCSI_CMD->DataIn == SCSI_IOCTL_DATA_OUT )
CBW.ucbmCBWFlags = 0x00;
else
CBW.ucbmCBWFlags = 0x00;
CBW.ucbCBWLUN = pSCSI_CMD->Lun;
CBW.ucbCBWCBLength = MAX_CDB_LENGTH;
RtlCopyMemory(&CBW.ucCBWCB, pSCSI_CMD->Cdb, CBW.ucbCBWCBLength);
ullTimeOut = pSCSI_CMD->TimeOutValue;
nDataBufferOffset = pSCSI_CMD->DataBufferOffset;

WDF_REQUEST_SEND_OPTIONS_INIT(&objOptions,
(WDF_REQUEST_SEND_OPTION_TIMEOUT|
WDF_REQUEST_SEND_OPTION_SYNCHRONOUS) );
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&objOptions,
WDF_REL_TIMEOUT_IN_SEC(ullTimeOut) );
WDF_MEMORY_DESCRIPTOR_INIT_BUFFER(&outputDesc,
(PVOID)&CBW,
31);
status = WdfUsbTargetPipeWriteSynchronously(pDeviceContext-
>BulkOUTPipe, NULL,
&objOptions,
&outputDesc,
&nReturn); ===> Crash
Message
if (!NT_SUCCESS(status)) {
*((PULONG)BytesReadOrWritten) = 0;
goto Exit;
}

[bluestar]

I use "!analyze -v" to see something, and it shows below information.
Does WdfUsbTargetPipeWriteSynchronously function fail???
How to interpret these information?

//--------------------------------------------------------------------------------------------------------//
PROCESS_NAME: FPTest.exe

FAULTING_IP:
nt!DbgBreakPoint+0
8184a8ea cc int 3

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 8184a8ea (nt!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8366b030
Parameter[2]: 00000000

ERROR_CODE: (NTSTATUS) 0x80000003 - {

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x0

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 851bd1db to 8184a8ea

STACK_TEXT:
91b629a0 851bd1db 83507f28 851bd1db 835e6f18 nt!DbgBreakPoint
91b629d4 98c26c66 835e6fd0 7ca750f0 00000000 Wdf01000!
imp_WdfUsbTargetPipeWriteSynchronously+0x73
91b629f4 98c26761 7ca750f0 00000000 91b62a38 fpldrv!
WdfUsbTargetPipeWriteSynchronously+0x26 [c:\winddk\6001.18001

\inc\wdf\kmdf\1.7\wdfusb.h @ 1653]
91b62b18 98c2bdd4 7cbce1e8 7caf80d0 00000050 fpldrv!
FPLUsbIoctlProcedure+0x411 [d:\prolific\driver\plfinger\bulkrwr.c @
1004]
91b62b6c 851ed514 7cbce1e8 7caf80d0 00000050 fpldrv!
FingerEvtIoDeviceControl+0x1d4 [d:\prolific\driver\plfinger\queue.c @

261]
91b62b90 851ee924 7cbce1e8 7caf80d0 00000050 Wdf01000!
FxIoQueueIoDeviceControl::Invoke+0x30
91b62bc0 851f0fb8 7caf80d0 83507f28 83431e10 Wdf01000!
FxIoQueue::DispatchRequestToDriver+0x445
91b62be0 851f2722 83431e00 85218188 83431e10 Wdf01000!
FxIoQueue::DispatchEvents+0x4e9
91b62bfc 851f385d 00000000 833cfd68 834ad398 Wdf01000!
FxIoQueue::QueueRequest+0x237
91b62c20 851e2665 8356eb20 91b62c44 8184a1ad Wdf01000!FxPkgIo::Dispatch
+0x377
91b62c2c 8184a1ad 834ad398 8356eb20 8356eb20 Wdf01000!
FxDevice::Dispatch+0x7f
91b62c44 819f6f64 833cfd68 8356eb20 8356ec20 nt!IofCallDriver+0x63
91b62c64 81a01940 834ad398 833cfd68 0012cb00 nt!
IopSynchronousServiceTail+0x1d9
91b62d00 81a336cf 834ad398 8356eb20 00000000 nt!IopXxxControlFile
+0x6b7
91b62d34 8185b9aa 00000104 00000000 00000000 nt!NtDeviceIoControlFile
+0x2a
91b62d34 77099a94 00000104 00000000 00000000 nt!KiFastCallEntry+0x12a
0012cb54 77098444 75c2c2a3 00000104 00000000 ntdll!KiFastSystemCallRet
0012cb58 75c2c2a3 00000104 00000000 00000000 ntdll!
ZwDeviceIoControlFile+0xc
0012cbb8 004025b6 00000104 0004d004 0012cbe8 kernel32!DeviceIoControl
+0x14a
WARNING: Stack unwind information not available. Following frames may
be wrong.
0012f440 00402bf5 00000016 00000053 000000a2 FPTest+0x25b6
0012f47c 00408099 0012fa38 000003ef 00000000 FPTest+0x2bf5
0012f4ac 00407640 000003ef 00000000 00000000 FPTest+0x8099
0012f4d0 0040bc03 000003ef 00000000 00000000 FPTest+0x7640
0012f520 0040c617 00000000 000101b0 02ca50ba FPTest+0xbc03
0012f5bc 00408f8f 00000111 000003ef 000101b0 FPTest+0xc617
0012f5dc 0040b0e0 00000111 000003ef 000101b0 FPTest+0x8f8f
0012f644 0040b16d 00000000 000201a6 00000111 FPTest+0xb0e0
0012f664 7642f8d2 000201a6 00000111 000003ef FPTest+0xb16d
0012f690 7642f794 0040b139 000201a6 00000111 USER32!InternalCallWinProc
+0x23
0012f708 76430a05 00000000 0040b139 000201a6 USER32!
UserCallWinProcCheckWow+0x14b
0012f748 76430afa 009434b0 00943448 000003ef USER32!SendMessageWorker
+0x4b7
0012f768 7461f94f 000201a6 00000111 000003ef USER32!SendMessageW+0x7c
0012f788 7461f9b1 00260cb8 00000000 0015002c COMCTL32!
Button_NotifyParent+0x3d
0012f7a4 7461fc97 50010001 00000001 0012f880 COMCTL32!
Button_ReleaseCapture+0x112
0012f804 7642f8d2 000101b0 00000202 00000000 COMCTL32!Button_WndProc
+0xa98
0012f830 7642f794 7463d1e1 000101b0 00000202 USER32!InternalCallWinProc
+0x23
0012f8a8 76430008 00000000 7463d1e1 000101b0 USER32!
UserCallWinProcCheckWow+0x14b
0012f90c 76430060 7463d1e1 00000000 0012f940 USER32!
DispatchMessageWorker+0x322
0012f91c 7641af07 0025f300 0025f300 0012fa38 USER32!DispatchMessageW
+0xf
0012f940 0040d6d5 000201a6 00944a48 0012fa38 USER32!IsDialogMessageW
+0x586
0012f950 00409314 0025f300 00407620 0025f300 FPTest+0xd6d5
0012fa38 00000000 00000000 00000000 00000000 FPTest+0x9314

STACK_COMMAND: kb

FOLLOWUP_IP:
fpldrv!WdfUsbTargetPipeWriteSynchronously+26 [c:\winddk\6001.18001\inc
\wdf\kmdf\1.7\wdfusb.h @ 1653]
98c26c66 5d pop ebp

FAULTING_SOURCE_CODE:
1649: PULONG BytesWritten
1650: )
1651: {
1652: return ((PFN_WDFUSBTARGETPIPEWRITESYNCHRONOUSLY)
WdfFunctions[WdfUsbTargetPipeWriteSynchronouslyTableIndex])
(WdfDriverGlobals, Pipe, Request, RequestOptions, MemoryDescriptor,
BytesWritten);
> 1653: }
1654:
1655: //
1656: // WDF Function: WdfUsbTargetPipeFormatRequestForWrite
1657: //
1658: typedef

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: fpldrv!WdfUsbTargetPipeWriteSynchronously+26

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: fpldrv

IMAGE_NAME: fpldrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48e601c4

FAILURE_BUCKET_ID: 0x0_fpldrv!WdfUsbTargetPipeWriteSynchronously+26

BUCKET_ID: 0x0_fpldrv!WdfUsbTargetPipeWriteSynchronously+26

Followup: MachineOwner

[Abhishek R [MSFT]]

Have you verified that the handle to the USB output pipe is still valid
(pDeviceContext->BulkOUTPipe)? The !wdfkd.wdfusbpipe debugger extension can
be used to verify this.

"bluestar" <bluest...@gmail.com> wrote in message
news:89029631-a38e-4b96...@l64g2000hse.googlegroups.com...

[Tim Roberts]

bluestar <bluest...@gmail.com> wrote:
>
>I use "!analyze -v" to see something, and it shows below information.
>Does WdfUsbTargetPipeWriteSynchronously function fail???
>How to interpret these information?

This is an "assert". WdfUsbTargetPipeWriteSynchronously has detected an
error condition, and has halted the system to prevent damage. If you look
at the wdflogdump in the debugger, you'll be able to see what it was
complaining about.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[bluestar]

Dear Abhishek:

I tried to use !wdfkd.wdfusbpipe to verify Pipe handle,
and I think it is ok for it. It returns Below Message:

pDeviceContext->BulkOUTPipe ===> 0x7cfdd298 struct WDFUSBPIPE__ *

0: kd> !wdfkd.wdfusbpipe 0x7cfdd298

WDFUSBPIPE 7cfdd298
===========================
Type UsbdPipeTypeBulk
Direction Out
MaxPacket 0x40, Max Transfer 0x400000
Endpoint Address 0x1
USBD_PIPE_HANDLE 830ec28c

!WDFUSBDEVICE 7ca79620
!WDFUSBINTERFACE 7cac9978

[bluestar]

Dear Tim:

I used !wdfkd.wdflogdump to dump log file and found the
error is IRQL is not correct when I call
WdfUsbTargetPipeWriteSynchronously.
(below message)
Could I use "Wait Locks" to force IRQL=PASSIVE_LEVEL(level 0) when
calling my function:UsbIoctlProcedure in EvtIoDeviceControl
(below code)? Or use other method to force IRQL to specific level?

By the way, I am very confused that what'a different between XP and
Vista
when running this function by using the same code?

Thanks for your kindly help.

//------------------------------------------------------------------------------------//

257: imp_WdfUsbTargetPipeWriteSynchronously - WDFUSBPIPE 7CFDD298
258: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2,
should be at level 0

//------------------------------------------------------------------------------------//
VOID EvtIoDeviceControl(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
NTSTATUS status;
ULONG length = 0;
switch(IoControlCode) {
case IOCTL_SCSI_PASS_THROUGH:
{
status = UsbIoctlProcedure(Queue, Request, OutputBufferLength,
InputBufferLength, IoControlCode, &length);
WdfRequestSetInformation(Request, length);
break;
}
default :
status = STATUS_INVALID_DEVICE_REQUEST;
break;
}
WdfRequestCompleteWithInformation(Request, status, length);
return;
}

__drv_requiresIRQL(PASSIVE_LEVEL)
NTSTATUS
UsbIoctlProcedure(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoctlControlCode,
OUT PULONG BytesReadOrWritten
)
{

NTSTATUS status = STATUS_SUCCESS;
PDEVICE_CONTEXT pDeviceContext;
WDF_MEMORY_DESCRIPTOR outputDesc;

CMD_BLOCK_WRAPPER CBW;
WDF_REQUEST_SEND_OPTIONS objOptions;

pDeviceContext = GetDeviceContext(WdfIoQueueGetDevice(Queue));
...code omitted

WDF_REQUEST_SEND_OPTIONS_INIT(&objOptions,
(WDF_REQUEST_SEND_OPTION_TIMEOUT|
WDF_REQUEST_SEND_OPTION_SYNCHRONOUS) );
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&objOptions,
WDF_REL_TIMEOUT_IN_SEC(ullTimeOut) );
WDF_MEMORY_DESCRIPTOR_INIT_BUFFER(&outputDesc,
(PVOID)&CBW,
31);
status = WdfUsbTargetPipeWriteSynchronously(pDeviceContext-
>BulkOUTPipe,

NULL, &objOptions, &outputDesc, &nReturn); ===> dump log after
crash

[Doron Holan [MSFT]]

are you explicitly acquiring a lock or are you setting sync scope on your
queue or device?

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"bluestar" <bluest...@gmail.com> wrote in message

news:7e3da702-22be-490d...@b2g2000prf.googlegroups.com...

[Tim Roberts]

bluestar <bluest...@gmail.com> wrote:
>
> I tried to use !wdfkd.wdfusbpipe to verify Pipe handle,
>and I think it is ok for it. It returns Below Message:
>
>pDeviceContext->BulkOUTPipe ===> 0x7cfdd298 struct WDFUSBPIPE__ *
>
>0: kd> !wdfkd.wdfusbpipe 0x7cfdd298
>
>WDFUSBPIPE 7cfdd298
>===========================
>Type UsbdPipeTypeBulk
>Direction Out
>MaxPacket 0x40, Max Transfer 0x400000
>Endpoint Address 0x1
>USBD_PIPE_HANDLE 830ec28c

Is this a USB 1.x device?

If it is a USB 2.0 device, then your descriptors are wrong. A bulk pipe
must have max packet size of 512.

[bluestar]

Dear Tim:

It's a USB 1.1 device, not for USB2.0

On 10月7日, 上午9時57分, Tim Roberts <t...@probo.com> wrote:
> Is this a USB 1.x device?
>
> If it is a USB 2.0 device, then your descriptors are wrong. A bulk pipe
> must have max packet size of 512.
> --

> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.- 隱藏被引用文字 -
>
> - 顯示被引用文字 -

[bluestar]

Dear Doron:

I used the below to solve this question.
Could you tell me is it good solution?

//---------------------------------------------------------------------------------//
NTSTATUS
EvtDeviceAdd(...)
{
...code omitted...
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&fdoAttributes,
DEVICE_CONTEXT);
fdoAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
fdoAttributes.ExecutionLevel = WdfExecutionLevelPassive;
status = WdfDeviceCreate(&DeviceInit, &fdoAttributes, &device);
...code omitted...

WDF_OBJECT_ATTRIBUTES_INIT(&lockAttributes);
lockAttributes.ParentObject = device;
status = WdfWaitLockCreate(&lockAttributes,
&pDevContext->IoctlWaitLock
);

}

NTSTATUS
UsbIoctlProcedure()
{
...code omitted...
WdfWaitLockAcquire(pDeviceContext->IoctlWaitLock, &ullLockTimeOut);

status = WdfUsbTargetPipeWriteSynchronously(pDeviceContext-
>BulkOUTPipe,
NULL,
&objOptions,
&outputDesc,
&nReturn);

WdfWaitLockRelease(pDeviceContext->IoctlWaitLock);
}

[Doron Holan [MSFT]]

if UsbIoctlProcedure is only being called in an IOCTL callback routine for
an IOCTL request, there is no need for IoctlWaitLock, KMDF will make sure
that no 2 requests will be runing concurrently

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"bluestar" <bluest...@gmail.com> wrote in message

news:1ddc115b-561c-4635...@o40g2000prn.googlegroups.com...

[bluestar]

Dear Doron:

Yes, UsbIoctlProcedure is only being called in an IOCTL
callback
routine for an IOCTL request.

I use IoctlWaitLock to force IRQL to level 0(Passive),
because
at first my idea is the same as what you say, but when running in
Vista,
it happens the above question.

Or you mean I only set ExecutionLevel is
WdfExecutionLevelPassive
in EvtDeviceAdd, is it ok for Vista and XP?

[Doron Holan [MSFT]]

locks can only raise iRQL, the cannot lower them. a wdfwaitlock is
acquirable at passive level and does not raise the IRQL once acquired. you
only need to set the sync scop to device and execution level to device and
all of your ioqueue callbacks will be synchronized against each other w/out
addtional locks in your driver

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"bluestar" <bluest...@gmail.com> wrote in message

news:e220e234-484b-485b...@r15g2000prh.googlegroups.com...

[bluestar]

Dear Doron:

Thanks for your explanation.

I will only set ExecutionLevel is WdfExecutionLevelPassive
in EvtDeviceAdd when creating Device.

Thank you.

WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&fdoAttributes,
DEVICE_CONTEXT);
fdoAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
fdoAttributes.ExecutionLevel = WdfExecutionLevelPassive;
status = WdfDeviceCreate(&DeviceInit, &fdoAttributes, &device);

On 10月9日, 上午4時04分, "Doron Holan [MSFT]" <dor...@online.microsoft.com>
wrote: