I have a strange problem.
In my Language Monitor I am trying to analyze on starting the Monitor after
reboot if the printer attached is my printer and if this printer can
communicate bi-directional.
I am using DeviceIoControl for getting the DeviceID and have no problems
with this.
Then I am using WriteFile and ReadFile with the same handle to see what
firmware version my printer has.
Here begins the problem, sometimes after reboot the ReadFile never returns
unless I reset the power of the printer or reset the USB cable and therefor
get the Windows PnP ping.
Of course my ReadFile will fail and come back with error code 31 (// A
device attached to the system is not functioning.) and thereafter the
WriteFile and ReadFile will work again.

A DeviceIoControl with the same call on a printer that supports this will in
any case work even when the WriteFile and ReadFile will fail.

Can anyone explain this and what can I do to work around this problem?

\Manfred

RE: USB device access via DeviceIoControl and WriteFile / ReadFile by TomPicard

TomPicard
Sat Aug 13 10:36:01 CDT 2005

It sounds like the deviceiocontrol is being called synchronously, the
(function) driver for the printer is pushing a synchronous irp down the
stack, the printer has no data to respond and so the wait (or till irp is
cancelled).

1. whose driver is is the deviceioctl dispatched to?
2. are you sure your printer is responding to the read (do you have a usb
monitor to confirm)?



"Manfred Wilner" wrote:

> I have a strange problem.
> In my Language Monitor I am trying to analyze on starting the Monitor after
> reboot if the printer attached is my printer and if this printer can
> communicate bi-directional.
> I am using DeviceIoControl for getting the DeviceID and have no problems
> with this.
> Then I am using WriteFile and ReadFile with the same handle to see what
> firmware version my printer has.
> Here begins the problem, sometimes after reboot the ReadFile never returns
> unless I reset the power of the printer or reset the USB cable and therefor
> get the Windows PnP ping.
> Of course my ReadFile will fail and come back with error code 31 (// A
> device attached to the system is not functioning.) and thereafter the
> WriteFile and ReadFile will work again.
>
> A DeviceIoControl with the same call on a printer that supports this will in
> any case work even when the WriteFile and ReadFile will fail.
>
> Can anyone explain this and what can I do to work around this problem?
>
> \Manfred
>
>
>

Re: USB device access via DeviceIoControl and WriteFile / ReadFile by Manfred

Manfred
Mon Aug 15 09:58:17 CDT 2005

Thank you, Tom.
The deviceiocontrol really is working and is not the problem I see. My
printer is responding correctly.

The problem is the write- / read-file where the read never comes back.
Do you know if the readfile function to a USB device path is working stable?



"Tom Picard" <TomPicard@discussions.microsoft.com> wrote in message
news:7938321C-D504-4179-A1D8-43106EFE4FC4@microsoft.com...
> It sounds like the deviceiocontrol is being called synchronously, the
> (function) driver for the printer is pushing a synchronous irp down the
> stack, the printer has no data to respond and so the wait (or till irp is
> cancelled).
>
> 1. whose driver is is the deviceioctl dispatched to?
> 2. are you sure your printer is responding to the read (do you have a usb
> monitor to confirm)?
>
>
>
> "Manfred Wilner" wrote:
>
>> I have a strange problem.
>> In my Language Monitor I am trying to analyze on starting the Monitor
>> after
>> reboot if the printer attached is my printer and if this printer can
>> communicate bi-directional.
>> I am using DeviceIoControl for getting the DeviceID and have no problems
>> with this.
>> Then I am using WriteFile and ReadFile with the same handle to see what
>> firmware version my printer has.
>> Here begins the problem, sometimes after reboot the ReadFile never
>> returns
>> unless I reset the power of the printer or reset the USB cable and
>> therefor
>> get the Windows PnP ping.
>> Of course my ReadFile will fail and come back with error code 31 (// A
>> device attached to the system is not functioning.) and thereafter the
>> WriteFile and ReadFile will work again.
>>
>> A DeviceIoControl with the same call on a printer that supports this will
>> in
>> any case work even when the WriteFile and ReadFile will fail.
>>
>> Can anyone explain this and what can I do to work around this problem?
>>
>> \Manfred
>>
>>
>>



RE: USB device access via DeviceIoControl and WriteFile / ReadFile by martinbo

martinbo
Mon Aug 15 18:58:38 CDT 2005

------=_NextPart_0001_1D32D6F5
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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.


------=_NextPart_0001_1D32D6F5
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Manfred,
\par
\par I assume you are using the standard USBPRINT driver that ships in Windows for your printer, correct?
\par
\par 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.
\par
\par
\par Martin Borve
\par Windows DDK Support
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par
\par }
------=_NextPart_0001_1D32D6F5--


Re: USB device access via DeviceIoControl and WriteFile / ReadFile by Manfred

Manfred
Wed Aug 17 10:09:21 CDT 2005

Thank you Martin,
I am using USBPRINT as the default driver and I will try analyzing this
further.

\Manfred

""Martin Borve [MSFT]"" <martinbo@online.microsoft.com> wrote in message
news:KTz7GVfoFHA.944@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.
>
>



Re: USB device access via DeviceIoControl and WriteFile / ReadFile by bobbym

bobbym
Fri Sep 09 17:16:25 CDT 2005

------=_NextPart_0001_9D943C19
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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@swecoinus.com>
References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
<KTz7GVfoFHA.944@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@online.microsoft.com> wrote in message
news:KTz7GVfoFHA.944@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.
>
>


------=_NextPart_0001_9D943C19
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Hi Manfred,
\par
\par 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.
\par 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.
\par
\par Also have you investigated whether you could use the below I/O control codes instead of the Write/Read option?
\par
\par IOCTL_USBPRINT_VENDOR_GET_COMMAND
\par IOCTL_USBPRINT_VENDOR_SET_COMMAND
\par
\par
\par
\par Hope this helps.
\par
\par Thank you,
\par Bobby Mattappally
\par Microsoft
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par
\par \pard\li720 --------------------
\par From: "Manfred Wilner" <manfred.w@swecoinus.com>
\par References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl> <KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl>
\par Subject: Re: USB device access via DeviceIoControl and WriteFile / ReadFile
\par Date: Fri, 9 Sep 2005 14:45:15 -0400
\par
\par Hello Martin,
\par
\par Here is what I am doing.
\par
\par I open a file handle
\par
\par hDevice = CreateFile ( pTmpPort->DevicePath,
\par
\par GENERIC_WRITE | GENERIC_READ, // read/write access
\par
\par FILE_SHARE_READ | FILE_SHARE_WRITE,
\par
\par NULL, // no SECURITY_ATTRIBUTES structure
\par
\par OPEN_EXISTING, // No special create flags
\par
\par 0,//FILE_FLAG_OVERLAPPED, // No special attributes
\par
\par NULL); // No template file
\par
\par I send an IOCTL_USBPRINT_GET_1284_ID
\par
\par IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, NULL, 0,
\par
\par pszLPID,255, &ReturnedLength, NULL);
\par
\par and then a WriteFile to the same device handle.
\par
\par if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength,
\par
\par NULL)) == 0)
\par
\par Once the write is done and came back OK I am trying to do a ReadFile
\par
\par IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength, NULL);
\par
\par This ReadFile sometimes never comes back.
\par
\par but it works on other times.
\par
\par As you can see in the case that it is not working the printer sends the
\par
\par result immediately (300 ms) but the PC never reads it and is continuing to
\par
\par read which gets NAK'ed out.
\par
\par What can I do?
\par
\par This happens in the Language Monitor during boot time, can it be that
\par
\par Windows is flushing the buffer inadvertainly and that is messing me up? Can
\par
\par I control this somehow?
\par
\par Thanks for your help,
\par
\par \\Manfred
\par
\par ""Martin Borve [MSFT]"" <martinbo@online.microsoft.com> wrote in message
\par news:KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl...
\par > Manfred,
\par >
\par > I assume you are using the standard USBPRINT driver that ships in Windows
\par > for your printer, correct?
\par >
\par > In that case, USBPRINT will simply submit an async (bulk or interrupt)
\par > request to the device. If this request is not completing, it's likely
\par > that
\par > the device is simply NAKing the transfer request. You can use a bus
\par > analyzer such as a CATC to verify this.
\par >
\par >
\par > Martin Borve
\par > Windows DDK Support
\par > This posting is provided "AS IS" with no warranties, and confers no
\par > rights.
\par >
\par >
\par
\par
\par \pard
\par }
------=_NextPart_0001_9D943C19--


Re: USB device access via DeviceIoControl and WriteFile / ReadFile by Manfred

Manfred
Mon Sep 12 10:06:59 CDT 2005

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@online.microsoft.com> wrote in message
news:41BRkwYtFHA.780@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@swecoinus.com>
> References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944@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@online.microsoft.com> wrote in message
> news:KTz7GVfoFHA.944@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.
>>
>>
>
>



Re: USB device access via DeviceIoControl and WriteFile / ReadFile by bobbym

bobbym
Mon Sep 12 15:37:33 CDT 2005

------=_NextPart_0001_ACACB0C1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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@swecoinus.com>
References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
<KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl>
<eBrff6WtFHA.2540@TK2MSFTNGP09.phx.gbl>
<41BRkwYtFHA.780@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@online.microsoft.com> wrote in message
news:41BRkwYtFHA.780@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@swecoinus.com>
> References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944@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@online.microsoft.com> wrote in message
> news:KTz7GVfoFHA.944@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.
>>
>>
>
>



------=_NextPart_0001_ACACB0C1
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

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


Re: USB device access via DeviceIoControl and WriteFile / ReadFile by Manfred

Manfred
Tue Sep 13 14:27:20 CDT 2005

Thank you Bobby this did it!


"Bobby Mattappally [MS]" <bobbym@online.microsoft.com> wrote in message
news:eujtPn9tFHA.2328@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@swecoinus.com>
> References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl>
> <eBrff6WtFHA.2540@TK2MSFTNGP09.phx.gbl>
> <41BRkwYtFHA.780@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@online.microsoft.com> wrote in message
> news:41BRkwYtFHA.780@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@swecoinus.com>
>> References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
>> <KTz7GVfoFHA.944@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@online.microsoft.com> wrote in message
>> news:KTz7GVfoFHA.944@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.
>>>
>>>
>>
>>
>
>
>



Re: USB device access via DeviceIoControl and WriteFile / ReadFile by bobbym

bobbym
Tue Sep 13 19:45:53 CDT 2005

------=_NextPart_0001_B29829F0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


--------------------
From: "Manfred Wilner" <manfred.w@swecoinus.com>
References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
<KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl>
<eBrff6WtFHA.2540@TK2MSFTNGP09.phx.gbl>
<41BRkwYtFHA.780@TK2MSFTNGXA01.phx.gbl>
<uEWOiu6tFHA.596@TK2MSFTNGP12.phx.gbl>
<eujtPn9tFHA.2328@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@online.microsoft.com> wrote in message
news:eujtPn9tFHA.2328@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@swecoinus.com>
> References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
> <KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl>
> <eBrff6WtFHA.2540@TK2MSFTNGP09.phx.gbl>
> <41BRkwYtFHA.780@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@online.microsoft.com> wrote in message
> news:41BRkwYtFHA.780@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@swecoinus.com>
>> References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
>> <KTz7GVfoFHA.944@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@online.microsoft.com> wrote in message
>> news:KTz7GVfoFHA.944@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.

------=_NextPart_0001_B29829F0
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20
\par \pard\li720 --------------------
\par From: "Manfred Wilner" <manfred.w@swecoinus.com>
\par References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl> <KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl> <eBrff6WtFHA.2540@TK2MSFTNGP09.phx.gbl> <41BRkwYtFHA.780@TK2MSFTNGXA01.phx.gbl> <uEWOiu6tFHA.596@TK2MSFTNGP12.phx.gbl> <eujtPn9tFHA.2328@TK2MSFTNGXA01.phx.gbl>
\par Subject: Re: USB device access via DeviceIoControl and WriteFile / ReadFile
\par Date: Tue, 13 Sep 2005 15:27:20 -0400
\par Lines: 188
\par
\par >Thank you Bobby this did it!
\par
\par Can you clarify?
\par Did the WritePort/ReadPort sequence succeed in this case (during reboot) ?
\par Or did you get the ReadPort to fail (timeout) and you had to redo it?
\par
\par
\par
\par Thank you,
\par Bobby Mattappally
\par Microsoft
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par
\par "Bobby Mattappally [MS]" <bobbym@online.microsoft.com> wrote in message
\par news:eujtPn9tFHA.2328@TK2MSFTNGXA01.phx.gbl...
\par > Hi Manfred,
\par >>I didn't realize that the ReadPort/WritePort functions would work since it
\par >>is the USB I am talking to but I will give it a try. How would you suggest
\par >>canceling after timeout?
\par >
\par > If you are using ReadPort/WritePort, you don't need to do any cancelling,
\par > the port monitor will cancel the operation on timeout and will return
\par > false.
\par > So you can decide whether to redo the Read/Write or something else.
\par >
\par >
\par > Hope this helps.
\par >
\par > Thank you,
\par > Bobby Mattappally
\par > Microsoft
\par >
\par > This posting is provided "AS IS" with no warranties, and confers no
\par > rights.
\par >
\par >
\par >
\par >
\par >
\par >
\par > --------------------
\par > From: "Manfred Wilner" <manfred.w@swecoinus.com>
\par > References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
\par > <KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl>
\par > <eBrff6WtFHA.2540@TK2MSFTNGP09.phx.gbl>
\par > <41BRkwYtFHA.780@TK2MSFTNGXA01.phx.gbl>
\par > Subject: Re: USB device access via DeviceIoControl and WriteFile /
\par > ReadFile
\par > Date: Mon, 12 Sep 2005 11:06:59 -0400
\par >
\par >
\par > Hi Bobby thank you for your reply,
\par > I didn't realize that the ReadPort/WritePort functions would work since it
\par > is the USB I am talking to but I will give it a try. How would you suggest
\par > canceling after timeout?
\par >
\par > Yes I have implemented the vendor commands but need the ReadPort/WritePort
\par > functions for backwards compatibility during first intialization.
\par >
\par > \\Manfred
\par >
\par >
\par >
\par > "Bobby Mattappally [MS]" <bobbym@online.microsoft.com> wrote in message
\par > news:41BRkwYtFHA.780@TK2MSFTNGXA01.phx.gbl...
\par >> Hi Manfred,
\par >>
\par >> One solution to avoid the hang would be to do an asynchronous
\par >> (Overlapped
\par >> IO) Read/Write operation and Cancel the IO after a predefined time out
\par >> and
\par >> retry the operations.
\par >> Is there a reason you are opening the device on your own to do the the
\par >> Read
\par >> and Write instead of using the ReadPort/WritePort functions exposed by
\par >> the
\par >> port monitor? The inbox USB port monitor does its Read and Write using
\par >> Asynchronous IO with settable timeout values. You can also modify the
\par >> timeout value by using pfnSetPortTimeout method exposed by the port
\par >> monitor.
\par >>
\par >> Also have you investigated whether you could use the below I/O control
\par >> codes instead of the Write/Read option?
\par >>
\par >> IOCTL_USBPRINT_VENDOR_GET_COMMAND
\par >> IOCTL_USBPRINT_VENDOR_SET_COMMAND
\par >>
\par >>
\par >>
\par >> Hope this helps.
\par >>
\par >> Thank you,
\par >> Bobby Mattappally
\par >> Microsoft
\par >>
\par >> This posting is provided "AS IS" with no warranties, and confers no
\par >> rights.
\par >>
\par >>
\par >>
\par >> --------------------
\par >> From: "Manfred Wilner" <manfred.w@swecoinus.com>
\par >> References: <#zRStcrnFHA.1048@tk2msftngp13.phx.gbl>
\par >> <KTz7GVfoFHA.944@TK2MSFTNGXA01.phx.gbl>
\par >> Subject: Re: USB device access via DeviceIoControl and WriteFile /
\par >> ReadFile
\par >> Date: Fri, 9 Sep 2005 14:45:15 -0400
\par >>
\par >> Hello Martin,
\par >>
\par >> Here is what I am doing.
\par >>
\par >> I open a file handle
\par >>
\par >> hDevice = CreateFile ( pTmpPort->DevicePath,
\par >>
\par >> GENERIC_WRITE | GENERIC_READ, // read/write access
\par >>
\par >> FILE_SHARE_READ | FILE_SHARE_WRITE,
\par >>
\par >> NULL, // no SECURITY_ATTRIBUTES structure
\par >>
\par >> OPEN_EXISTING, // No special create flags
\par >>
\par >> 0,//FILE_FLAG_OVERLAPPED, // No special attributes
\par >>
\par >> NULL); // No template file
\par >>
\par >> I send an IOCTL_USBPRINT_GET_1284_ID
\par >>
\par >> IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, NULL,
\par >> 0,
\par >>
\par >> pszLPID,255, &ReturnedLength, NULL);
\par >>
\par >> and then a WriteFile to the same device handle.
\par >>
\par >> if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength,
\par >>
\par >> NULL)) == 0)
\par >>
\par >> Once the write is done and came back OK I am trying to do a ReadFile
\par >>
\par >> IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength,
\par >> NULL);
\par >>
\par >> This ReadFile sometimes never comes back.
\par >>
\par >> but it works on other times.
\par >>
\par >> As