proxy WDM/Miniport driver - can I do this ?

device driver

    Sponsored Links

    Next

  • 1. read conventional memory from DriverEntry/Checked build
    Hi My previous question was maybe too detailed and seemed complex or unclear. I did not get any answer to it... So I ask it again, but in a simpler way (I hope) : From the DriverEntry of one of my boot drivers, I need to read some bytes in conventional memory (below 640KB of physical address). I can use MmMapIoSpace but this fails when I use WinXP Checked Build (ASSERT (PointerPte->u.Hard.Valid == 0)) I need to be able to use a "Checked Build Valid" method to read bytes from physical addresses below 640KB. This method must also be accepted by DriverVerifier. These are customer requirements. What is the correct method to read such bytes from boot drivers under CheckedBuild and with DriverVerifier under free build? Thanks in advance for your help
  • 2. How to get print spooler to release/close open device(Parallel0)
    To be able to query local attached printers for information, I need to force/convince the print spooler to release the ports (parport), which it has opened. As the spooler (or language monitor) needs to monitor the printer for unsolicited status messages, it makes sence that the spooler opens the port(s) and keeps it open. But, now, when another applications tries to open the port (\Device\Parallel0), access is denied. So how do I get the print spooler to release/close the device, so that I can use it? I know this is possible, as I can see Lexmark is doing this from their "lexbces.exe" service. I have used Portmon to monitor all requests sendt to the device, and always before "lexbces.exe" tries to open the device, the print spooler magically closes the device. I don't know if this is a undocumented feature provided by MS to help their chums at Lexmark ;), or if Lexmark uses some tricks and hacks to do this - but I also would realy like to know, how this magic works. Kind Regards, Christoph Lindemann
  • 3. bug found only in signed printer driver, how to debug?
    I recently got my printer driver signed. After getting signed, our QA group found a bug. When I (and then they) tried to reproduce it, we found it only happens with the signed version. The unsigned version does not have the problem (it's a spooler crash when doing a test print as part of the install; test prints after install and normal application prints work fine). So I'm wondering how to debug this. I can't very well submit a debug version of the driver to be signed (cause then it will be part of windows update and all our customers will get this debug driver). And debugging the non-debug, signed, version of the driver is less than productive. Any ideas? Thanks, ScottR -- Scott Robins

proxy WDM/Miniport driver - can I do this ?

Postby SeanG » Sat, 22 Nov 2003 07:27:11 GMT

Let me preface this by saying I know little about device drivers, but a lot
about C++ Windev using Win32/COM. I have Visstudio 6 and 7, and MSDN
Universal, and just got the latest DDK. Im a quick learner.

**Problem:
We are developing a softphone client using Microsoft's RTC SIP/RTP
components.
You can point these components and whatever audio source/destination you
wish.
When connected, RTC is streaming audio over UDP, ideally and usually in 20ms
intervals, with @10% variance, so on a good sound card/driver setup we see
successive UDP packets spaced  like ... 21ms 20ms 20ms 22ms ... etc.
Variance from that is called Jitter. A certain amount of jitter is normal.
Excessive Jitter results in poor audio and data loss on the receiving end.
Some sound card/driver combinations, for unknown reasons, cause massive
jitter eg  .01 ms .01 ms 45ms ,01ms 39 ms .02ms ...
This is verifed using Ethereal tracing and doing RTP packet analysis.
On the same PC, use another sound card/driver, or an USB mike/headset and it
works fine.
This is not just with RTC implementation. Tried a non RTC softphone (Xten) -
had same jittery UDP.

**My Idea: (I dont really know what I am talking about so bear with me :-)
Create what I call a "Proxy" Driver. Essentially this would be a consumer of
the actual Drivers miniport/pin output, rebuffer it and it would then show
up as an available sound source to the RTC app. Hopefully by rebuffering the
audio I can eliminate this jitter problem.

so [AUDIO DEVICE] <--> [ADAPTER DRIVER] <--> [*MY REBUFFER DRIVER*] <-->
[Kernel / portcls]

Is something like this possible / insane ?
If it is possible can someone point me in the right direction. I have a book
on device drivers and am reading now about portcls, wdm, miniports, bus
drivers etc.

Thanks
b.

btw, I have posted to to MS MVP's at the RTC ng, and they thought about it
and said it was out of their scope.



RE: proxy WDM/Miniport driver - can I do this ?

Postby johnei » Wed, 26 Nov 2003 05:06:33 GMT

Hi, Sean

The DDK specialist most familiar with this area is not able to respond at
this time. You should receive a response by close of business on Tuesday,
Pacific time.

Thank you for choosing the MSDN Managed Newsgroups,

John Eikanger
Microsoft Developer Support

This posting is provided S ISwith no warranties, and confers no rights.
"Microsoft highly recommends to all of our customers that they visit the
http://www.microsoft.com/protect site and perform the three straightforward
steps listed to improve your computer security."


--------------------
Reply-To: "SeanG"<
From: "SeanG"<
Subject: proxy WDM/Miniport driver - can I do this ?
Date: Thu, 20 Nov 2003 16:27:11 -0600
Lines: 43
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID:<< XXXX@XXXXX.COM >>
Newsgroups: microsoft.public.development.device.drivers
NNTP-Posting-Host: fw-df-global.webley.com 64.108.238.10
Path:
cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP08
phx.gbl!TK2MSFTNGP12.phx.gbl
Xref: cpmsftngxa07.phx.gbl microsoft.public.development.device.drivers:34241
X-Tomcat-NG: microsoft.public.development.device.drivers

Let me preface this by saying I know little about device drivers, but a lot
about C++ Windev using Win32/COM. I have Visstudio 6 and 7, and MSDN
Universal, and just got the latest DDK. Im a quick learner.

**Problem:
We are developing a softphone client using Microsoft's RTC SIP/RTP
components.
You can point these components and whatever audio source/destination you
wish.
When connected, RTC is streaming audio over UDP, ideally and usually in 20ms
intervals, with @10% variance, so on a good sound card/driver setup we see
successive UDP packets spaced like ... 21ms 20ms 20ms 22ms ... etc.
Variance from that is called Jitter. A certain amount of jitter is normal.
Excessive Jitter results in poor audio and data loss on the receiving end.
Some sound card/driver combinations, for unknown reasons, cause massive
jitter eg .01 ms .01 ms 45ms ,01ms 39 ms .02ms ...
This is verifed using Ethereal tracing and doing RTP packet analysis.
On the same PC, use another sound card/driver, or an USB mike/headset and it
works fine.
This is not just with RTC implementation. Tried a non RTC softphone (Xten) -
had same jittery UDP.

**My Idea: (I dont really know what I am talking about so bear with me :-)
Create what I call a "Proxy" Driver. Essentially this would be a consumer of
the actual Drivers miniport/pin output, rebuffer it and it would then show
up as an available sound source to the RTC app. Hopefully by rebuffering the
audio I can eliminate this jitter problem.

so [AUDIO DEVICE]<<->> [ADAPTER DRIVER]<<->> [*MY REBUFFER DRIVER*]<<->>
[Kernel / portcls]

Is something like this possible / insane ?
If it is possible can someone point me in the right direction. I have a book
on device drivers and am reading now about portcls, wdm, miniports, bus
drivers etc.

Thanks
b.

btw, I have posted to to MS MVP's at the RTC ng, and they thought about it
and said it was out of their scope.



{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Hi, Sean
\par
\par The DDK specialist most familiar with this area is not able to respond at this t

Similar Threads:

1.wdm drivers done some damage

After installing WDM drivers (2.20) downloaded from Nvidia I experienced some 
problems, first I noticed my dvd-rom and cd burner were not showing in My 
Compter, I fixed this with windows KB Q314060. Then I noticed my sound wasn't 
working, I tried uninstalling WDM drivers reinstalling sound and chipset 
drivers I tried taking out the pci sound card and enabling onbaord sound. 
Windows will see the new hardware, I'll install the latest drivers, device 
manager says it's ok but in Sounds and Audio Devices Properties it says "no 
audio devices".
I am also getting errors in the Application event log

Faulting application setup.exe, version 1.0.0.28, faulting module setup.exe, 
version 1.0.0.28, fault address 0x00001b1f.

Fault bucket 21975919.

Faulting application mixer.exe, version 1.5.5.0, faulting module mixer.exe, 
version 1.5.5.0, fault address 0x000016bb.

Fault bucket 19788726.

Specs:
WindowsXP Pro
Abit IS7
PCI Sound card (c-media 8738)

2.Koolatron KWC13A Mini Fridge 16-(12-Ounce) Cans, Red

3.send buffers in ndis-wdm miniport example of wdk

hi,


Reference:   path       :\WinDDK\6001.18001\src\network\ndis\ndiswdm\init.c
                     
                      function:  NICAllocSendResources

                      Line       :183
    
When sending data  from ndiswdm miniport driver , what is the need of 
calling NdisAllocateBufferPool to allocate bufferpool and than allocate 
buffer using NdisAllocateBuffer ?

Can't we directly send the data (which is in TCB)  as we have allocated 
memory for TCB?

should we  use URB in TCB if NIC is connected on USB as a end point, rather 
than IRP in TCB

TIA
Jitender Singh

4.NDIS miniport with WDM lower edge, SG list for a MDL, DMA adap

5.Power Management in a Miniport Driver with a WDM Lower Interfa

"Vetzak" wrote:
> 
> Your NDIS port driver must handle the power OIDs as documented. The
> imported NDIS port driver takes care of all PnP and power IRPs hence
> will send these IRPs down to the lower device object.

In the DDK, the samples tend to prevail over MSDN documentation....

--PA

> On 25 jan, 08:54, "igorik" < XXXX@XXXXX.COM > wrote:
> > Hi,
> >
> > I have a question regarding Power Management in a Miniport Driver with
> > a WDM Lower Interface. According to a documentation "The miniport
> > driver must always return NDIS_STATUS_SUCCESS to an OID_PNP_SET_POWER
> > request". However, in the ndiswdm example they return
> > NDIS_STATUS_PENDING and forward this request to the lower binding. My
> > questions are:
> > 1. Can I answer OID_PNP_SET_POWER with NDIS_STATUS_PENDING? I would
> > like to use this mechanism to communicate with a device before entering
> > D3.
> > 2. If Yes, should I forward OID_PNP_SET_POWER to the lower binding or
> > NDIS will do it for me? As far as I understand, if I return
> > NDIS_STATUS_SUCCESS, NDIS will do it for me.
> > 
> > Thanks in advance,
> > Igor.
> 
> 

6. NDIS miniport with WDM lower edge, SG list for a MDL, DMA adapter

7. Ndis Wdm miniport, Halt not called at device removal

8. Power Management in a Miniport Driver with a WDM Lower Interface



Return to device driver

 

Who is online

Users browsing this forum: No registered users and 88 guest