INetCfg::FindComponent returns S_FALSE

Adrien_de_Croy · December 21, 2010, 11:06pm

Hi all, I hope someone can help.

I’m having problems on some windows 2008 R2 systems when it comes to
updating my component (LWF driver).

First I have to remove it, which requires finding the component.

However the call to INetCfg::FindComponent returns S_FALSE.

Documentation for INetCfg::FindComponent doesn’t mention a possible
return of that type, however INetCfg::EnumComponents does - when the
last chunk in the enumeration is obtained.

Is this a bug in NetCfg?

I’m wondering if I need to work around it by implementing my own
FindComponent call by using EnumComponents.

I only call this code when I’ve determined the component is actually
installed - I can see it in the registry under

HKLM\System\CurrentControlSet\Control\Network{4d36e974-e325-11ce-bfc1-08002be10318}[My
Network Service Instance GUID]

This by the way is also where I find the oemxx.inf file I need to clean up.

Is it bad to reuse GUIDs for your component?

Thanks

Adrien

David_R_Cattley · December 22, 2010, 12:46pm

S_FALSE (IIRC) is the return code that results when the component cannot be found (is not installed).

You say this occurs when your detect your component is installed by inference from the registry data. A better way is to use BindView from the WDK and verify your component is installed. I am not convinced that your component is actually installed if you call FindComponent() with your component Id and it returns S_FALSE. I also presume that when it returns S_FALSE that the output interface pointer is NULL. Is that correct?

Finding the name of the OEMnn.INF file(s) that will install your component is an operation consisting of a number of SetupDi calls. Essentially you create a device info set and a new root enumerated device with a device id that matches your component id. Yes, I know that sounds silly since your component is not a ‘device’ but that is irrelevant to how SetupDi views the issue. You ‘create’ the device and specify a flag to avoid calling the CFGMGR to actually involve PnP and then ask SetupDi to enumerate all drivers for the device, then grok the list of drivers for the name(s) of the INF file in which the system has found the drivers. You then delete the device and cleanup up now that you know the list of INF files.

Wandering about the registry is not a good idea

Oh, and that GUID? I don’t think you actually control that value do you? NetCfg allocates that for its own use. Nothing that I know of guarantees that GUID to be same through an install->uninstall->install cycle.

Good Luck,
Dave Cattley

Adrien_de_Croy · December 22, 2010, 3:55pm

http-equiv=“Content-Type”>

HI Dave

thanks for your reply

On 23/12/2010 6:45 a.m., Dave Cattley wrote:

type=“cite”>

S_FALSE (IIRC) is the return code that results when the component
cannot be found (is not installed).

You say this occurs when your detect your component is installed
by inference from the registry data.   A better way is to use
BindView from the WDK and verify your component is installed.   I
am not convinced that your component is actually installed if you
call FindComponent() with your component Id and it returns
S_FALSE.    I also presume that when it returns S_FALSE that the
output interface pointer is NULL. Is that correct?

I changed my code from checking for S_OK to checking for
SUCCEEDED(hr) and a non-null interface pointer. Since I can’t repro
the problem (customer site) I’ve asked the customer to run another
installer which should give me the answer to this question a bit
later.

type=“cite”>

Finding the name of the OEMnn.INF file(s) that will install your
component is an operation consisting of a number of SetupDi
calls. Essentially you create a device info set and a new root
enumerated device with a device id that matches your component
id. Yes, I know that sounds silly since your component is not a
‘device’ but that is irrelevant to how SetupDi views the issue.
You ‘create’ the device and specify a flag to avoid calling the
CFGMGR to actually involve PnP and then ask SetupDi to enumerate
all drivers for the device, then grok the list of drivers for the
name(s) of the INF file in which the system has found the
drivers. You then delete the device and cleanup up now that you
know the list of INF files.

Actually since we have a netcfginstance UUID it’s “safe” to grep the
.inf files in Windows\ini ?

We are of course also dealing with a bunch of legacy issues, where
previous versions of our driver uninstaller didn’t remove the
oemxx.inf files, so there would be multiple copies of the driver in
the driver repository.

So I grep the files, look for the device class GUID and our net
config instance GUID and remove all old inf files that way. Seems
to work great.

As for finding the current instance in the registry. I work on the
basis that MS won’t change this radically any time soon, since it
hasn’t changed in aeons. Otherwise we’d need to store the reported
oemx.inf file when we installed (which our old installer didn’t do).

I can see reliably that the reg key is removed / added when I remove
/ add the component using netcfg.exe or from the network interface
properties UI.

type=“cite”>

Wandering about the registry is not a good idea

Oh, and that GUID? I don’t think you actually control that value
do you?

it’s in our .inf file under NetCfgInstanceId

the value we provide there seems to be used by the os.

refer to
http://msdn.microsoft.com/en-us/library/ff554951(VS.85).aspx under
the DDInstall Section.

type=“cite”>NetCfg allocates that for its own use. Nothing that I
know of guarantees that GUID to be same through an
install->uninstall->install cycle.

type=“cite”>Good Luck,

thanks!

Adrien

type=“cite”>
Dave Cattley

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

--
Adrien de Croy - WinGate Proxy Server -[http://www.wingate.com](http://www.wingate.com)

David_R_Cattley · December 22, 2010, 4:44pm

it’s in our .inf file under NetCfgInstanceId
the value we provide there seems to be used by the os.
refer to http://msdn.microsoft.com/en-us/library/ff554951(VS.85).aspx under
the DDInstall Section.

Thanks for pointing that out. I was clearly asleep when reading your
original post (you mention in the first lines this is a LWF).

Cheers,
Dave Cattley

satheesh_babu_muthupandi · December 22, 2010, 5:00pm

Hi Adrien,
Just for clalification.
If you remove your old inf file (oemXX.inf) from the inf folder by looking
at the component’s registry, how do you handle the downgrade driver (or
rollback) scenario by the user?

I’m also looking for a better solution to clean-up the oemXX.inf files which
are not cleaned up on subsequent installation of our driver package

thanks in adv.
Satheesh

On Wed, Dec 22, 2010 at 1:44 PM, David R. Cattley wrote:

>
> it’s in our .inf file under NetCfgInstanceId
> the value we provide there seems to be used by the os.
> refer to http://msdn.microsoft.com/en-us/library/ff554951(VS.85).aspx http:under
> the DDInstall Section.
> </http:>
>
> Thanks for pointing that out. I was clearly asleep when reading your
> original post (you mention in the first lines this is a LWF).
>
> Cheers,
> Dave Cattley
>
>
> —
> 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
>

David_R_Cattley · December 22, 2010, 5:43pm

NetService is a bit different than a PnP device enumerated in the device
tree when it comes to downgrade / rollback. For an enumerated device, the
presence of the device is independent of the ?installed state? of the driver
package. The device is just ?there? and so if you remove one driver, the
device (aka, PnP) would very much like to have some other driver installed
on that device and so a subsequent device install will pick from what is
available.

In the case of a NetService, the removal of the service is just that ? a
removal. To ?rollback? (or downgrade) the NetService must be installed
again. In fact, all OBO references must be ?removed? before the NetService
is removed. And there is no ?upgrade? either. Asking NetCfg to ?install?
a NetService that is already installed is a no-op other than adding an OBO
reference. The ?betterness? of any new Driver Package is irrelevant.

So downgrade/rollback is entirely something that an application that is
installing a NetService must do essentially on its own. To handle the
upgrade scenario in a recent installer I worked on, I created a custom
action that ran after the DIFxAPP custom actions to ‘fixup’ the NetCfg
installed state on upgrade by removing/re-installing the NetService to
actually get an upgrade to behave correctly. In my case, rollback is not
necessary. If the application is removed, the NetService is not required
and is removed.

DIFxAPP does remove the OEMnnn.INF (and driver store entry) on uninstall.
I too faced the problem of prior (non-DIFx) installers having left behind
old versions of the INFs and thus wrote code that enumerated the installed
INFs for a particular DeviceId (in this case, a Network ComponentId) and
removed the INFs using the SETUPAPI. This technique catches all of the
left over INFs, not just the *one* that is recorded in the registry if the
component happens to be installed. In other words, it works even if the
component is not installed.

Good Luck,
Dave Cattley

satheesh_babu_muthupandi · December 22, 2010, 9:19pm

Dave,

Thanks for the explanation.
I will try using the DIFxAPI and come back if I couldn’t make it.

Wish you and all a wonderful Christmas and happy New Year-2011 in advance.

Thanks
Satheesh

On Wed, Dec 22, 2010 at 2:42 PM, David R. Cattley wrote:

> NetService is a bit different than a PnP device enumerated in the device
> tree when it comes to downgrade / rollback. For an enumerated device, the
> presence of the device is independent of the ?installed state? of the
> driver
> package. The device is just ?there? and so if you remove one driver, the
> device (aka, PnP) would very much like to have some other driver installed
> on that device and so a subsequent device install will pick from what is
> available.
>
> In the case of a NetService, the removal of the service is just that ? a
> removal. To ?rollback? (or downgrade) the NetService must be installed
> again. In fact, all OBO references must be ?removed? before the NetService
> is removed. And there is no ?upgrade? either. Asking NetCfg to
> ?install?
> a NetService that is already installed is a no-op other than adding an OBO
> reference. The ?betterness? of any new Driver Package is irrelevant.
>
> So downgrade/rollback is entirely something that an application that is
> installing a NetService must do essentially on its own. To handle the
> upgrade scenario in a recent installer I worked on, I created a custom
> action that ran after the DIFxAPP custom actions to ‘fixup’ the NetCfg
> installed state on upgrade by removing/re-installing the NetService to
> actually get an upgrade to behave correctly. In my case, rollback is not
> necessary. If the application is removed, the NetService is not required
> and is removed.
>
> DIFxAPP does remove the OEMnnn.INF (and driver store entry) on uninstall.
> I too faced the problem of prior (non-DIFx) installers having left behind
> old versions of the INFs and thus wrote code that enumerated the installed
> INFs for a particular DeviceId (in this case, a Network ComponentId) and
> removed the INFs using the SETUPAPI. This technique catches all of the
> left over INFs, not just the one that is recorded in the registry if the
> component happens to be installed. In other words, it works even if the
> component is not installed.
>
> Good Luck,
> Dave Cattley
>
>
>
> —
> 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
>

Adrien_de_Croy · December 28, 2010, 4:14am

http-equiv=“Content-Type”>

On 23/12/2010 10:59 a.m., SatheeshBabu Muthupandi wrote:

cite="mid:AANLkTi=-yG+xxxxx@mail.gmail.com"
type=“cite”>Hi Adrien,

Just for clalification.

If you remove your old inf file (oemXX.inf) from the inf folder by
looking at the component’s registry, how do you handle the
downgrade driver (or rollback) scenario by the user?

we don’t handle down-grading of our software - only upgrading.

Regards

Adrien

cite="mid:AANLkTi=-yG+xxxxx@mail.gmail.com"
type=“cite”>

I’m also looking for a better solution to clean-up the oemXX.inf
files which are not cleaned up on subsequent installation of our
driver package

thanks in adv.

Satheesh

On Wed, Dec 22, 2010 at 1:44 PM, David R.
Cattley < href="mailto:xxxxx@msn.com">xxxxx@msn.com>
wrote:

it’s in our .inf file under NetCfgInstanceId

the value we provide there seems to be used by the os.

refer to href=“http://msdn.microsoft.com/en-us/library/ff554951%28VS.85%29.aspx”
target=“_blank”>http://msdn.microsoft.com/en-us/library/ff554951(VS.85).aspx
under

the DDInstall Section.

Thanks for pointing that out. I was clearly asleep when
reading your

original post (you mention in the first lines this is a LWF).

Cheers,

Dave Cattley

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars
visit:

href=“http://www.osr.com/seminars” target=“_blank”>http://www.osr.com/seminars

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

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

--
Adrien de Croy - WinGate Proxy Server -[http://www.wingate.com](http://www.wingate.com)

Adrien_de_Croy · December 28, 2010, 4:20am

Hi David

One thing I’m wondering about is your reference to the OBO tokens. You
mention that all OBO references must be removed.

We only ever install our LWF as OBO_USER, and that’s all we ever
uninstall it on behalf of as well.

Does it then matter which user account the installer / uninstaller is
run in?

Should I perhaps try OBO_SOFTWARE, and just put our product /
manufacturer details in the OBO_TOKEN?

thanks

Adrien

On 23/12/2010 11:42 a.m., David R. Cattley wrote:

NetService is a bit different than a PnP device enumerated in the device
tree when it comes to downgrade / rollback. For an enumerated device, the
presence of the device is independent of the ‘installed state’ of the driver
package. The device is just ‘there’ and so if you remove one driver, the
device (aka, PnP) would very much like to have some other driver installed
on that device and so a subsequent device install will pick from what is
available.

In the case of a NetService, the removal of the service is just that – a
removal. To ‘rollback’ (or downgrade) the NetService must be installed
again. In fact, all OBO references must be ‘removed’ before the NetService
is removed. And there is no ‘upgrade’ either. Asking NetCfg to ‘install’
a NetService that is already installed is a no-op other than adding an OBO
reference. The ‘betterness’ of any new Driver Package is irrelevant.

So downgrade/rollback is entirely something that an application that is
installing a NetService must do essentially on its own. To handle the
upgrade scenario in a recent installer I worked on, I created a custom
action that ran after the DIFxAPP custom actions to ‘fixup’ the NetCfg
installed state on upgrade by removing/re-installing the NetService to
actually get an upgrade to behave correctly. In my case, rollback is not
necessary. If the application is removed, the NetService is not required
and is removed.

DIFxAPP does remove the OEMnnn.INF (and driver store entry) on uninstall.
I too faced the problem of prior (non-DIFx) installers having left behind
old versions of the INFs and thus wrote code that enumerated the installed
INFs for a particular DeviceId (in this case, a Network ComponentId) and
removed the INFs using the SETUPAPI. This technique catches all of the
left over INFs, not just the *one* that is recorded in the registry if the
component happens to be installed. In other words, it works even if the
component is not installed.

Good Luck,
Dave Cattley

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

–
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

David_R_Cattley · December 28, 2010, 9:50am

AFAIK there is only one OBO_USER reference possible in the system regardless
of how many times the ‘user’ might request a component be installed. So
removing just once is all that can be done. And if that is the only
reference then the component will be removed.

The only reason I bring up OBO_xxxx is that DIFxAPP and DIFxAPI will always
install an Network component with an OBO_SOFTWARE reference which maps back
to the DIFx driver store entry. If you install with DIFx you must either
uninstall with DIFx or do some rather challenging dancing to remove the
component.

The account you run the installer from does not matter (the ‘user account’
is not associated with OBO_USER in any way). The account must have the
privilege of course but no other significance is extracted from the
particular user account. OBO_USER is not a specific user but more to
convey “because the user wanted it” whereas OBO_SOFTWARE is “because
softwtware package XXXX wanted it” and OBO_COMPONENT is (well, you get it).

If you switch to OBO_SOFTWARE you cannot remove the component with the GUI
(shell), BindView, or NETCFG.EXE. Think about that before making any
changes voluntarily. When I moved to DIFxAPP, I had to develop a raft of
Swiss-Army-Knife style tools to rip out and clean-up busted installs that
had OBO_SOFTWARE based references left behind. DIFxAPP is great but the
path for Network components is a little narrow and slippery. Caveat Emptor.

Good Luck and Happy New Year,
Dave Cattley