Re: WinXP 64-bit Virtual DMA_ADAPTER

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

On Oct 25, 3:59 pm, marli...@xxxxxxxxx wrote:
On Oct 25, 11:46 am, marli...@xxxxxxxxx wrote:





On Oct 25, 6:40 am, "Alexander Grigoriev" <al...@xxxxxxxxxxxxx> wrote:

Use UsbAudio class system driver instead of PortCls.

<marli...@xxxxxxxxx> wrote in message

news:1193291318.496500.142210@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Oct 24, 7:15 pm, "Alexander Grigoriev" <al...@xxxxxxxxxxxxx> wrote:
Why do you think your driver needs a DMA adapter?

<marli...@xxxxxxxxx> wrote in message

news:1193253266.655828.203150@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Oct 24, 10:28 am, "Doron Holan [MSFT]"
<dor...@xxxxxxxxxxxxxxxxxxxx> wrote:
unless you are enumerating devices with hardware resources, what
devices
that load on your bus will require dma?

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.

<marli...@xxxxxxxxx> wrote in message

news:1193241365.270312.296640@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi,

I have a virtual bus driver over a USB bus. In this driver, I want
to
intercept the GUID_BUS_INTERFACE_STANDARD so that I get requests for
IoGetDmaAdapter().
The reason I want to do this is because in Windows XP 64-bit (unlike
32-bit) these requests fail (the PDMA_ADAPTER that is returned is
NULL).

I have been able to create my own DMA_ADAPTER by intercepting the
call
and returning a BUS_INTERFACE_STANDARD. I pass my own
BusGetDmaAdapter() which does get called. In my BusGetDmaAdapter().
I
basically return a DMA_ADAPTER structure that I have created,
including the attached DMA_OPERATIONS...

Basically, this scheme works perfectly fine...the overlaying
applications get data as they expect and everythign in 64 works just
like it does in 32 (from the app point of view).

But, there is major problem...When I run verifier I have severe
problems because Verifier's hooking mechanism does very bad things
because it thinks it is hooking on the Win XP 64-bit DMA_ADAPTER
structure which apparently has data in front of, and I think, in
back
of the DMA_ADAPTER. (The Verifier hooing function wants to hook all
the components, not just the DMA_ADAPTER but also the associated
data.) Now, there is no way for me to know what the hooking
mechanism
is doing unless I dissasemble the hooking code...and provide
Verifier
with fake data there too.

So, my questions are:
1. Can somebody give me a document that tells me how I can properly
simulate WinXP 64-bit's DMA_ADAPTER data so that Verifier will find
what it expects?
2. Is there another way I can do this (create a fake DMA_ADAPTER)?

I have a very complicated driver that is composed of two drivers
that
works perfectly in XP 32-bit because under XP 32-bit a proper
DMA_ADAPTER structure is returned with me doing anything special. I
want make these drivers work under XP 64-bit without having to
rewrite
them...and this idea of faking the DMA works...except that verifier
itself causes problems.

I need verifier to work because I need to pass DTM.

Thank you in advance for any help or ideas...- Hide quoted text -

- Show quoted text -

Hi,
I have an audio driver for a USB device that is a WavePCI model driver
(accessed by PortCls.sys). It is a virtual audio driver that sits on
top of a bus driver that sits on the USB bus. When my audio driver is
called by PortCls.sys to create a DMA adapter, my driver calls the
PortCls function NewMasterDmaChannel(). That generates an IRP that
goes eventually to my bus driver (IRP_MN_QUERY_INTERFACE). Now, in 32-
bit Windows, I pass this down and eventually it gets completed
successfully because the HalGetDmaAdapter() function is eventually
called by the lower drivers.
But, in 64-bit, apparently HalGetDmaAdapter() does not exist, so the
lower drivers return NULL...and PortCls cannot deal with that. So, for
64-bit, I am trying to basically emulate the behaviour of
HalGetDmaAdapter(). Like I said...everything works perfectly...except
when Verifier tries to hook into it. In that case Verifier expects
data that is put there by the 64-bit equivalent of
HalGetDmaAdapter()...and since the data is not there, Verifier has
problems.
When Verifier is not running all requests to the fake DMA_ADAPTER go
my driver directly and I deal with them...so the OS never knows...it
is only when the the OS is trying to interact with my fake DMA_ADAPTER
(when Verifier is running) that a problem happens.
One other possible solution is that I could get an exemption from
WHQL...- Hide quoted text -

- Show quoted text -

Hi, Alexander,
Think you for you interest in answering my question...I was asked the
same question ("why does my driver need a DMA_ADAPTER?") by Doron
above and I answered it earlier. See the post just before this one,
where I answered in detail about why my driver needs a DMA_ADAPTER.
It is an aduio miniport that runs under PortCls.sys and it is the the
driver that wants a a DMA_ADAPTER as that is how it it does it "data
pumping". Please see above for a more detailed explanation. If my
previous explanation does not fully explain, then let me know and I
will try to add more information.- Hide quoted text -

- Show quoted text -

Yes, I am using PortWavePci for a USB driver...but it is really over a
virtual device that sits over a USB driver.

One solution to my problem is to rewrite the driver using AVStream. I
am trying to avoid that. I just need a way to create a fake
DMA_ADAPTER in a way that satisfies Verifier.- Hide quoted text -

- Show quoted text -

Hi,

I have found a post with a very similar issue to mine...Eliyas from
MSFT indicated that faking the DMA_ADAPTER is valid...and, indeed, it
is what I am trying to do.

Here is a link to the post (I am not sure why I cannot find it on
google...):http://www.adras.com/IoGetDmaAdapter-for-a-root-enumerated-device-in-...

Eliyas....can you help me with this issue? Faking the DMA_ADAPTER
works perfectly except for when Verifier tries to hook into it.- Hide quoted text -

- Show quoted text -

Hi,

I have more detailed information about what is missing in my
implementation of my virtual DMA_ADAPTER. It is clear that there is
some Object (as in the Ob*() API) creation going on. And it looks like
Verifier calls ObReferencesObject()...but it is doing it to my virtual
DMA_ADAPTER when clearly that is wrong...it should be to an OBJECT
type. So, it looks like the original functions are returning some kind
of mapped pointer where the pointer is really the OBJECT instead of
the DMA_POINTER. And when Verifier calls ObReferenceObject() I can see
it is incrementing invalid data in special pool (when it does it to my
virtual DMA_ADAPTER).

This does not happen in the real world without Verifier because in
that case the only program that touches my virtual DMA_ADAPTER is me
so the ObReferenceObject() that Verifier hooking api does never
happens.

I have tried doing some manipulation with the Ob*() API but it is
clear that what I need to do is to create an object...and I don't see
an API do that.

Can MSFT (or someone else) give me some guidance about:

1. Am I correct in my statements above?
2. Is there a way I can get access to API's that create an object and
map in the way it needs to be mapped?
3. Will I be able to get a WHQL pass since this problem only happens
as a result of the presence of Verifier?
4. Might this be considered a verifier bug? Shouldn't verifier detect
that it is not accessing a real DMA_ADAPTER and leave it alone?


.

Relevant Pages

  • Re: errors that keep on coming up
    ... Param3= Memory contents of the pool block ... Read below or type Verifier in Start Run and choose the max in the wizard. ... How to Use Driver Verifier to Troubleshoot Windows Drivers ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: errors that keep on coming up
    ... Param3= Memory contents of the pool block ... Read below or type Verifier in Start Run and choose the max in the wizard. ... How to Use Driver Verifier to Troubleshoot Windows Drivers ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: WinXP 64-bit Virtual DMA_ADAPTER
    ... (The Verifier hooing function wants to hook all ... Is there another way I can do this (create a fake DMA_ADAPTER)? ... I have an audio driver for a USB device that is a WavePCI model driver ... MSFT indicated that faking the DMA_ADAPTER is valid...and, indeed, it ...
    (microsoft.public.development.device.drivers)
  • Re: 0x000000c4 error
    ... Lee run the Verifier and see which driver will not be signed and post back ... "nass" wrote: ... I think that the windows verifier ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: 0x000000c4 error
    ... "nass" wrote: ... Lee run the Verifier and see which driver will not be signed and post back ... I think that the windows verifier ...
    (microsoft.public.windowsxp.perform_maintain)