Error when calling INetCfgClassSetup::Install

NTDEV
1

Hi Experts,
I am writing a Windows service application from which I am calling INetCfgClassSetup::Install API to install my IM driver.It works fine with Windows Server 2008.

My issue here is:
When I run the same service in Windows Server 2003 ,INetCfgClassSetup::Install is returning an error with code ERROR_NOT_FOUND(element not found).But If I set the service property as Allow the Service to interact with Desktop everything goes well.

What I would like to know is:

  1. What is the relation between the Service property - Allow the Service to interact with Desktop and INetCfgClassSetup::Install function?

  2. If there is a relation why is it working successfully in Windows server 2008 without setting that property?

3.When I set the service type parameter as SERVICE_INTERACTIVE_PROCESS in Create service function,it does not have any impact.Why?

  1. I know it is not advisable to allow the service to interact with desktop.Is there any better way of solving this issue?

When I googled I found couple of work arounds like editing type subkey under the particular service entry in the registry.(ORing the type value with 256).I guess Allow the service to interact with Desktop also does the same.But I would like to hear from the experts on this issue.

Please provide your valuable inputs.

Regards
Alex.

2

xxxxx@gmail.com wrote:

When I run the same service in Windows Server 2003, INetCfgClassSetup::Install
is returning an error with code ERROR_NOT_FOUND(element not found).
But If I set the service property as Allow the Service to interact
with Desktop everything goes well.

As compared to earlier versions of Windows, NT 5.1 was the first
platform where I encountered “server-side installations” of an
unsigned driver (a non-WHQL-signed driver) being blocked if the
install was attempted in a non-interactive context.

Presumably in relation to singing, this was to prevent the
installation from occurring in a context where approval of a
non-WHQL-signed driver couldn’t be interactively prompted. Not sure
if in your case the signing aspect is really at issue, or whether
there is some other more literal flag of “this device requires an
interactive installation context” that is leading to the same outcome.

(In the signing-related case we had observed, note that the signing
requirement was being enforced for the non-interactive installation
attempt regardless of whether the particular network component class
installed via INetCfg was even subject to the driver signing policy;
i.e. the classes cited by [DriverSigningClasses] from certclas.inf.)

You might look for clues to what exactly has been blocked/denied in
the SETUPAPI.LOG, although in the signing case it was no more verbose
than “blocked (server install)”.

Alan Adams

3

Thank you so much for the reply Alan Adams.