Problem using GetScatterGatherList with DriverVerifier enabled

NTDEV
1

I’m using the GetScatterGatherList function to obtain the SG (Scatter
Gather) list of a host memory buffer (approx. 40kB). The function works
fine and the list is good as long as the “DMA verification” option is
disabled in Driver Verifier.

When I enable this option, the function still works (does not return any
error), but the SG list returned is invalid, i.e. the elements composing
the SG list do not represent the real physical segments of the memory
buffer.

Anybody ever experienced something like this?

Thanks.

2

“Stephane Bureau” wrote in message news:xxxxx@ntdev…
>
>
> When I enable this option, the function still works (does not return any
> error), but the SG list returned is invalid, i.e. the elements composing
> the SG list do not represent the real physical segments of the memory
> buffer.
>

Ah, wait a sec. Is the SG list INVALID or do the elements comprising the SG
list not represent the same physical segments of memory as your user data
buffer. These are two entirely different things!

With verifier enabled, you should expect to see the SG list point to
intermediate buffer space below 4GB physical. DMA Verifier intermediately
buffers the transfer to ensure that (a) your driver doesn’t freak-out when
this happens (it’s perfectly legal, and done in several situation on
Windows – for example, transfers from a 32-bit busmaster DMA device are
intermediately buffered on a system with 4GB or more of physical memory) and
(b) to ensure that you don’t over transfer.

OTOH, if the list is INVALID there’s a big problem!

Peter
OSR

3

> With verifier enabled, you should expect to see the SG list point to

intermediate buffer space below 4GB physical. DMA Verifier
intermediately buffers the transfer to ensure that (a) your driver
doesn’t freak-out when…

Ok, sorry about the delay, but I had to verify a few things on my side.
So, if I understand what you explained about driver verifier, it makes a
copy of my host buffer to an intermediate buffer, and then, when I receive
my SG list, it represents the physical pages of this intermediate buffer,
instead of my original buffer. Right?

Knowing that, I verified (with SoftIce) the content of the first physical
segment returned in the SG List, and it was filled with 0x0E, instead of
the data of my original buffer. And after calling PutScatterGatherList,
the memory is cleared with 0x0F.

If driver verifier is supposed to make a copy of my buffer, shouldn’t I
see my data instead of 0x0E everywhere in the intermediate buffer?
If that is so, it looks like the copy isn’t made properly!

Thanks.

4

“Stephane Bureau” wrote in message news:xxxxx@ntdev…
>
> > With verifier enabled, you should expect to see the SG list point to
> > intermediate buffer space below 4GB physical. DMA Verifier
> > intermediately buffers the transfer to ensure that (a) your driver
> > doesn’t freak-out when…
>
> Ok, sorry about the delay, but I had to verify a few things on my side.
> So, if I understand what you explained about driver verifier, it makes a
> copy of my host buffer to an intermediate buffer, and then, when I receive
> my SG list, it represents the physical pages of this intermediate buffer,
> instead of my original buffer. Right?
>
> Knowing that, I verified (with SoftIce) the content of the first physical
> segment returned in the SG List, and it was filled with 0x0E, instead of
> the data of my original buffer. And after calling PutScatterGatherList,
> the memory is cleared with 0x0F.
>
> If driver verifier is supposed to make a copy of my buffer, shouldn’t I
> see my data instead of 0x0E everywhere in the intermediate buffer?
> If that is so, it looks like the copy isn’t made properly!
>
> Thanks.
>
>

5

“Stephane Bureau” wrote in message news:xxxxx@ntdev…
>
> Knowing that, I verified (with SoftIce) the content of the first physical
> segment returned in the SG List, and it was filled with 0x0E, instead of
> the data of my original buffer. And after calling PutScatterGatherList,
> the memory is cleared with 0x0F.
>

Really… Hmmmmm… What version of the O/S are you using? Like, what
build number? If you’re not completely sure, please execute the command
“winver” from the command line, and the version information will displayed
be in the box that appears.

Also, check the couple of longwords or so just before and just after your
buffer in memory… tell me what you see there. While you’re poking around
in the debugger, tell me the name of the function that
DmaAdapter->DmaOperations->GetScatterGatherList is pointing to. These two
things will verify for me that (a) you ARE talking to DMA Verifier, and
(b)it IS intermediately buffering your data.

> If driver verifier is supposed to make a copy of my buffer, shouldn’t I
> see my data instead of 0x0E everywhere in the intermediate buffer?
> If that is so, it looks like the copy isn’t made properly!
>

Yeah… Well, what you’re seeing is certainly confusing, that’s for sure.
From your description, it almost sounds like you’re running a really OLD
pre-release (field test) copy of XP and not the actual final release of the
O/S. But that’s sort of a wild guess on my part, based on some of what I
remember seeing eons ago…

Peter
OSR

6

> Really… Hmmmmm… What version of the O/S are you using? Like, what

build number? If you’re not completely sure, please execute the command
“winver” from the command line, and the version information will
displayed be in the box that appears.

Ok… so here are the info about my O/S version:
Microsoft Windows XP
Version 5.1 (Build 2600.xpsp2.021108-1929 : Service Pack 1)

So I’m not sure but it looks quite up-to-date to me.

Also, check the couple of longwords or so just before and just after
your buffer in memory… tell me what you see there. While you’re
poking around in the debugger, tell me the name of the function that
DmaAdapter->DmaOperations->GetScatterGatherList is pointing to. These
two things will verify for me that (a) you ARE talking to DMA Verifier,
and (b)it IS intermediately buffering your data.

Ok, I looked at the bytes right before and after the auxiliary buffer in
memory, and the bytes are…
0x44, 0x6D, 0x61, 0x56, 0x72, 0x66, 0x66, 0x79, 0x30. In other words,
it’s written “DmaVrfy0”. And that is so for all the pages/segments
returned by the SG list (each segment of 4kB has “DmaVrfy0” written before
and after it).

Now, for the function pointed to by DmaAdapter->DmaOperations->
GetScatterGatherList, I’m not sure I got the right info. In SoftIce, I
could see that the function is pointing to an address (0x80631B6D), and
when I unassemble, it takes me to an assembler line located at
ntoskrnl!RtlCompressBuffer+839B. But I’m really not sure that’s the right
function.
I also tried with WinDbg, with the Windows symbols, but I couldn’t find
better.

So… have any idea how I could get that function name?

Thanks.
Stephane

7

> Really… Hmmmmm… What version of the O/S are you using? Like, what

build number? If you’re not completely sure, please execute the command
“winver” from the command line, and the version information will
displayed be in the box that appears.

Ok… so here are the info about my O/S version:
Microsoft Windows XP
Version 5.1 (Build 2600.xpsp2.021108-1929 : Service Pack 1)

So I’m not sure but it looks quite up-to-date to me.

Also, check the couple of longwords or so just before and just after
your buffer in memory… tell me what you see there. While you’re
poking around in the debugger, tell me the name of the function that
DmaAdapter->DmaOperations->GetScatterGatherList is pointing to. These
two things will verify for me that (a) you ARE talking to DMA Verifier,
and (b)it IS intermediately buffering your data.

Ok, I looked at the bytes right before and after the auxiliary buffer in
memory, and the bytes are…
0x44, 0x6D, 0x61, 0x56, 0x72, 0x66, 0x66, 0x79, 0x30. In other words,
it’s written “DmaVrfy0”. And that is so for all the pages/segments
returned by the SG list (each segment of 4kB has “DmaVrfy0” written before
and after it).

Now, for the function pointed to by DmaAdapter->DmaOperations->
GetScatterGatherList, I’m not sure I got the right info. In SoftIce, I
could see that the function is pointing to an address (0x80631B6D), and
when I unassemble, it takes me to an assembler line located at
ntoskrnl!RtlCompressBuffer+839B. But I’m really not sure that’s the right
function.
I also tried with WinDbg, with the Windows symbols, but I couldn’t find
better.

So… have any idea how I could get that function name?

Thanks.
Stephane

8

“Stephane Bureau” wrote in message news:xxxxx@ntdev…
>
> Ok… so here are the info about my O/S version:
> Microsoft Windows XP
> Version 5.1 (Build 2600.xpsp2.021108-1929 : Service Pack 1)
>
> So I’m not sure but it looks quite up-to-date to me.
>

Yeah, me too. This IS the system on which your driver is running, right?
Not the system on which you’re building? (sorry, but I have to ask – One
can take nothing for granted in email these days).

>
> Ok, I looked at the bytes right before and after the auxiliary buffer in
> memory, and the bytes are…
> 0x44, 0x6D, 0x61, 0x56, 0x72, 0x66, 0x66, 0x79, 0x30. In other words,
> it’s written “DmaVrfy0”. And that is so for all the pages/segments
> returned by the SG list (each segment of 4kB has “DmaVrfy0” written before
> and after it).
>

OK, well we know for sure that DMA Verifier is “engaged” and is managing
these segments then.

>
> So… have any idea how I could get that function name?
>

Ah, it doesn’t matter. You’re clearly running on a relatively recent build
of the O/S, and driver verifier is managing your DMA segments.

Let me try to restate your problem, to see if I have it right: Given an
arbitrary buffer in main memory (not device memory) that’s properly
described by an MDL (the MDL is probed and locked and valid), you can verify
the contents of that buffer directly via that MDL by looking at the pages
pointed to by the PFNs in the MDL’s page vector (NOT by looking at any VA
contained in the MDL), but during your execution routine callback from
GetScatterGatherList the contents of the pages that the scatter/gather
elements point to is DIFFERENT from the contents of the pages pointed to by
the PFNs in your MDL’s page vector. And this is only true when using Driver
Verifier. When you do NOT use driver verifier, your driver works perfectly.
Finally, your testing your driver on Windows XP SP1, using the checked
kernel and hal.

Does the describe the problem precisely?

If you’re quite certain this is the case, you have a real, honest to
goodness mystery on your hands. I’d strongly suggest getting in touch with
the DDK Support folks at Microsoft. They would certainly be aware of any
existing problems wth DMA support in driver verifier. Here at OSR we use
the DMA support in verifier rather frequently, and have not experienced any
such problem.

OTOH, if the above does not describe your problem, please let us know how
your problem is different from that described above.

Peter
OSR

9

> Yeah, me too. This IS the system on which your driver is running, right?

Not the system on which you’re building? (sorry, but I have to ask –
One can take nothing for granted in email these days).

Indeed, this is the machine on which I am both building and running my
driver. But just so you know, I can reproduce this bug on all the
machines we have here (all running Windows XP SP1).

Does the describe the problem precisely?

In fact, that’s all right. Maybe except for the part when you say:
“…using the checked kernel and hal”. I’m not sure, but I would guess
we’re running the release versions of the kernel and hal. Could it change
anything? Should I try with the checked version?

I’d strongly suggest getting in touch
with the DDK Support folks at Microsoft. They would certainly be aware
of any existing problems wth DMA support in driver verifier. Here at
OSR we use the DMA support in verifier rather frequently, and have not > experienced any such problem.

Ok, well I already sent a message to the Microsoft Development NewsGroup
(microsoft.public.development.device.drivers). Is that the right place,
or should I contact them by some other way?

Thanks again for your help.
Stephane

10

“Stephane Bureau” wrote in message news:xxxxx@ntdev…
>
>
> > Does the describe the problem precisely?
>
> In fact, that’s all right. Maybe except for the part when you say:
> “…using the checked kernel and hal”. I’m not sure, but I would guess
> we’re running the release versions of the kernel and hal. Could it change
> anything? Should I try with the checked version?
>

YES. You should ALWAYS test your driver using the checked kernel and HAL.
ALWAYS.

> > I’d strongly suggest getting in touch
> > with the DDK Support folks at Microsoft. They would certainly be aware
> > of any existing problems wth DMA support in driver verifier. Here at
> > OSR we use the DMA support in verifier rather frequently, and have not >
experienced any such problem.
>
> Ok, well I already sent a message to the Microsoft Development NewsGroup
> (microsoft.public.development.device.drivers). Is that the right place,
> or should I contact them by some other way?
>

No, that is not the right place. That’s just another news group like this
one.

You need to contact Microsoft’s DDK Support Group. You can get phone
numbers etc from here:
http://support.microsoft.com/common/international.aspx?rdpath=fh;en-us;cntactms

This is a PAID service, but you get 1 or 2 free incidents with an MSDN
subscription. If you find an O/S bug, there’s no charge :slight_smile:

Sorry I can’t be more help. I would LOVE to hear the result, however.
Please update us when/if you learn anything about the cause of this problem,

Peter