Trouble getting MCE to see BDA swtuner example driver

Hi

I am new to the world of BDA kernel mode drivers and I’m having a play around with the swtuner example driver in the WDK. I’ve built the DVBT version from the sample and got it to load ok as described in the WDK documentation. When I start MCE, MCE fires a load of requests to the driver, which are processed ok - everything seems to be working fine.

I 'm now trying to load the same swtuner sample driver by enumerating it from a lower level driver that talks USB to my actual device. I am able to enumerate and load this driver ok, but this time, when I run up MCE, it does not fire any requests to the BDA driver, it just gives a ‘No tuner’ message. However, I can see my BDA filter in GraphEdit.

I’ve only made minor modifications to the swtdvbt.inf file, so that my lower level driver can enumerate it. But I guess I’m missing some magical GUIDs somewhere??

Thanks for any help…

Nick Clarke
Red Software Systems
http://www.redsoftsys.com

xxxxx@redsoftsys.com wrote:

Hi

I am new to the world of BDA kernel mode drivers and I’m having a play around with the swtuner example driver in the WDK. I’ve built the DVBT version from the sample and got it to load ok as described in the WDK documentation. When I start MCE, MCE fires a load of requests to the driver, which are processed ok - everything seems to be working fine.

I 'm now trying to load the same swtuner sample driver by enumerating it from a lower level driver that talks USB to my actual device. I am able to enumerate and load this driver ok, but this time, when I run up MCE, it does not fire any requests to the BDA driver, it just gives a ‘No tuner’ message. However, I can see my BDA filter in GraphEdit.

I’ve only made minor modifications to the swtdvbt.inf file, so that my lower level driver can enumerate it. But I guess I’m missing some magical GUIDs somewhere??

MCE is extremely finicky about deciding whether it will accept a tuner,
and the criteria it uses to qualify them are not well-documented. The
fact that you got a sample to work in paragraph 1 is an excellent sign,
and suggests that you should be able to achieve success without going
completely insane.

What modifications did you make to the working sample’s INF? Did you
simply change the device ID to one of your own creation? Did you change
any of the GUIDs? MCE caches a bunch of information in the registry
about every tuner it finds. I can probably look up the registry key
you’d need to flush, or perhaps you should try starting from a fresh image.


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

Hi Tim

Thanks for this quick response. Mods to the inf file are as follows:

Changed this line: %SWTDVBT.DeviceDesc%=SWTDVBT,ms_swtdvbt
To this line: %SWTDVBT.DeviceDesc% =SWTDVBT,
{3B234F52-3549-461e-A680-45D5CAA7F600}\MSi2500IrHid ; this GUID is used in
my bus enumerator

That’s all. I think maybe it might be because I have previously installed
the sw tuner using the above commented out line and, like you say below, the
original installation is all cached in the registry.

If you could let me know which keys to purge that will, in future, no doubt
be invaluable.

In the meantime, I’m going to do as you suggest and re-image my test OS.

Thanks
Nick

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 22 September 2010 18:28
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Trouble getting MCE to see BDA swtuner example driver

xxxxx@redsoftsys.com wrote:

Hi

I am new to the world of BDA kernel mode drivers and I’m having a play
around with the swtuner example driver in the WDK. I’ve built the DVBT
version from the sample and got it to load ok as described in the WDK
documentation. When I start MCE, MCE fires a load of requests to the
driver, which are processed ok - everything seems to be working fine.

I 'm now trying to load the same swtuner sample driver by enumerating it
from a lower level driver that talks USB to my actual device. I am able to
enumerate and load this driver ok, but this time, when I run up MCE, it does
not fire any requests to the BDA driver, it just gives a ‘No tuner’ message.
However, I can see my BDA filter in GraphEdit.

I’ve only made minor modifications to the swtdvbt.inf file, so that my
lower level driver can enumerate it. But I guess I’m missing some magical
GUIDs somewhere??

MCE is extremely finicky about deciding whether it will accept a tuner,
and the criteria it uses to qualify them are not well-documented. The
fact that you got a sample to work in paragraph 1 is an excellent sign,
and suggests that you should be able to achieve success without going
completely insane.

What modifications did you make to the working sample’s INF? Did you
simply change the device ID to one of your own creation? Did you change
any of the GUIDs? MCE caches a bunch of information in the registry
about every tuner it finds. I can probably look up the registry key
you’d need to flush, or perhaps you should try starting from a fresh image.


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


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


This email has been scanned by Netintelligence
http://www.netintelligence.com/email

__________ Information from ESET Smart Security, version of virus signature
database 5470 (20100922) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 5471 (20100922) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Nick Clarke wrote:

Hi Tim

Thanks for this quick response. Mods to the inf file are as follows:

Changed this line: %SWTDVBT.DeviceDesc%=SWTDVBT,ms_swtdvbt
To this line: %SWTDVBT.DeviceDesc% =SWTDVBT,
{3B234F52-3549-461e-A680-45D5CAA7F600}\MSi2500IrHid ; this GUID is used in
my bus enumerator

That’s all. I think maybe it might be because I have previously installed
the sw tuner using the above commented out line and, like you say below, the
original installation is all cached in the registry.

HKEY_LOCAL_MACHINE\
SOFTWARE\
Microsoft\
Windows\
CurrentVersion\
Media Center\
Service\
Video\
Tuners

In general, you can blast everything inside that key, and Media Center
will go re-enumerate all of the tuners the next time it starts up.


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

Still no joy. I have the error code 0xc0040597 in the media center
event log. It says media center is unable to communicate with the tv
tuner, which is good for my sanity at least. However, when I searched
the WDK for this nothing came up. Any ideas?

On 22 Sep 2010, at 23:05, Tim Roberts wrote:

> Nick Clarke wrote:
>> Hi Tim
>>
>> Thanks for this quick response. Mods to the inf file are as follows:
>>
>> Changed this line: %SWTDVBT.DeviceDesc%=SWTDVBT,ms_swtdvbt
>> To this line: %SWTDVBT.DeviceDesc% =SWTDVBT,
>> {3B234F52-3549-461e-A680-45D5CAA7F600}\MSi2500IrHid ; this GUID is
>> used in
>> my bus enumerator
>>
>> That’s all. I think maybe it might be because I have previously
>> installed
>> the sw tuner using the above commented out line and, like you say
>> below, the
>> original installation is all cached in the registry.
>
> HKEY_LOCAL_MACHINE<br>> SOFTWARE<br>> Microsoft<br>> Windows<br>> CurrentVersion<br>> Media Center<br>> Service<br>> Video<br>> Tuners
>
> In general, you can blast everything inside that key, and Media Center
> will go re-enumerate all of the tuners the next time it starts up.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>
> ______________________________________________
> This email has been scanned by Netintelligence
> http://www.netintelligence.com/email
>

Nick Clarke wrote:

Still no joy. I have the error code 0xc0040597 in the media center
event log. It says media center is unable to communicate with the tv
tuner, which is good for my sanity at least. However, when I searched
the WDK for this nothing came up. Any ideas?

Do you have the magical white paper “Designing Video Capture Boards for
Use with the Microsoft ActiveX Video Control”? Although it may not be
immediately apparent, Media Center is little more than a pretty GUI
shell surrounding msvidctl.ax. All of the hard-core video work in Media
Center is done by msvidctl.ax, so this white paper is critical reading
if you want to play in that realm.

http://www.microsoft.com/whdc/archive/mcpcvidcap.mspx

Have you already downloaded the Windows Media Center Diagnostics Kit?
It has a set of poorly documented but useful tools that can help you
poke at the insides of Media Center.

http://www.microsoft.com/downloads/details.aspx?familyid=ce06d6a7-de56-4d82-bf5f-6f6e1296a934

Can you tell that I have an attitude about Media Center?


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

One thing I am reading in the DDK docs under this heading
(http://msdn.microsoft.com/en-us/library/ff560742(v=VS.85).aspx) is
troubling me:

QUOTE:
If you are writing a minidriver for a child device, the AddReg section
should contain:

Copy
[Manufacturer]
…=ChildName
[ChildName]
…=ChildName.Device,AVStream[string]
Note that “AVStream” would be “Stream” for a stream class driver.

For all AVStream minidrivers, the filter-specific reference string in the
INF file must match the ReferenceGuid member of the KSFILTER_DESCRIPTOR
structure.
:UNQUOTE

I can see this ReferenceGuid in the BDA sample code, but the above line does
not appear in the sample .inf. Further more, I need to have my own PnP
device ID in this inf section, in order that the child BDA driver loads i.e.

%SWTDVBT.DeviceDesc% =SWTDVBT,
{3B234F52-3549-461e-A680-45D5CAA7F600}\MSi2500IrHid

Where {3B234F52-3549-461e-A680-45D5CAA7F600} is my bus GUID. How can I do
both things? Do I have to concatenate these lines in some way? Do you think
this is my problem? If so how is the original swt example achieving
success? So many questions I know, but I’m short on answers at the
moment…

Thx
Nick

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: 23 September 2010 17:59
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Trouble getting MCE to see BDA swtuner example driver

Nick Clarke wrote:

Still no joy. I have the error code 0xc0040597 in the media center
event log. It says media center is unable to communicate with the tv
tuner, which is good for my sanity at least. However, when I searched
the WDK for this nothing came up. Any ideas?

Do you have the magical white paper “Designing Video Capture Boards for
Use with the Microsoft ActiveX Video Control”? Although it may not be
immediately apparent, Media Center is little more than a pretty GUI
shell surrounding msvidctl.ax. All of the hard-core video work in Media
Center is done by msvidctl.ax, so this white paper is critical reading
if you want to play in that realm.

http://www.microsoft.com/whdc/archive/mcpcvidcap.mspx

Have you already downloaded the Windows Media Center Diagnostics Kit?
It has a set of poorly documented but useful tools that can help you
poke at the insides of Media Center.

http://www.microsoft.com/downloads/details.aspx?familyid=ce06d6a7-de56-4d82-
bf5f-6f6e1296a934

Can you tell that I have an attitude about Media Center?


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


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


This email has been scanned by Netintelligence
http://www.netintelligence.com/email

__________ Information from ESET Smart Security, version of virus signature
database 5473 (20100923) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 5476 (20100924) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Nick Clarke wrote:

One thing I am reading in the DDK docs under this heading
(http://msdn.microsoft.com/en-us/library/ff560742(v=VS.85).aspx) is
troubling me:

QUOTE:
If you are writing a minidriver for a child device, the AddReg section
should contain:

I don’t think you are writing either a parent or a child device, so I
believe that whole section is irrelevant.

Do I have to concatenate these lines in some way? Do you think
this is my problem?

No. I think this is the proverbial “red herring”.


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

Ok, so now I’ve managed to get the BDA DVBT SW tuner sample loaded with the USB VID and PID keys for my device in the .inf. MCE recognises the sample driver in this case and fires off BDA requests, I can even get the driver to record and playback channels simultaneously, happy days!

However, I still need to load BDA sample driver by enumerating it from my bus driver. I can get the driver to load, but MCE does not recognise it still, so I am assuming that I need to handle some IRP_MN_XXX or other request in my bus driver.

I’m not handling the following in my bus driver:

IRP_MN_QUERY_DEVICE_TEXT
IRP_MN_DEVICE_ENUMERATED
IRP_MN_QUERY_INTERFACE
IRP_MN_QUERY_LEGACY_BUS_INFORMATION
IRP_MN_FILTER_RESOURCE_REQUIREMENTS
IRP_MN_QUERY_PNP_DEVICE_STATE
IRP_MN_QUERY_ID(BusQueryContainerIDs)

Does MCE require any of these to be handled? Or am I just barking up the wrong tree again?

Thx
Nick Clarke
www.redsoftsys.com

xxxxx@redsoftsys.com wrote:

Ok, so now I’ve managed to get the BDA DVBT SW tuner sample loaded with the USB VID and PID keys for my device in the .inf. MCE recognises the sample driver in this case and fires off BDA requests, I can even get the driver to record and playback channels simultaneously, happy days!

However, I still need to load BDA sample driver by enumerating it from my bus driver. I can get the driver to load, but MCE does not recognise it still, so I am assuming that I need to handle some IRP_MN_XXX or other request in my bus driver.

I guess I have lost track of your situation. I gather you have a USB
tuner. You can get the DVBT sw tuner driver to load by changing the
device ID in the INF to your USB device. Right so far?

So where does a bus driver come into play? Is your USB driver exposing
a “bus” of other devices, some of which will have BDA drivers? Are your
child devices getting loaded at all?

I’m not handling the following in my bus driver:

IRP_MN_QUERY_DEVICE_TEXT

That is strongly encouraged but not required.


Does MCE require any of these to be handled? Or am I just barking up the wrong tree again?

MCE doesn’t care about your plug-and-play handling. That’s all device
manager. All it cares about is how the final tuner device behaves.
It’s basically the handling of properties that determines whether you
are acceptable to MCE or not.

For reference: http://msdn.microsoft.com/en-us/library/ff558807.aspx


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

>I guess I have lost track of your situation. I gather you have a USB
tuner. You can get the DVBT sw tuner driver to load by changing the
device ID in the INF to your USB device. Right so far?

Right, and MCE recognises and uses it

So where does a bus driver come into play? Is your USB driver exposing
a “bus” of other devices, some of which will have BDA drivers? Are your
child devices getting loaded at all?

Right, my USB driver exposes a bus, for a HID driver for IR at the moment. We are trying to enumerate the BDA driver now too. Both of these children are being loaded ok. The HID driver is fully working, but MCE refuses to use the BDA sample (i.e. the same binary as it uses above, when loaded by USB device ID).

MCE doesn’t care about your plug-and-play handling. That’s all device
manager. All it cares about is how the final tuner device behaves.
It’s basically the handling of properties that determines whether you
are acceptable to MCE or not.

Ok, but its the same BDA driver binary in both cases. My only recourse is to look for differences between the way that the driver is loaded. I’m just thinking that there’s something that I’m doing/not doing at enumeration/installation time, that is causing MCE to reject the bus driver enumerated BDA driver. Because that’s the only difference between the two cases.

I’ve been looking through the driver property pages for clues and have some things to try. Any other ideas welcomed…thx for the pointers so far

Nick Clarke
www.redsoftsys.com

xxxxx@redsoftsys.com wrote:

Right, my USB driver exposes a bus, for a HID driver for IR at the moment. We are trying to enumerate the BDA driver now too. Both of these children are being loaded ok. The HID driver is fully working, but MCE refuses to use the BDA sample (i.e. the same binary as it uses above, when loaded by USB device ID).

Ok, but its the same BDA driver binary in both cases. My only recourse is to look for differences between the way that the driver is loaded. I’m just thinking that there’s something that I’m doing/not doing at enumeration/installation time, that is causing MCE to reject the bus driver enumerated BDA driver. Because that’s the only difference between the two cases.

Are you handling the FDO and PDO differently? I should have asked that
first. They require different handling.

I just checked the driver we did that had a similar design, for a
similar reason. For the FDO, we handled:
IRP_MN_QUERY_DEVICE_RELATIONS (BusRelations)
IRP_MN_QUERY_CAPABILITIES
For the PDO, we handled:
IRP_MN_QUERY_DEVICE_RELATIONS (TargetDeviceRelation)
IRP_MN_QUERY_CAPABILITIES
IRP_MN_QUERY_DEVICE_TEXT (Description and LocationInformation)
IRP_MN_QUERY_ID (DeviceID, HardwareIDs, CompatibleIDs, InstanceID)

We invented our own bus. MCE handled this just fine.


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

> Are you handling the FDO and PDO differently? I should have asked that
first. They require different handling.

Yes, I based my PDO handling code on the WDM toaster sample in the WDK.

I just checked the driver we did that had a similar design, for a
similar reason. For the FDO, we handled:
IRP_MN_QUERY_DEVICE_RELATIONS (BusRelations)
IRP_MN_QUERY_CAPABILITIES
For the PDO, we handled:
IRP_MN_QUERY_DEVICE_RELATIONS (TargetDeviceRelation)
IRP_MN_QUERY_CAPABILITIES
IRP_MN_QUERY_DEVICE_TEXT (Description and LocationInformation)
IRP_MN_QUERY_ID (DeviceID, HardwareIDs, CompatibleIDs, InstanceID)

Ok, so my PDO handling code was not handling IRP_MN_QUERY_DEVICE_TEXT, now it does the same as yours, but still no joy with MCE!!

I’m wondering if I’m handling the IRP_MN_QUERY_IDs right, here’s what I return, maybe you can compare with yours Tim?
BusQueryDeviceID/BusQueryHardwareIDs: “{3B234F52-3549-461e-A680-45D5CAA7F600}\IrHid”
BusQueryCompatibleIDs: “{3B234F52-3549-461e-A680-45D5CAA7F600}\IrHidCompatible”
BusQueryInstanceID: “1”

We invented our own bus. MCE handled this just fine

I’m so glad to hear this, I’m sure I’m close to getting this working now, but could not have managed without you.

Nick Clarke
www.redsoftsys.com

xxxxx@redsoftsys.com wrote:

Ok, so my PDO handling code was not handling IRP_MN_QUERY_DEVICE_TEXT, now it does the same as yours, but still no joy with MCE!!

I’m wondering if I’m handling the IRP_MN_QUERY_IDs right, here’s what I return, maybe you can compare with yours Tim?
BusQueryDeviceID/BusQueryHardwareIDs: “{3B234F52-3549-461e-A680-45D5CAA7F600}\IrHid”
BusQueryCompatibleIDs: “{3B234F52-3549-461e-A680-45D5CAA7F600}\IrHidCompatible”
BusQueryInstanceID: “1”

Ours was a PCI device. We created the hardware ID and compatible ID by
grabbing the ID of the parent device, replacing the PCI with our own
product name, and appending “&Tuner” or “&Capture” or “&Encoder” or
“&Remote”. We assigned the instance ID based on the subdevice type, so
&Tuner was ID “2”.

So, the INF file matched things like
“OurName\VEN_xxxxx&DEV_xxxx&SUBSYS_xxxxxxxx&Tuner”.

However, I don’t think any of this is very important. The hardware ID
is just a random string of characters. The actual content is
irrelevant, as long as the device manager can find a match an INF file
somewhere.

Do you see MCE trying to tickle your device when the service comes up?
You should be able to do “net stop ehrecvr” and “net stop ehsched” to
stop the MCE service, then wipe out that Tuners key in the registry,
then “net start ehrecvr” and “net start ehsched”. At that point, MCE
should try to talk to your tuner.


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

> Do you see MCE trying to tickle your device when the service comes up?
You should be able to do “net stop ehrecvr” and “net stop ehsched” to
stop the MCE service, then wipe out that Tuners key in the registry,
then “net start ehrecvr” and “net start ehsched”. At that point, MCE
should try to talk to your tuner.

No it doesn’t do this. As a comparison I do see MCE tickle my tuner that was enumerated directly from USB, rather than via the fake bus.

After blowing away the registry, and then starting MCE I see 2 entries in the reg for my tuners. The one that is failing (the fake bus tuner) key does not have values for ConfiguredTuningSpace or SupportedNetworkType.

This is why I’m suspecting something wrong at PnP time; MCE does not even try to start the filter. It’s as though there is something wrong in the BDA registration somehow for the fake bus tuner. I’ll keep digging.

Nick Clarke
www.redsoftsys.com

I think I’ve found the problem. During the sample driver BDA PnPStart routine the underlying bus driver receives 2 IRP_MN_QUERY_INTERFACE requests for the following GUIDs:

{4747b320-62ce-11cf-a5d6-28db04c10000} ( this is KSMEDIUMSETID_Standard as deined in the WDK), and
{496b8280-6f25-11d0-beaf-08002be2092f} ( I googled this without any result, not defined in the WDK)

Any ideas what to do with these requests?

Nick Clarke
www.redsoftsys.com

xxxxx@redsoftsys.com wrote:

I think I’ve found the problem. During the sample driver BDA PnPStart routine the underlying bus driver receives 2 IRP_MN_QUERY_INTERFACE requests for the following GUIDs:

{4747b320-62ce-11cf-a5d6-28db04c10000} ( this is KSMEDIUMSETID_Standard as deined in the WDK), and
{496b8280-6f25-11d0-beaf-08002be2092f} ( I googled this without any result, not defined in the WDK)

Any ideas what to do with these requests?

I think your need to go in for some search rehab:

C:\tmp>findstr /s /i 496b8280 \DDK\7600\inc*.h
\DDK\7600\inc\ddk\wdmguid.h:DEFINE_GUID( GUID_BUS_INTERFACE_STANDARD,
0x496B8280L, 0x6F25, 0x11D0, 0xBE, 0xAF, 0x08, 0x00, 0x2B, 0xE2,
0x09, 0x2F
);

That interface is actually documented.


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

Tim Roberts wrote:

xxxxx@redsoftsys.com wrote:
> I think I’ve found the problem. During the sample driver BDA PnPStart routine the underlying bus driver receives 2 IRP_MN_QUERY_INTERFACE requests for the following GUIDs:
>
> {4747b320-62ce-11cf-a5d6-28db04c10000} ( this is KSMEDIUMSETID_Standard as deined in the WDK), and
> {496b8280-6f25-11d0-beaf-08002be2092f} ( I googled this without any result, not defined in the WDK)
>
> Any ideas what to do with these requests?
I think your need to go in for some search rehab:

C:\tmp>findstr /s /i 496b8280 \DDK\7600\inc*.h
\DDK\7600\inc\ddk\wdmguid.h:DEFINE_GUID( GUID_BUS_INTERFACE_STANDARD,
0x496B8280L, 0x6F25, 0x11D0, 0xBE, 0xAF, 0x08, 0x00, 0x2B, 0xE2,
0x09, 0x2F
);

That interface is actually documented.

And, as it turns out, we DID implement that interface in the BDA bus
device we did.


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

Ok Tim, thanks for that.

Do you think that implementing these interfaces is a requirement for MCE to recognise a device? I’ve had a look at GUID_BUS_INTERFACE_STANDARD and I don’t think I need to implement this interface, nothing seems to be relevant.

And I’ve checked the documentation for IRP_MN_QUERY_INTERFACE and am handling this correctly for the case of interface not supported:

“If a bus driver does not export the requested interface and therefore does not handle this IRP for a child PDO, the bus driver leaves Irp->IoStatus.Status as is and completes the IRP”

As for the KSMEDIUMSETID_Standard interface, I can’t find any documentation on that. Did you implement that one in your bus driver?

Nick Clarke
www.redsoftsys.com

xxxxx@redsoftsys.com wrote:

Ok Tim, thanks for that.

Do you think that implementing these interfaces is a requirement for MCE to recognise a device? I’ve had a look at GUID_BUS_INTERFACE_STANDARD and I don’t think I need to implement this interface, nothing seems to be relevant.

You’re right, I looked too quickly. We didn’t IMPLEMENT that interface,
we REQUESTED that interface from the PCI bus driver below us. Red herring.

As for the KSMEDIUMSETID_Standard interface, I can’t find any documentation on that. Did you implement that one in your bus driver?

Nope.


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