Adding new network adapter on Vista from under LocalService

Hi guys,

I wonder if anyone dealt with the following problem. Our app is running on Vista as a service. If it attempts to add new virtual network adapter, the call to SetupDiCallClassInstaller(DIF_INSTALLDEVICE) never returns. The same code works just fine when it is invoked by the installer. Also it works fine on XP both as a part of the installer and when invoked from within the service.

Looking in setupapi_app.log, the process appears to stall at this point -


cci: [NCI BEGIN START SERVICES]
cci: NCI: Starting device ROOT\NET\0001
cci: NCI: SP_DEVINSTALL_PARAMS.Flags 0x02810020. Set result 0x00000000
cci: NCI: SP_DEVINSTALL_PARAMS.FlagsEx 0x00001010. Set result: 0x00000000
dvi: {Restarting Devices} 02:18:11.091
dvi: Query-remove: ROOT\NET\0000

cci: NCI: 6to4svc.dll asking for write lock.
cci: NCI: 6to4svc.dll asking for write lock.
��:V[����Pj����

Note the garbage at the very end and two entries of 6to4svc.dll asking for a write lock. Same portion of the log generated by a successful install looks like this -


cci: [NCI BEGIN START SERVICES]
cci: NCI: Starting device ROOT\NET\0000
cci: NCI: SP_DEVINSTALL_PARAMS.Flags 0x02810020. Set result 0x00000000
cci: NCI: SP_DEVINSTALL_PARAMS.FlagsEx 0x00000010. Set result: 0x00000000
dvi: {Restarting Devices} 09:09:08.477
dvi: Restart: ROOT\NET\0000
dvi: Restart complete.
dvi: {Restarting Devices exit} 09:09:10.399
cci: [NCI END START SERVICES]

I am inclined to think it’s a bug in Vista’s setup module, because I can’t see any other reasonable explanation for the garbage in the log file. Double locking also looks quite suspicious, as does the fact of 6t04svc asking for a lock at this point of device installation.

In any case - if this rings a bell to anyone, I am very interested to hear about it.

Thanks,
Alex

Hi there @ Hamachi,

A question: is your driver signed? otherwise, how do you beat the popup?

Regards,
–PA

wrote in message news:xxxxx@ntdev…
> Hi guys,
>
> I wonder if anyone dealt with the following problem. Our app is running on
> Vista as a service. If it attempts to add new virtual network adapter, the
> call to SetupDiCallClassInstaller(DIF_INSTALLDEVICE) never returns. The
> same code works just fine when it is invoked by the installer. Also it
> works fine on XP both as a part of the installer and when invoked from
> within the service.
>
> Looking in setupapi_app.log, the process appears to stall at this point -
>
> …
> cci: [NCI BEGIN START SERVICES]
> cci: NCI: Starting device ROOT\NET\0001
> cci: NCI: SP_DEVINSTALL_PARAMS.Flags 0x02810020. Set result
> 0x00000000
> cci: NCI: SP_DEVINSTALL_PARAMS.FlagsEx 0x00001010. Set result:
> 0x00000000
> dvi: {Restarting Devices} 02:18:11.091
> dvi: Query-remove: ROOT\NET\0000
>
> cci: NCI: 6to4svc.dll asking for write lock.
> cci: NCI: 6to4svc.dll asking for write lock.
> ��:V[����Pj����
>
> Note the garbage at the very end and two entries of 6to4svc.dll asking for
> a write lock. Same portion of the log generated by a successful install
> looks like this -
>
> …
> cci: [NCI BEGIN START SERVICES]
> cci: NCI: Starting device ROOT\NET\0000
> cci: NCI: SP_DEVINSTALL_PARAMS.Flags 0x02810020. Set result
> 0x00000000
> cci: NCI: SP_DEVINSTALL_PARAMS.FlagsEx 0x00000010. Set result:
> 0x00000000
> dvi: {Restarting Devices} 09:09:08.477
> dvi: Restart: ROOT\NET\0000
> dvi: Restart complete.
> dvi: {Restarting Devices exit} 09:09:10.399
> cci: [NCI END START SERVICES]
>
> I am inclined to think it’s a bug in Vista’s setup module, because I can’t
> see any other reasonable explanation for the garbage in the log file.
> Double locking also looks quite suspicious, as does the fact of 6t04svc
> asking for a lock at this point of device installation.
>
> In any case - if this rings a bell to anyone, I am very interested to hear
> about it.
>
> Thanks,
> Alex
>
>

The driver is signed. Its .cat is signed too. This appears to be not a cause of the problem, because it locks up way after authentication checks.

Hmm … the garbage at the end of the log file is actually some sort of a temporary state data used by the setupapi logging module. It is always there when something is being installed.

Secondly, killing the service that issues the SetupDiCallClassInstaller resolves the lock up and the setup completes successfully. Furthermore, if the service spawn separate process to call SetupDiCallClassInstaller, the lock up still happens and it persists until this child process is killed (i.e. the issue is not related to the inter-service deadlock or something like that).

wrote in message news:xxxxx@ntdev…
> Hmm … the garbage at the end of the log file is actually some sort of a
> temporary state data used by the setupapi logging module. It is always
> there when something is being installed.
>
> Secondly, killing the service that issues the SetupDiCallClassInstaller
> resolves the lock up and the setup completes successfully. Furthermore, if
> the service spawn separate process to call SetupDiCallClassInstaller, the
> lock up still happens and it persists until this child process is killed
> (i.e. the issue is not related to the inter-service deadlock or something
> like that).
>

Still, does it look like it waits for some (invisible) msgbox?
Can you get stack of that process while it “locks up”?

–PA

I doubt it waits for the message box, because it stalls between these two lines (setupapi.dev.log) -

dvi: Install Device: Removing device sub-tree. 10:11:13.621
dvi: Install Device: Removing device sub-tree completed. 10:12:15.637

I just don’t see what it can be asking/prompting for … though it’s Vista, so I guess it might be saying something like “Wow ! Removing device sub-tree ?” :slight_smile:

I will try and get the stack, good idea. Just to be sure.

Alex

I found the actual trigger of this problem. So, in case if someone else runs into this stuff, here it is -

The call to SetupDiCallClassInstaller() with either DIF_INSTALL or DIF_PROPERTYCHANGE will hang on Vista if the driver is loaded and has its WDM device opened (e.g. from some application via CreateFile). In my case, it’s the device created with NdisMRegisterDevice().

This is clearly a bug in Vista kernel.