Assuming you are dealing with a x86 system - the only thing you can do is
placing some hardware breakpoints at your IO locations and see what happens.
You could initialize these breakpoints by yourself within your driver and
disable/reenable them when doing meant accesses. WinDbg should be activated
on hitting such a breakpoint. Another possibility is trying to set
appropriate hardware breakpoints by WinDbg directly. (Some debuggers do this
implicitely on specification of suitable breakpoint conditions)
Your depiction sounds like keyboard driver or any related stuff itself would
access your IO locations erraneous - hard to believe.
What about your hardware? Is it proven? Theoretical an incomplete address
decoder on your ISA card could decode accesses from other IO locations. In
that case hardware breakpoints won’t work.
Regards
Volker
----- Original Message -----
From: “Oleg E. Aleksandrov”
To: “NT Developers Interest List”
Sent: Wednesday, February 05, 2003 9:30 AM
Subject: [ntdev] Re: Can anything in W2K use a port range, which already
used by (assigned to) kernel-mode driver?
> > ===========================
> > Mark Roddy
>
> > pseudo-Pnp driver? You should be writing an ISA-bus function driver for
your device, and your inf file ought to be specifying IO port 0x120 with a
range of 8 bytes.
>
> Yes, I did just this thing. I got the example from W2K DDK - “portIO”. I
> rewrite
> “portIO” and “portIO.inf” to fit my requrements.
>
> > Anything else is doomed. In your start device routine you will then
obtain the IO resources you specified, or your device will fail to install.
> > What you cannot do is to bypass the resource allocation mechanism and
just decide that IO port 0x120 is yours for the use as you see fit.
>
> Yes, The driver obtained the requred resources on it’s start.
> Yes, The device manager shows the requested resources, and the device
> manager shows no conflict.
>
> The driver mostly works, but when I press keyboard button “Enter”, in any
> window applications (just anywhere) the device get the illegal
> input/output.
>
> >
> >
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@epost.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> What about your hardware?
I cant prove my hardware. It is “as-is”, I am not the electronic engineer.
But can you suggest a technology to verify the incomplete address decoder
on my ISA-card programmatically?
I can not state that the keyboard driver access my IO locations, it is
more likely that the key pressing (or rather releasing the key “Esc” or
“Enter”) only start any related stuff to access IO locations erraneous. It
is hard to believe, but such is the case.
the only thing you can do is
placing some hardware breakpoints at your IO locations and see what happens.
Is such “hardware breakpoint” requires any additional hardware or I can
setup it on ordinary x86 system?
Assuming you are dealing with a x86 system - the only thing you can do is
placing some hardware breakpoints at your IO locations and see what happens.
You could initialize these breakpoints by yourself within your driver and
disable/reenable them when doing meant accesses. WinDbg should be activated
on hitting such a breakpoint. Another possibility is trying to set
appropriate hardware breakpoints by WinDbg directly. (Some debuggers do this
implicitely on specification of suitable breakpoint conditions)
Your depiction sounds like keyboard driver or any related stuff itself would
access your IO locations erraneous - hard to believe.
What about your hardware? Is it proven? Theoretical an incomplete address
decoder on your ISA card could decode accesses from other IO locations. In
that case hardware breakpoints won’t work.
Regards
Volker
> But can you suggest a technology to verify the incomplete address decoder
on my ISA-card programmatically?
Theoretical you could write to as many other IO locations as possible with
test patterns and look if the register contents of your hardware remain
unchanged. This procedure is limited by the fact that you should not corrupt
register contents of other devices in your system. Possibly it’s a good idea
to perform such a test under DOS or in an embedded environment with
preferable few additional peripherals.
I can not state that the keyboard driver access my IO locations, it is
more likely that the key pressing (or rather releasing the key “Esc” or
“Enter”) only start any related stuff to access IO locations erraneous. It
is hard to believe, but such is the case.
The IO locations should be inaccessible for all user mode stuff if no ‘port
enabler’ or something near it is installed on your system.
Is such “hardware breakpoint” requires any additional hardware or I can
setup it on ordinary x86 system?
Hardware breakpoints are a feature supported by x386+. The simplest way is
to setting them up by the debugger. I looked into WinDbg documentation and
found that ‘BA’ (Break on Access) is exactly what you need. (The
documentation suggests that CPU hardware breakpoints are used to implement
this feature.) But unfortunately setting this access breakpoint on IO
locations is only supported for Windows XP. You could protect your IO
address range by two breakpoints each 4 byte of size.
Another way is to initialize the hardware breakpoints by your own code.
Searching the web for “x86 hardware breakpoint” you can find some starting
points for own coding efforts e.g. http://www.morearty.com/code/breakpoint/.
The sample refers to WIN32 user mode. I think you have to do some assembler
programming (inline or by MASM) to implement hardware breakpoints in kernel
mode. Refer to the Intel processor manuals
http://developer.intel.com/design/PentiumIII/manuals/ - vol. 3 “System
Programming Guide”. But possibly you could set the breakpoints simply from
user mode too (according the download). On hit they trigger an INT3 and this
should be catched by WinDbg - if active - too.
I tested the hardware breakpoint approach not yet in Windows kernel mode by
myself but succesfully in other environments.
Regards
Volker
----- Original Message -----
From: “Oleg E. Aleksandrov”
To: “NT Developers Interest List”
Sent: Friday, February 07, 2003 12:45 PM
Subject: [ntdev] Re: Can anything in W2K use a port range, which already
used by (assigned to) kernel-mode driver?
> > What about your hardware?
>
> I cant prove my hardware. It is “as-is”, I am not the electronic engineer.
> But can you suggest a technology to verify the incomplete address decoder
> on my ISA-card programmatically?
>
> I can not state that the keyboard driver access my IO locations, it is
> more likely that the key pressing (or rather releasing the key “Esc” or
> “Enter”) only start any related stuff to access IO locations erraneous. It
> is hard to believe, but such is the case.
>
> > the only thing you can do is
> > placing some hardware breakpoints at your IO locations and see what
happens.
>
> Is such “hardware breakpoint” requires any additional hardware or I can
> setup it on ordinary x86 system?
>
> > Assuming you are dealing with a x86 system - the only thing you can do
is
> > placing some hardware breakpoints at your IO locations and see what
happens.
> > You could initialize these breakpoints by yourself within your driver
and
> > disable/reenable them when doing meant accesses. WinDbg should be
activated
> > on hitting such a breakpoint. Another possibility is trying to set
> > appropriate hardware breakpoints by WinDbg directly. (Some debuggers do
this
> > implicitely on specification of suitable breakpoint conditions)
> >
> > Your depiction sounds like keyboard driver or any related stuff itself
would
> > access your IO locations erraneous - hard to believe.
> >
> > What about your hardware? Is it proven? Theoretical an incomplete
address
> > decoder on your ISA card could decode accesses from other IO locations.
In
> > that case hardware breakpoints won’t work.
> >
> >
> > Regards
> > Volker
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@epost.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> Volker
Thanks for helpful information.