Prev: Please HELP - Analyzing IRQL_NOT_LESS_OR_EQUAL
Next: PcCardConfig M Option
From: Bobby Mattappally [MS] on 9 Sep 2005 18:16
Hi Manfred,

One solution to avoid the hang would be to do an asynchronous (Overlapped
IO) Read/Write operation and Cancel the IO after a predefined time out and
retry the operations.
Is there a reason you are opening the device on your own to do the the Read
and Write instead of using the ReadPort/WritePort functions exposed by the
port monitor? The inbox USB port monitor does its Read and Write using
Asynchronous IO with settable timeout values. You can also modify the
timeout value by using pfnSetPortTimeout method exposed by the port monitor.

Also have you investigated whether you could use the below I/O control
codes instead of the Write/Read option?

IOCTL_USBPRINT_VENDOR_GET_COMMAND
IOCTL_USBPRINT_VENDOR_SET_COMMAND



Hope this helps.

Thank you,
Bobby Mattappally
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.



--------------------
From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
<KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
Subject: Re: USB device access via DeviceIoControl and WriteFile / ReadFile
Date: Fri, 9 Sep 2005 14:45:15 -0400

Hello Martin,

Here is what I am doing.

I open a file handle

hDevice = CreateFile ( pTmpPort->DevicePath,

GENERIC_WRITE | GENERIC_READ, // read/write access

FILE_SHARE_READ | FILE_SHARE_WRITE,

NULL, // no SECURITY_ATTRIBUTES structure

OPEN_EXISTING, // No special create flags

0,//FILE_FLAG_OVERLAPPED, // No special attributes

NULL); // No template file

I send an IOCTL_USBPRINT_GET_1284_ID

IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, NULL, 0,

pszLPID,255, &ReturnedLength, NULL);

and then a WriteFile to the same device handle.

if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength,

NULL)) == 0)

Once the write is done and came back OK I am trying to do a ReadFile

IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength, NULL);

This ReadFile sometimes never comes back.

but it works on other times.

As you can see in the case that it is not working the printer sends the

result immediately (300 ms) but the PC never reads it and is continuing to

read which gets NAK'ed out.

What can I do?

This happens in the Language Monitor during boot time, can it be that

Windows is flushing the buffer inadvertainly and that is messing me up? Can

I control this somehow?

Thanks for your help,

\Manfred

""Martin Borve [MSFT]"" <martinbo(a)online.microsoft.com> wrote in message
news:KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl...
> Manfred,
>
> I assume you are using the standard USBPRINT driver that ships in Windows
> for your printer, correct?
>
> In that case, USBPRINT will simply submit an async (bulk or interrupt)
> request to the device. If this request is not completing, it's likely
> that
> the device is simply NAKing the transfer request. You can use a bus
> analyzer such as a CATC to verify this.
>
>
> Martin Borve
> Windows DDK Support
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>

From: Manfred Wilner on 12 Sep 2005 11:06
Hi Bobby thank you for your reply,
I didn't realize that the ReadPort/WritePort functions would work since it
is the USB I am talking to but I will give it a try. How would you suggest
canceling after timeout?

Yes I have implemented the vendor commands but need the ReadPort/WritePort
functions for backwards compatibility during first intialization.

\Manfred



"Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message
news:41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl...
> Hi Manfred,
>
> One solution to avoid the hang would be to do an asynchronous
> (Overlapped
> IO) Read/Write operation and Cancel the IO after a predefined time out and
> retry the operations.
> Is there a reason you are opening the device on your own to do the the
> Read
> and Write instead of using the ReadPort/WritePort functions exposed by the
> port monitor? The inbox USB port monitor does its Read and Write using
> Asynchronous IO with settable timeout values. You can also modify the
> timeout value by using pfnSetPortTimeout method exposed by the port
> monitor.
>
> Also have you investigated whether you could use the below I/O control
> codes instead of the Write/Read option?
>
> IOCTL_USBPRINT_VENDOR_GET_COMMAND
> IOCTL_USBPRINT_VENDOR_SET_COMMAND
>
>
>
> Hope this helps.
>
> Thank you,
> Bobby Mattappally
> Microsoft
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>
> --------------------
> From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
> Subject: Re: USB device access via DeviceIoControl and WriteFile /
> ReadFile
> Date: Fri, 9 Sep 2005 14:45:15 -0400
>
> Hello Martin,
>
> Here is what I am doing.
>
> I open a file handle
>
> hDevice = CreateFile ( pTmpPort->DevicePath,
>
> GENERIC_WRITE | GENERIC_READ, // read/write access
>
> FILE_SHARE_READ | FILE_SHARE_WRITE,
>
> NULL, // no SECURITY_ATTRIBUTES structure
>
> OPEN_EXISTING, // No special create flags
>
> 0,//FILE_FLAG_OVERLAPPED, // No special attributes
>
> NULL); // No template file
>
> I send an IOCTL_USBPRINT_GET_1284_ID
>
> IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, NULL,
> 0,
>
> pszLPID,255, &ReturnedLength, NULL);
>
> and then a WriteFile to the same device handle.
>
> if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength,
>
> NULL)) == 0)
>
> Once the write is done and came back OK I am trying to do a ReadFile
>
> IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength, NULL);
>
> This ReadFile sometimes never comes back.
>
> but it works on other times.
>
> As you can see in the case that it is not working the printer sends the
>
> result immediately (300 ms) but the PC never reads it and is continuing to
>
> read which gets NAK'ed out.
>
> What can I do?
>
> This happens in the Language Monitor during boot time, can it be that
>
> Windows is flushing the buffer inadvertainly and that is messing me up?
> Can
>
> I control this somehow?
>
> Thanks for your help,
>
> \Manfred
>
> ""Martin Borve [MSFT]"" <martinbo(a)online.microsoft.com> wrote in message
> news:KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl...
>> Manfred,
>>
>> I assume you are using the standard USBPRINT driver that ships in Windows
>> for your printer, correct?
>>
>> In that case, USBPRINT will simply submit an async (bulk or interrupt)
>> request to the device. If this request is not completing, it's likely
>> that
>> the device is simply NAKing the transfer request. You can use a bus
>> analyzer such as a CATC to verify this.
>>
>>
>> Martin Borve
>> Windows DDK Support
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>
>


From: Bobby Mattappally [MS] on 12 Sep 2005 16:37
Hi Manfred,
>I didn't realize that the ReadPort/WritePort functions would work since it
>is the USB I am talking to but I will give it a try. How would you suggest
>canceling after timeout?

If you are using ReadPort/WritePort, you don't need to do any cancelling,
the port monitor will cancel the operation on timeout and will return false.
So you can decide whether to redo the Read/Write or something else.


Hope this helps.

Thank you,
Bobby Mattappally
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.






--------------------
From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
<KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
<eBrff6WtFHA.2540(a)TK2MSFTNGP09.phx.gbl>
<41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl>
Subject: Re: USB device access via DeviceIoControl and WriteFile / ReadFile
Date: Mon, 12 Sep 2005 11:06:59 -0400


Hi Bobby thank you for your reply,
I didn't realize that the ReadPort/WritePort functions would work since it
is the USB I am talking to but I will give it a try. How would you suggest
canceling after timeout?

Yes I have implemented the vendor commands but need the ReadPort/WritePort
functions for backwards compatibility during first intialization.

\Manfred



"Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message
news:41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl...
> Hi Manfred,
>
> One solution to avoid the hang would be to do an asynchronous
> (Overlapped
> IO) Read/Write operation and Cancel the IO after a predefined time out and
> retry the operations.
> Is there a reason you are opening the device on your own to do the the
> Read
> and Write instead of using the ReadPort/WritePort functions exposed by the
> port monitor? The inbox USB port monitor does its Read and Write using
> Asynchronous IO with settable timeout values. You can also modify the
> timeout value by using pfnSetPortTimeout method exposed by the port
> monitor.
>
> Also have you investigated whether you could use the below I/O control
> codes instead of the Write/Read option?
>
> IOCTL_USBPRINT_VENDOR_GET_COMMAND
> IOCTL_USBPRINT_VENDOR_SET_COMMAND
>
>
>
> Hope this helps.
>
> Thank you,
> Bobby Mattappally
> Microsoft
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>
> --------------------
> From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
> Subject: Re: USB device access via DeviceIoControl and WriteFile /
> ReadFile
> Date: Fri, 9 Sep 2005 14:45:15 -0400
>
> Hello Martin,
>
> Here is what I am doing.
>
> I open a file handle
>
> hDevice = CreateFile ( pTmpPort->DevicePath,
>
> GENERIC_WRITE | GENERIC_READ, // read/write access
>
> FILE_SHARE_READ | FILE_SHARE_WRITE,
>
> NULL, // no SECURITY_ATTRIBUTES structure
>
> OPEN_EXISTING, // No special create flags
>
> 0,//FILE_FLAG_OVERLAPPED, // No special attributes
>
> NULL); // No template file
>
> I send an IOCTL_USBPRINT_GET_1284_ID
>
> IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, NULL,
> 0,
>
> pszLPID,255, &ReturnedLength, NULL);
>
> and then a WriteFile to the same device handle.
>
> if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength,
>
> NULL)) == 0)
>
> Once the write is done and came back OK I am trying to do a ReadFile
>
> IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength, NULL);
>
> This ReadFile sometimes never comes back.
>
> but it works on other times.
>
> As you can see in the case that it is not working the printer sends the
>
> result immediately (300 ms) but the PC never reads it and is continuing to
>
> read which gets NAK'ed out.
>
> What can I do?
>
> This happens in the Language Monitor during boot time, can it be that
>
> Windows is flushing the buffer inadvertainly and that is messing me up?
> Can
>
> I control this somehow?
>
> Thanks for your help,
>
> \Manfred
>
> ""Martin Borve [MSFT]"" <martinbo(a)online.microsoft.com> wrote in message
> news:KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl...
>> Manfred,
>>
>> I assume you are using the standard USBPRINT driver that ships in Windows
>> for your printer, correct?
>>
>> In that case, USBPRINT will simply submit an async (bulk or interrupt)
>> request to the device. If this request is not completing, it's likely
>> that
>> the device is simply NAKing the transfer request. You can use a bus
>> analyzer such as a CATC to verify this.
>>
>>
>> Martin Borve
>> Windows DDK Support
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>
>


From: Manfred Wilner on 13 Sep 2005 15:27
Thank you Bobby this did it!


"Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message
news:eujtPn9tFHA.2328(a)TK2MSFTNGXA01.phx.gbl...
> Hi Manfred,
>>I didn't realize that the ReadPort/WritePort functions would work since it
>>is the USB I am talking to but I will give it a try. How would you suggest
>>canceling after timeout?
>
> If you are using ReadPort/WritePort, you don't need to do any cancelling,
> the port monitor will cancel the operation on timeout and will return
> false.
> So you can decide whether to redo the Read/Write or something else.
>
>
> Hope this helps.
>
> Thank you,
> Bobby Mattappally
> Microsoft
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>
>
>
>
> --------------------
> From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
> <eBrff6WtFHA.2540(a)TK2MSFTNGP09.phx.gbl>
> <41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl>
> Subject: Re: USB device access via DeviceIoControl and WriteFile /
> ReadFile
> Date: Mon, 12 Sep 2005 11:06:59 -0400
>
>
> Hi Bobby thank you for your reply,
> I didn't realize that the ReadPort/WritePort functions would work since it
> is the USB I am talking to but I will give it a try. How would you suggest
> canceling after timeout?
>
> Yes I have implemented the vendor commands but need the ReadPort/WritePort
> functions for backwards compatibility during first intialization.
>
> \Manfred
>
>
>
> "Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message
> news:41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl...
>> Hi Manfred,
>>
>> One solution to avoid the hang would be to do an asynchronous
>> (Overlapped
>> IO) Read/Write operation and Cancel the IO after a predefined time out
>> and
>> retry the operations.
>> Is there a reason you are opening the device on your own to do the the
>> Read
>> and Write instead of using the ReadPort/WritePort functions exposed by
>> the
>> port monitor? The inbox USB port monitor does its Read and Write using
>> Asynchronous IO with settable timeout values. You can also modify the
>> timeout value by using pfnSetPortTimeout method exposed by the port
>> monitor.
>>
>> Also have you investigated whether you could use the below I/O control
>> codes instead of the Write/Read option?
>>
>> IOCTL_USBPRINT_VENDOR_GET_COMMAND
>> IOCTL_USBPRINT_VENDOR_SET_COMMAND
>>
>>
>>
>> Hope this helps.
>>
>> Thank you,
>> Bobby Mattappally
>> Microsoft
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>>
>> --------------------
>> From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
>> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
>> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
>> Subject: Re: USB device access via DeviceIoControl and WriteFile /
>> ReadFile
>> Date: Fri, 9 Sep 2005 14:45:15 -0400
>>
>> Hello Martin,
>>
>> Here is what I am doing.
>>
>> I open a file handle
>>
>> hDevice = CreateFile ( pTmpPort->DevicePath,
>>
>> GENERIC_WRITE | GENERIC_READ, // read/write access
>>
>> FILE_SHARE_READ | FILE_SHARE_WRITE,
>>
>> NULL, // no SECURITY_ATTRIBUTES structure
>>
>> OPEN_EXISTING, // No special create flags
>>
>> 0,//FILE_FLAG_OVERLAPPED, // No special attributes
>>
>> NULL); // No template file
>>
>> I send an IOCTL_USBPRINT_GET_1284_ID
>>
>> IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, NULL,
>> 0,
>>
>> pszLPID,255, &ReturnedLength, NULL);
>>
>> and then a WriteFile to the same device handle.
>>
>> if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength,
>>
>> NULL)) == 0)
>>
>> Once the write is done and came back OK I am trying to do a ReadFile
>>
>> IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength,
>> NULL);
>>
>> This ReadFile sometimes never comes back.
>>
>> but it works on other times.
>>
>> As you can see in the case that it is not working the printer sends the
>>
>> result immediately (300 ms) but the PC never reads it and is continuing
>> to
>>
>> read which gets NAK'ed out.
>>
>> What can I do?
>>
>> This happens in the Language Monitor during boot time, can it be that
>>
>> Windows is flushing the buffer inadvertainly and that is messing me up?
>> Can
>>
>> I control this somehow?
>>
>> Thanks for your help,
>>
>> \Manfred
>>
>> ""Martin Borve [MSFT]"" <martinbo(a)online.microsoft.com> wrote in message
>> news:KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl...
>>> Manfred,
>>>
>>> I assume you are using the standard USBPRINT driver that ships in
>>> Windows
>>> for your printer, correct?
>>>
>>> In that case, USBPRINT will simply submit an async (bulk or interrupt)
>>> request to the device. If this request is not completing, it's likely
>>> that
>>> the device is simply NAKing the transfer request. You can use a bus
>>> analyzer such as a CATC to verify this.
>>>
>>>
>>> Martin Borve
>>> Windows DDK Support
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>
>>>
>>
>>
>
>
>


From: Bobby Mattappally [MS] on 13 Sep 2005 20:45

--------------------
From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
<KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
<eBrff6WtFHA.2540(a)TK2MSFTNGP09.phx.gbl>
<41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl>
<uEWOiu6tFHA.596(a)TK2MSFTNGP12.phx.gbl>
<eujtPn9tFHA.2328(a)TK2MSFTNGXA01.phx.gbl>
Subject: Re: USB device access via DeviceIoControl and WriteFile / ReadFile
Date: Tue, 13 Sep 2005 15:27:20 -0400
Lines: 188

>Thank you Bobby this did it!

Can you clarify?
Did the WritePort/ReadPort sequence succeed in this case (during reboot) ?
Or did you get the ReadPort to fail (timeout) and you had to redo it?



Thank you,
Bobby Mattappally
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.



"Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message
news:eujtPn9tFHA.2328(a)TK2MSFTNGXA01.phx.gbl...
> Hi Manfred,
>>I didn't realize that the ReadPort/WritePort functions would work since it
>>is the USB I am talking to but I will give it a try. How would you suggest
>>canceling after timeout?
>
> If you are using ReadPort/WritePort, you don't need to do any cancelling,
> the port monitor will cancel the operation on timeout and will return
> false.
> So you can decide whether to redo the Read/Write or something else.
>
>
> Hope this helps.
>
> Thank you,
> Bobby Mattappally
> Microsoft
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>
>
>
>
> --------------------
> From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
> <eBrff6WtFHA.2540(a)TK2MSFTNGP09.phx.gbl>
> <41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl>
> Subject: Re: USB device access via DeviceIoControl and WriteFile /
> ReadFile
> Date: Mon, 12 Sep 2005 11:06:59 -0400
>
>
> Hi Bobby thank you for your reply,
> I didn't realize that the ReadPort/WritePort functions would work since it
> is the USB I am talking to but I will give it a try. How would you suggest
> canceling after timeout?
>
> Yes I have implemented the vendor commands but need the ReadPort/WritePort
> functions for backwards compatibility during first intialization.
>
> \Manfred
>
>
>
> "Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message
> news:41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl...
>> Hi Manfred,
>>
>> One solution to avoid the hang would be to do an asynchronous
>> (Overlapped
>> IO) Read/Write operation and Cancel the IO after a predefined time out
>> and
>> retry the operations.
>> Is there a reason you are opening the device on your own to do the the
>> Read
>> and Write instead of using the ReadPort/WritePort functions exposed by
>> the
>> port monitor? The inbox USB port monitor does its Read and Write using
>> Asynchronous IO with settable timeout values. You can also modify the
>> timeout value by using pfnSetPortTimeout method exposed by the port
>> monitor.
>>
>> Also have you investigated whether you could use the below I/O control
>> codes instead of the Write/Read option?
>>
>> IOCTL_USBPRINT_VENDOR_GET_COMMAND
>> IOCTL_USBPRINT_VENDOR_SET_COMMAND
>>
>>
>>
>> Hope this helps.
>>
>> Thank you,
>> Bobby Mattappally
>> Microsoft
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>>
>> --------------------
>> From: "Manfred Wilner" <manfred.w(a)swecoinus.com>
>> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl>
>> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl>
>> Subject: Re: USB device access via DeviceIoControl and WriteFile /
>> ReadFile
>> Date: Fri, 9 Sep 2005 14:45:15 -0400
>>
>> Hello Martin,
>>
>> Here is what I am doing.
>>
>> I open a file handle
>>
>> hDevice = CreateFile ( pTmpPort->DevicePath,
>>
>> GENERIC_WRITE | GENERIC_READ, // read/write access
>>
>> FILE_SHARE_READ | FILE_SHARE_WRITE,
>>
>> NULL, // no SECURITY_ATTRIBUTES structure
>>
>> OPEN_EXISTING, // No special create flags
>>
>> 0,//FILE_FLAG_OVERLAPPED, // No special attributes
>>
>> NULL); // No template file
>>
>> I send an IOCTL_USBPRINT_GET_1284_ID
>>
>> IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, NULL,
>> 0,
>>
>> pszLPID,255, &ReturnedLength, NULL);
>>
>> and then a WriteFile to the same device handle.
>>
>> if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength,
>>
>> NULL)) == 0)
>>
>> Once the write is done and came back OK I am trying to do a ReadFile
>>
>> IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength,
>> NULL);
>>
>> This ReadFile sometimes never comes back.
>>
>> but it works on other times.
>>
>> As you can see in the case that it is not working the printer sends the
>>
>> result immediately (300 ms) but the PC never reads it and is continuing
>> to
>>
>> read which gets NAK'ed out.
>>
>> What can I do?
>>
>> This happens in the Language Monitor during boot time, can it be that
>>
>> Windows is flushing the buffer inadvertainly and that is messing me up?
>> Can
>>
>> I control this somehow?
>>
>> Thanks for your help,
>>
>> \Manfred
>>
>> ""Martin Borve [MSFT]"" <martinbo(a)online.microsoft.com> wrote in message
>> news:KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl...
>>> Manfred,
>>>
>>> I assume you are using the standard USBPRINT driver that ships in
>>> Windows
>>> for your printer, correct?
>>>
>>> In that case, USBPRINT will simply submit an async (bulk or interrupt)
>>> request to the device. If this request is not completing, it's likely
>>> that
>>> the device is simply NAKing the transfer request. You can use a bus
>>> analyzer such as a CATC to verify this.
>>>
>>>
>>> Martin Borve
>>> Windows DDK Support
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>
>>>
>>
>>
>
>
>




Thank you,
Bobby Mattappally
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Please HELP - Analyzing IRQL_NOT_LESS_OR_EQUAL
Next: PcCardConfig M Option