Discussion:
Whut the ?... an IRP is not an IRP ?
(too old to reply)
R.Wieser
2018-09-19 11:22:04 UTC
Permalink
Hello All,

Slow progress, and seemingly walking into every pit there is. :-\

Currently I'm trying to find the structure of an IRP. Well, thats eazy,
just google it. It turns out to be harder than it seems, as an IRP is not
the same as an IRP. Yeah, really. :-((

The problem is that the (pointer tot the) IRP structure thats send to any of
the IRP_MJ_* associated functions has one layout, while the "I/O request
packets" - wich *also* get referred to as IRPs ! - have another.

I've found the description to the "I/O request packets" [1]. The problem is
that I do not seem to be able to find a definition of that function-argument
IRP structure (which starts with type and size fields, two bytes each).

[1] https://msdn.microsoft.com/library/windows/hardware/ff550694

Help ?

Regards,
Rudy Wieser
Apd
2018-09-19 15:15:55 UTC
Permalink
Post by R.Wieser
The problem is that the (pointer tot the) IRP structure thats send to any of
the IRP_MJ_* associated functions has one layout, while the "I/O request
packets" - wich *also* get referred to as IRPs ! - have another.
Do they? I think not.
Post by R.Wieser
I've found the description to the "I/O request packets" [1]. The problem is
that I do not seem to be able to find a definition of that function-argument
IRP structure (which starts with type and size fields, two bytes each).
[1] https://msdn.microsoft.com/library/windows/hardware/ff550694
I'm not sure what the confusion is here but that MS link only
documents the parts of the IRP struct they want you to use. Many
kernel structures start with type and size fields and this is no
exception:

typedef struct _IRP {
CSHORT Type;
USHORT Size;
PMDL MdlAddress;
ULONG Flags;
//... other documented and undocumented fields ...
} IRP, *PIRP;

See ntddk.h for all the fields.

The IRP_MJ funcs (driver dispatch routines) then use this structure:

typedef NTSTATUS (*PDRIVER_DISPATCH) (
struct _DEVICE_OBJECT *DeviceObject,
struct _IRP *Irp
);
R.Wieser
2018-09-19 16:58:32 UTC
Permalink
Apd,
Post by Apd
Do they? I think not.
Yes, they do.
Post by Apd
I'm not sure what the confusion is here but that MS
link only documents the parts of the IRP struct they
want you to use.
How can something being "the confusion" when nothing of that kind has been
mentioned ?

And for the record, why not sort all the fields alphabetcally too ? That
way they are easier to find back!

Better yet: Why show them as being in a structure *at all*. Just name the
fields and what they do, the compiler does the rest anyway.

/s

I'm sorry (and I'm gratefull for the help you already gave), but thats
bullshit. Yes, I can imagine that some MS dipshit really thought that that
would be a good idea. But with it they effectivily block anyone not using
C{something) together with their SDK from programming.
Post by Apd
Many kernel structures start with type and size fields and
And pray tell: How do I know which structures do have such a "prefix" and
which do not ? Just flip a coin or something ?

Me is disappoint. :-(

Maybe I should focus more on third-party descriptions of such structures
instead of trying to get it directly from the source. What a load of
bollocks!!
Post by Apd
See ntddk.h for all the fields.
Yes, I found and downloaded it too (but ofcourse, not from a MS server).
But as the structures contents described in it mismatched the structure as
shown in that link I had to conclude that they where different. Hence my
post.
Post by Apd
[snip]
Yeah, that part I could glean from what was in the first part of the
tutorial I (and you) mentioned.


Nonwithstanding my above rant, thank you for telling me that both are, in
fact, the same as well as that, in regard to structures, MS documentation is
not (anymore) to be trusted/relied upon.

Regards,
Rudy Wieser
R.Wieser
2018-09-19 17:52:45 UTC
Permalink
Post by R.Wieser
Post by Apd
See ntddk.h for all the fields.
Yes, I found and downloaded it too (but ofcourse, not from a MS server).
I made a mistake there: it wasn't even the MS-declared structure (but a
third-party, "worked over" one)

I just did a search for the file, and came acros this page:

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddk/

Alas, it does not mention the IRP structure *at all*. I guess they do not
really want you to know about/use it ... :-p
(sorry, could not help myself).

From the further results (none on MS, a few on GitHub) *none* of them seemed
to included that structure (hmm...).

Shucks, just realized: I also found wdm.h, and it does (include the
structure). And now I know its the *only* structure I'm going to give it a
bit more attention.

Regards,
Rudy Wieser
Apd
2018-09-19 18:27:16 UTC
Permalink
Post by R.Wieser
Apd,
Post by Apd
I'm not sure what the confusion is here but that MS
link only documents the parts of the IRP struct they
want you to use.
How can something being "the confusion" when nothing of that kind has been
mentioned ?
I mean I wasn't sure what you were asking about but it's clear now.
Post by R.Wieser
And for the record, why not sort all the fields alphabetcally too ? That
way they are easier to find back!
Better yet: Why show them as being in a structure *at all*. Just name the
fields and what they do, the compiler does the rest anyway.
Yes, it's misleading. They shouldn't show it as a struct if they're
going to omit undocumented fields.
Post by R.Wieser
I'm sorry (and I'm gratefull for the help you already gave), but thats
bullshit. Yes, I can imagine that some MS dipshit really thought that that
would be a good idea. But with it they effectivily block anyone not using
C{something) together with their SDK from programming.
Yes, it's bullshit. They should at least show the size of places that
should be left alone and mark them reserved. I was surprised to see
that they hadn't.
Post by R.Wieser
Post by Apd
Many kernel structures start with type and size fields and
And pray tell: How do I know which structures do have such a "prefix" and
which do not ? Just flip a coin or something ?
Look at the header files in the DDK (driver development kit). I don't
know if the one for XP is still available from MS. Also look at the
ReactOS source.
Post by R.Wieser
Me is disappoint. :-(
Maybe I should focus more on third-party descriptions of such structures
instead of trying to get it directly from the source.
That's a good idea. I look at both. Sometimes the 3rd party code
documents more of the headers and functions than MS does. Often this
info is gleaned from the symbols/strings reported when debugging
kernel modules.
Post by R.Wieser
What a load of bollocks!!
Exactly.
Post by R.Wieser
Post by Apd
See ntddk.h for all the fields.
Yes, I found and downloaded it too (but ofcourse, not from a MS server).
But as the structures contents described in it mismatched the structure as
shown in that link I had to conclude that they where different. Hence my
post.
I now understand the confusion.
Post by R.Wieser
Nonwithstanding my above rant, thank you for telling me that both are, in
fact, the same as well as that, in regard to structures, MS documentation is
not (anymore) to be trusted/relied upon.
I have also found MS docs to be incomplete and just plain wrong in
some cases.
R.Wieser
2018-09-20 08:06:32 UTC
Permalink
Apd,

First off, thank you for not having taken my previous post personally.
(phew!...)
Post by Apd
Yes, it's misleading. They shouldn't show it as a struct if
they're going to omit undocumented fields.
... or at least make it clear that they ommitted stuff in there. It would
not be nice, but acceptable nonetheless.
Post by Apd
They should at least show the size of places that
should be left alone and mark them reserved
To be honest, the full structure with all fields named (why? are those
fields not supposed to be opaque?) [1] is still available in the headerfile,
so the offsets to the described/needed ones can be determined.

That that headerfile cannot be found on their own servers is a fully other
problem. :-)

[1] The language that I'm using allows me to specify nameless structure
fields / ranges of bytes. Which I sometimes use when alignment is needed,
but could imagine also being used for fields that should be truly opaque.
Post by Apd
Also look at the ReactOS source.
:-) Thats pretty-much the "third party descriptions" I referred to.
Post by Apd
Post by R.Wieser
Maybe I should focus more on third-party descriptions of such
structures instead of trying to get it directly from the source.
That's a good idea. I look at both. Sometimes the 3rd party code
documents more of the headers and functions than MS does.
In cases where a usage isn't directly obvious I often spend
hoours-upon-hours to search for documentation and trying to match-up the
different pieces (just like I now did for the IRP / _IRP structure). This
time I just could not make any sense of it.
Post by Apd
Often this info is gleaned from the symbols/strings reported when
debugging kernel modules.
I disassembled a few device driver files just to have some kind of reference
to what needs to be happening. In this case that did not help as much, as
I am still a bit in a daze about the different kinds of device-drivers
(user, kernel, WDM, etc.) and what their differences are (and thus how they
are supposed to work).
Post by Apd
I have also found MS docs to be incomplete
Tell me about it. :-(

My pet peeve is about constants being named and described, but not including
their actual values.

Its probably the same thing as with this structure though: You're expected
to run C{something}and having the SDK installed. You're simply not expected
to want / need to know the nitty-gritty of it.
Post by Apd
and just plain wrong in some cases.
I think I ran into the same a couple of times, but always attributed it to
the difference of me looking for documentation for an older OS, while MS
has, supposedly, updated it for the more recent ones.

Regards,
Rudy Wieser
Apd
2018-09-21 00:20:35 UTC
Permalink
Post by R.Wieser
Apd,
First off, thank you for not having taken my previous post personally.
(phew!...)
There's nothing like a good rant!
Post by R.Wieser
Post by Apd
Yes, it's misleading. They shouldn't show it as a struct if
they're going to omit undocumented fields.
... or at least make it clear that they ommitted stuff in there. It would
not be nice, but acceptable nonetheless.
They do show dots for the missing bits in my DDK docs.
Post by R.Wieser
That that headerfile cannot be found on their own servers is a fully other
problem. :-)
Not too surprising as they expect you to download the DDK.
Post by R.Wieser
I disassembled a few device driver files just to have some kind of reference
to what needs to be happening. In this case that did not help as much, as
I am still a bit in a daze about the different kinds of device-drivers
(user, kernel, WDM, etc.) and what their differences are (and thus how they
are supposed to work).
A user driver runs in user mode like any other win32 executable.
Kernel mode drivers are what you're looking at.

As for WDM, I found this in my DDK help file:

| Introduction to WDM
|
| To allow driver developers to write device drivers that are source-
| code compatible across all Microsoft Windows operating systems, the
| Windows Driver Model (WDM) was introduced. Kernel-mode drivers that
| follow WDM rules are called WDM drivers. All WDM drivers must:
|
| * Include wdm.h, not ntddk.h. (Note that wdm.h is a subset of ntddk.h.)
| * Be designed as a bus driver, a function driver, or a filter driver,
| as described in Types of WDM Drivers.
| * Create device objects as described in WDM Device Objects and Device
| Stacks.
| * Support Plug and Play.
| * Support Power Management.
| * Support Windows Management Instrumentation (WMI)

It also says that WDM can be source-code compatible (with a few
special case statements) across Win 98/ME and Win2k and later. I
didn't know that, since Win9x and NT are very different beasts.
Post by R.Wieser
My pet peeve is about constants being named and described, but not including
their actual values.
Its probably the same thing as with this structure though: You're expected
to run C{something}and having the SDK installed. You're simply not expected
to want / need to know the nitty-gritty of it.
Their preference is C or C++. Again, from the DDK help file:

| Choosing a Programming Language
|
| For maximum portability, drivers should be written in a high-level
| language, typically C for kernel-mode drivers ...
|
| To ensure compatibility across hardware platforms, drivers should not
| contain assembly language code.
R.Wieser
2018-09-21 09:18:10 UTC
Permalink
Apd,
Post by Apd
Not too surprising as they expect you to download the DDK.
Which is, for non C{something} (and a specific version of Visual Studio)
users (like me), the problem. I can make a good guess to the reason for
that, but not being able to have easy access to referred-to
documents/programs/other files is a nuissance.
Post by Apd
A user driver runs in user mode like any other win32 executable.
Kernel mode drivers are what you're looking at.
I know both exist. But as of yet I have no idea what either should be
looking like. Like I found a reference to a WDM-driver bit (0x2000) that
could be applied to the DLL flags in the PE header, but have zero idea what
its for or when its supposed to be used.

And yes, assumed I was writing a kernel driver - if only because one of the
arguments to "sc.exe" (with which I load/unload my driver) is "type= kernel"
and my driver keeps working. :-)
Post by Apd
| Introduction to WDM
[snip]

Thanks. Knowing what area of usage they are aimed at already helps.
Not that I expect a userland "device driver" (whats in a name ....) to be
able to access hardware, but even than.
Post by Apd
It also says that WDM can be source-code compatible (with a few
special case statements) across Win 98/ME and Win2k and later.
Well, thats not *that* surprising, as those MS guys have full control over
the involved API *and* the development environment. It just means that
either the ones that designed the API did actually do their homework, or
that the later ones had to bend themselves in knots to keep it compatible.
:-)
Post by Apd
I didn't know that, since Win9x and NT are very different beasts.
I would say !
...
Post by Apd
| For maximum portability, drivers should be written in a high-level
| language, typically C for kernel-mode drivers ...
Lol ? C being a *high-level* language ? Really ?

But I can understand their preference, and their shennigans to push people
into using their products. I don't (have to) like it though.

Regards,
Rudy Wieser

Loading...