From: Manfred Wilner on
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


From: Tom Picard on
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
>
>
>
From: Manfred Wilner on
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(a)discussions.microsoft.com> wrote in message
news:7938321C-D504-4179-A1D8-43106EFE4FC4(a)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
>>
>>
>>


From: "Martin Borve [MSFT]" on
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
Thank you Martin,
I am using USBPRINT as the default driver and I will try analyzing this
further.

\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.
>
>