DeviceIO and Array of structs

Ding Ding Ding…we have a winner!

xxxxx@yahoo.co.uk wrote:

From: xxxxx@yahoo.co.uk
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] DeviceIO and Array of structs
Date: Fri, 3 Sep 2010 10:27:19 -0400 (EDT)

Nope. sizeof(Irp->AssociatedIrp.SystemBuffer) gives 4 bytes.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

xxxxx@yahoo.co.uk wrote:

>> 2) Please post the C# signature [DllImport] that you’re using for
DeviceIoControl

[DllImport("kernel32.dll", SetLastError = true)]  
static extern bool DeviceIoControl(  
Microsoft.Win32.SafeHandles.SafeFileHandle hDevice,  
uint dwIoControlCode,  
IntPtr lpInBuffer,  
uint nInBufferSize,  
[Out] IntPtr lpOutBuffer,  
uint nOutBufferSize,  
ref uint lpBytesReturned,  
IntPtr lpOverlapped);  

Technically speaking, both the lpInBuffer and lpOutBuffer parameters
should be declared [In,Out]. The exact interpretation of those two
buffers depends on the low-order two buts of the ioctl code. It’s
possible for them both to be input buffers in one call, and both to be
output buffers in another call.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Not really…

The InBuffer can only be used to supply input TO the driver. There’s no provision for returning data to the InBuffer (to user mode).

The OutBuffer, however, CAN be used in either direction as you mentioned.

Peter
OSR

Did you look at the samples at
http://pinvoke.net/default.aspx/kernel32.DeviceIoControl

That site has lots of interesting C# to legacy C calling examples.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-423564-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.co.uk
Sent: Friday, September 03, 2010 6:17 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DeviceIO and Array of structs

Being really specific this is the current problem. The output buffer
supplied to
the driver is only 4 bytes. It needs to be 200 bytes.

An illustration of the C# code follows

uint inputBufferSize = 0;  
uint outputBufferSize = 200;  
IntPtr ptrInput;  
IntPtr ptrOutput;  
ptrOutput = Marshal.AllocHGlobal(200);  
retVal = DeviceIoControl(hDriver, ioctlCode, ptrInput, inputBufferSize,  
ptrOutput, outputBufferSize, ref bytesReturned, IntPtr.Zero); ```  
  
Yet a DbgPrint of the AssociatedIrp-\>SystemBuffer size yields only 4  

bytes!

This is what is confusing the heck out of me. This worked like a charm
when I
was only retrieving one struct.

So the theory is this.

I need a buffer off 200 bytes (which will return an array of 50 ptrs -
each ptr
points to a struct in the array. Then I can walk the buffer pulling out my
structs.

As I say I’m not asking for help with how to unpack the buffer, rather why
or
how is the driver only getting 4 bytes?

The definition of the api call has not changed.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> sizeof(Irp->AssociatedIrp.SystemBuffer) gives 4 bytes.

I don’t mean to be rude/arrogant/etc with you, but probably it makes sense to take a basic C course before even thinking about writing drivers???

Anton Bassov

@Anton

You always mean to be rude :sigh:

People make mistakes. People miss the obvious. It doesn’t make them any less skilled, it makes them human. “To err is human”. And there is a second part to that saying which I often invoke in your case :wink:

> You always mean to be rude :sigh:

Well, I never want to be actually rude, but I can be, indeed, sometimes intentionally hard with posters like you. More on it below

People make mistakes. People miss the obvious. It doesn’t make them any less skilled, it makes
them human. “To err is human”. And there is a second part to that saying which I often invoke in your case :wink:

Sorry, but both your argumentation and your reference to Alexander Pope’s famous phrase are totally irrelevant in this context. Indeed, we all make mistakes. However, as far as programming mistakes are concerned, some of us (those who mainly answer questions, btw ) try everything they can before asking for the external assistance, while those happen to be on the asking side on the regular basis tend to scream “SOS!!! HELP!!!” without taking ANY steps to investigate the issue - instead, they would prefer if someone else did all work for them. I can be, indeed, hard with the latter type of posters.

I hope you are not going to argue about firmly belonging to the latter type of posters -after all, you asked for nothing less than written code right in your original post. Therefore, when I saw that, apart from other things, you did not even bother yourself with looking at either struct IRP declaration or WDK documentation before asking for help, I got pretty irritated…

Anton Bassov

At 19:50 04/09/2010, xxxxx@hotmail.com wrote:

However, as far as programming mistakes are concerned, some of us
(those who mainly answer questions, btw ) try everything they can
before asking for the external assistance, while those happen to be
on the asking side on the regular basis tend to scream “SOS!!!
HELP!!!” without taking ANY steps to investigate the issue -
instead, they would prefer if someone else did all work for them. I
can be, indeed, hard with the latter type of posters.

Anton may not be everybody’s favourite list member, but there is a
very serious point here. Those who tend to scream for help on every
step of the way are probably not cut out to be a professional in this
type of career.

As a driver writer it seems that most experienced and learned list
members have gone through the very painful experience of identifying
a problem or a bug that is the fault of product supplied by someone
else. More often than not the driver writer works for the smallest
fish in the chain, hence all the bigger guys shrug their shoulders
and say that it must be your fault and nothing to do with them or
their products.

You want the big guys to fix their products, or even just acknowledge
that they have a problem (there can be significant commercial
pressure on this last bit since your boss doesn’t want his company
sued for failing to deliver).

The only way to get the attention of those big guys is to research
and understand the problem until you know it backwards. You know all
the steps and conditions to recreate it and you can list all the
things you have tried to get around it. When you submit your
findings you have to be 100% sure that there is no flaw in your
reasoning. If there is any flaw, those big guys will dismiss you
(and your company) as lightweight and you’ll never get another
response. Conversely, by showing your technical competence and
ability to correctly analyse a problem you gain credibility with
those big guys and they will listen to you in the future.

Many of the regular list responders will have been in this
position. They know how important it is to show how much effort you
have made to understand a problem before asking for assistance. When
they ask for some effort to be made by the poster, they really do
know what such effort should be.

What is generally most exasperating on the list is the number of
questions posted by the ‘screamers’ that could have been answered by
themselves with a bit of nouse and adding debug statements to their
code or RTFM.

It should be remembered that participation in this list is voluntary,
very busy people take time to answer questions. No one is obliged to
answer and the more one is perceived as a ‘screamer’ the less likely
there is to be an answer - or at least a polite and useful answer.

Mark.

I agree with everything Mr. Edwards said.

Then again, there are those times when you get locked-into looking at a problem a certain way, and can’t see the very obvious error that you’re making.

Peter
OSR

At 21:13 04/09/2010, xxxxx@osr.com wrote:

I agree with everything Mr. Edwards said.

Then again, there are those times when you get locked-into looking
at a problem a certain way, and can’t see the very obvious error
that you’re making.

Thank you.

That’s the next stage - gaining the skills to know when it is time to
break out of the box. And to know what questions to ask, who to ask
and how the questions should be framed for maximum response.

Mark.

Indeed. It always amazes me that an ENGINEER can ask a question without providing enough context or information. I mean, we’re all engineers here. Don’t they think to themselves before posting: “Hmmm, what would I need to know to be able to answer this question?” – all they need to do is imagine themselves in the position of ANSWERING the question.

Seriously… this mystifies me.

Peter
OSR

(P.S. This has nothing to do with this thread, or the OP’s question… just more discursiveness following the train of thought Mr. Edwards started).



> As a driver writer it seems that most experienced and learned list members have gone through
> the very painful experience of identifying a problem or a bug that is the fault of product
> supplied by someone else.

Well, on one occasion I was in even more “interesting” position - I was looking for non-existent bug in my code, because " a product supplied by someone else" made me believe there was the one in my code. The most interesting part was the fact that the product in question was, actually, a debugger that I was using at the time (i.e. Numega SoftIce). Later I had found out that my problem was familiar to anyone who tried examining memory-mapped registers with SI after having written to them - SoftIce sometimes (but not always) made you believe that operation had never taken effect…

Anton Bassov





SoftICE was junk, and relied on placing so many hooks into Windows that it was absolutely laughable.

I could never understand how people could actually run this thing on their DEVELOPMENT systems, because it let them do “single machine development and debugging” – Who would install such a thing on their development system?

Peter
OSR

Some people take no pride in their craft. Major problem.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, September 04, 2010 4:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DeviceIO and Array of structs

[quote]
and how the questions should be framed for maximum response [/quote]

Indeed. It always amazes me that an ENGINEER can ask a question without
providing enough context or information. I mean, we’re all engineers here.
Don’t they think to themselves before posting: “Hmmm, what would I need to
know to be able to answer this question?” – all they need to do is imagine
themselves in the position of ANSWERING the question.

Seriously… this mystifies me.

Peter
OSR

(P.S. This has nothing to do with this thread, or the OP’s question… just
more discursiveness following the train of thought Mr. Edwards started).


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

+1

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, September 04, 2010 4:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DeviceIO and Array of structs

I agree with everything Mr. Edwards said.

Then again, there are those times when you get locked-into looking at a
problem a certain way, and can’t see the very obvious error that you’re
making.

Peter
OSR


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> SoftICE was junk, and relied on placing so many hooks into Windows that it was absolutely laughable.

WEll, let’s face it - by its very definition kernel-level debugger invariably implies at least some modifications to the kernel (for the fun of doing it let’s try to avoid any references to Mr.Torvalds’s opinion on the subject unless we decide to move it to NTTALK). The only possible way to avoid these modifications is to debug your code under emulator like QEMU that is designed to work hand-by-hand with the debugger like GDB. If you do it this way you will be just an external observer as far as the target kernel is concerned. Things will work exactly the same way they do when you debug a regular UM process, with QEMU running your target kernel in one terminal window and GDB in another. If you do it this way no modifications to the running kernel image will be needed . However, this approach is hardly suitable for someone who writes a driver for a physical hardware device…

I could never understand how people could actually run this thing on their DEVELOPMENT
systems, because it let them do “single machine development and debugging” – Who would
install such a thing on their development system?

It depends on your objectives…

Assuming that your objective is just source-level debugging WinDbg is obviously the tool of your choice.
However, if you want something more advanced (for example, interactive disasm), there is a good chance you would just love a tool like SoftIce.

Let’s say you want to examine memory. contents. How much memory are you able to see under WinDbg at any given moment??? How fast can you single-step though the code??? Can you jump to the location of your choice???

By the virtue of allowing “single machine development and debugging” , SoftIce allowed you to browse the memory and code windows pretty much the same way you browse the document. If it is not enough for you SI allowed you to modify memory, as well as register, contents, on the fly; to alter execution path, and, in all respects, do everything you can do under IDA…while operating on the running kernel. Certainly, all the above did not come for free - quite a few modifications to the system were required to make it all work…

Anton Bassov

“M. M. O’Brien” wrote in message
news:xxxxx@ntdev…
> Some people take no pride in their craft. Major problem.

What craft? Very few people these days look for a kernel, drivers or other
“low level” developer career, it is thing of the past.
For many new devs in this area making a driver is temporary assignment.
They often are students in quite unrelated professions, such as management,
arts or law.
They just want to get the job done, and move on with their life.

Regards,
–pa

>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Saturday, September 04, 2010 4:55 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] DeviceIO and Array of structs
>
>


>
> Indeed. It always amazes me that an ENGINEER can ask a question without
> providing enough context or information. I mean, we’re all engineers
> here.
> Don’t they think to themselves before posting: “Hmmm, what would I need to
> know to be able to answer this question?” – all they need to do is
> imagine
> themselves in the position of ANSWERING the question.
>
> Seriously… this mystifies me.
>
> Peter
> OSR
>
> (P.S. This has nothing to do with this thread, or the OP’s question…
> just
> more discursiveness following the train of thought Mr. Edwards started).
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-423710-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, September 04, 2010 6:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DeviceIO and Array of structs

[snip]

It depends on your objectives…

Assuming that your objective is just source-level debugging WinDbg is
obviously the tool of your choice.
However, if you want something more advanced (for example, interactive
disasm), there is a good chance you would just love a tool like SoftIce.

Let’s say you want to examine memory. contents. How much memory are you
able to see under WinDbg at any given moment??? How fast can you single-
step though the code??? Can you jump to the location of your choice???

By the virtue of allowing “single machine development and debugging” ,
SoftIce allowed you to browse the memory and code windows pretty much the
same way you browse the document. If it is not enough for you SI allowed
you to modify memory, as well as register, contents, on the fly; to alter
execution path, and, in all respects, do everything you can do under
IDA…while operating on the running kernel. Certainly, all the above
did not come for free - quite a few modifications to the system were
required to make it all work…

I have done every single one of the above activities using Windbg on a live
system. I’ve patched running images to bypass my own mistakes so it would
not bugcheck, so I could unload the driver or reboot the whole system
cleanly. On the other hand, sometimes it’s just easier to .reboot. :slight_smile:

With a 1394 cable, it’s almost as fast as SoftICE was on Win98. With a
serial cable, not so much.

Phil

Philip D. Barila (303) 776-1264

BTW, as a follow-up, just look at the “masterpiece” below

[quote]

Frankly i have no intrest in WDM. so, can u give me any code for do so,please.

[end quote]

The funniest thing here is that this statement was made on “device path to dos path” thread at approx the same time Mr.Edwards was typing his post…

Anton Bassov

> I have done every single one of the above activities using Windbg on a live system.

You must be a true masochist then…

BTW, what was your target system? IIRC, it took meat least 5 secs to step from one line to another with WinDbg under Vista (although it was faster with XP), so that I can imagine the amount of time you spent on it…

I’ve patched running images to bypass my own mistakes so it would not bugcheck, so I could
unload the driver or reboot the whole system cleanly.

…and I was playing around with the running kernel ,examining code paths, structure layouts,etc, screwing up everything I possibly could…and then restoring things back to the original state so that the program could continue execution, then reaching another breakpoint, doing the same thing again and so on an so forth. It was all fun, and the user experience was comparable to that of editing a doc . I imagine how “enjoyable” my experience would have been if I was using WinDbg for this purpose…

On the other hand, sometimes it’s just easier to .reboot.

Judging from my experience with WinDbg, that’s for sure …

Anton Bassov