The question is: Can anything in W2K be able to use a port
range, which already used by (assigned to) kernel-mode
driver? If yes, it can, then can I avoid this?
The background.
We have some nonstandard legacy device connected to the
computer via ISA-bus card.
We have the simple kernel driver (slightly
modified “portio” driver from NT 4.0 DDK). The driver
handles only ports IO operation and it does not any
interrupt handling. The driver (and other sowtware) works
fine in NT 4.0 environment.
Recently we have tested the driver under W2K SP3
environment (on the same computer and with exactly the
same hardware) and we found out a problem. The problem
is the follow: when we run our software it successfully
connects the driver and performs requested operations till
one of the keyboard buttons “Enter” or “Esc” is pressed.
Înly this two keys are involved, any others keys seems to
be safety, and it is no difference which application has
input focus. Just after “Enter” or “Esc” is pressed the
device comes in to unexpected state. The unexpected state,
as it seems to me, is the result of some illegal
input/output operation with ports range used by the device
(and its driver). The mentioned illegal input/output
operation seems to be done not via our driver (the driver
can produce a log). And the system reports no conflict for
port range used by our driver.
The question is: Can anything in W2K use a port
range, which already used by (assigned to) kernel-mode
driver? If yes, it can, can I avoid this?
Once you are in kernel mode there is nothing that I know of that can stop
you from doing IO to any port you want to; at least this tends to hold true
on serial and parallel IO devices. So, you could conceiveably write a driver
that writes and reads to COMx at any time it wants. However … in doing
that you will not, and cannot synchronize with the drivers that control
those ports nor can they sync with you. Hence … both of you are going to
step all over each other and it is primarily YOUR fault … although the
good driver will probably be blamed. This is why it is a SUPER bad idea to
run around the system and do direct IO to ports.
NT4 didn’t have a lot things in place that 2000 does, hence you never saw
the synchronization problem on that platform. In all probabilty, you now
need to do things the right way — attach to the PDO/FDO stack and filter
the IO of the port your now trying to control directly.
–
Gary G. Little
Have Computer, will travel …
909-698-3191
909-551-2105
“Oleg E. Aleksandrov” wrote in message
news:xxxxx@ntdev…
>
> The question is: Can anything in W2K be able to use a port
> range, which already used by (assigned to) kernel-mode
> driver? If yes, it can, then can I avoid this?
>
> The background.
> We have some nonstandard legacy device connected to the
> computer via ISA-bus card.
>
> We have the simple kernel driver (slightly
> modified “portio” driver from NT 4.0 DDK). The driver
> handles only ports IO operation and it does not any
> interrupt handling. The driver (and other sowtware) works
> fine in NT 4.0 environment.
>
> Recently we have tested the driver under W2K SP3
> environment (on the same computer and with exactly the
> same hardware) and we found out a problem. The problem
> is the follow: when we run our software it successfully
> connects the driver and performs requested operations till
> one of the keyboard buttons “Enter” or “Esc” is pressed.
> Înly this two keys are involved, any others keys seems to
> be safety, and it is no difference which application has
> input focus. Just after “Enter” or “Esc” is pressed the
> device comes in to unexpected state. The unexpected state,
> as it seems to me, is the result of some illegal
> input/output operation with ports range used by the device
> (and its driver). The mentioned illegal input/output
> operation seems to be done not via our driver (the driver
> can produce a log). And the system reports no conflict for
> port range used by our driver.
>
> The question is: Can anything in W2K use a port
> range, which already used by (assigned to) kernel-mode
> driver? If yes, it can, can I avoid this?
>
>
I see, but you recommendation is wrong. My driver does not use a COMx
ports, it uses the processor IO ports range 0x120-0x127. The system
reports that there is no conflict on that ports. But the device gets the
illegal input/output, and as it seems to me not via my driver.
Citation:
you now
need to do things the right way — attach to the PDO/FDO stack and filter
the IO of the port your now trying to control directly
Yes I have developed the new style pseudo-PnP W2k driver. Guess what I get
… oh…, the same result.
Once you are in kernel mode there is nothing that I know of that can stop
you from doing IO to any port you want to; at least this tends to hold true
on serial and parallel IO devices. So, you could conceiveably write a driver
that writes and reads to COMx at any time it wants. However … in doing
that you will not, and cannot synchronize with the drivers that control
those ports nor can they sync with you. Hence … both of you are going to
step all over each other and it is primarily YOUR fault … although the
good driver will probably be blamed. This is why it is a SUPER bad idea to
run around the system and do direct IO to ports.
NT4 didn’t have a lot things in place that 2000 does, hence you never saw
the synchronization problem on that platform. In all probabilty, you now
need to do things the right way — attach to the PDO/FDO stack and filter
the IO of the port your now trying to control directly.
–
Gary G. Little
Have Computer, will travel …
909-698-3191
909-551-2105