HLK NdisStudio tests blocked: stale 'nds-protocol' NetSetup object, NetSetupCreateObject fails with 0x800700B7

Question

HLK NdisStudio tests blocked: stale 'nds-protocol' NetSetup object, NetSetupCreateObject fails with 0x800700B7

Abhishek Naik 0

Hello,

All [NdisStudio] OidRequestTest jobs fail on our HLK client before any test logic runs. We have root-caused it to a stale NetSetup object and need a supported way to remove it.

ENVIRONMENT

HLK client: Windows 11 Pro for Workstations, build 10.0.26200
HLK/kit version on client: 10.0.26100 (controller: LAB-PC4)
NdisStudio driver: ndisstudio.inf, 10.0.26100.8328
TAEF: v10.104k x64
Device under test: NetAdapterCx virtual Ethernet adapter (SIMA_BUS\VIRTUALNETADAPTER\0)

SYMPTOM

Job "[NdisStudio] OidRequestTest - OID_GEN_VENDOR_DRIVER_VERSION Verification" fails in TestClassSetup:

Error: Verify: Caught an unidentified C++ exception during

(m_protocolGuid = protocolDriver.Create(m_transaction))

[File: onecore\net\ndis\studio\testv2\utilities\protocol.cpp,

Function: Ndis::Studio::Protocol::SetupProtocolDriver, Line: 63]

Error: TAEF: Setup fixture 'NdisStudioOidRequestTest::OidRequestTest::TestClassSetup' failed.

The same failure reproduces outside HLK by running TE.exe directly, and against the inbox Intel I210 NIC as well, so it is not specific to our driver.

ROOT CAUSE FOUND SO FAR

Under cdb, the first exception is NetSetupApi!HResultException thrown from:

NetSetupApi!NetSetupRpcClient::CreateObject

NetSetupApi!NetSetupCreateObject

ndis_studio_oidrequesttest!NetSetup2::ObjectCreationTemplate::Create

ndis_studio_oidrequesttest!Ndis::Studio::Protocol::SetupProtocolDriver

HRESULT = 0x800700B7 (ERROR_ALREADY_EXISTS). NetSetupSvc is running normally.

We found a leftover registry key:

HKLM\SYSTEM\CurrentControlSet\Services\nds-protocol

Linkage\Bind/Export/Route list 7 adapter GUIDs
'sc qc nds-protocol' returns 1060 (no such service)
no matching component in 'netcfg -s n', no adapter binding, no entry under the network protocol class {4d36e975-e325-11ce-bfc1-08002be10318}

Deleting the key succeeds, but it is recreated on the next boot and the test still fails. HKLM\SYSTEM\CurrentControlSet\Control\NetworkSetup2 cannot be read even when running as SYSTEM, so we cannot inspect or clean the stored object.

This started after two NdisStudio HLK jobs were cancelled mid-run, which we assume left the object behind.

QUESTIONS

Is this a known issue with NdisStudio on OS build 26200 / this HLK version?
What is the supported way to delete a stale 'nds-protocol' NetSetup ProtocolDriver object, short of 'netcfg -d' or reimaging the machine?
Should NdisStudio clean up this object when a run is interrupted, and is a fix planned?
If no cleanup is available, is an errata for these jobs an option?

Thank you,

Abhishek Naik

SiMa.ai

0 comments

1 answer

Your answer

Answer 1

Hi Abhishek,

Thank you for the detailed investigation. The failure occurs during NdisStudio’s protocol creation in TestClassSetup, before OID verification begins. Reproducing it through TE.exe and against the inbox Intel I210 adapter is useful evidence that this is not specific to your NetAdapterCx implementation.

0x800700B7 indicates an object already exists. However, the recurring nds-protocol service key does not, by itself, identify the conflicting NetSetup object. The timing after cancelled jobs makes incomplete cleanup a plausible explanation, but it is not yet a confirmed cause.

On your specific questions:

Known issue and kit compatibility: This report alone does not establish a known NdisStudio defect or an unsupported HLK/OS combination. The abbreviated 26100 kit version versus OS build 26200 is insufficient to conclude a mismatch. Please provide the full controller and client HLK versions, including installed updates, and compare the installed release with the HLK release table. Updating the kit should not be assumed to repair the existing configuration.

Targeted cleanup: I don’t have a documented, supported command to recommend for removing this specific orphaned object. Since deleting the service key did not resolve it, I would avoid further registry deletion or changing permissions on NetworkSetup2. The next step is an HLK support investigation specifically requesting targeted recovery that preserves the remaining network configuration—not simply another attempt to delete the visible service key.

Interrupted-run cleanup and fix status: Whether cancellation left the object behind, what cleanup is expected at that stage, and whether a fix exists require confirmation from the test owners. There is no confirmed fix or timeline to share from the information available here.

Errata: HLK errata can address incorrect failures caused by test or operating-system defects, often through filters. Applicability to these jobs needs review; it should not be assumed that an existing filter covers this failure.

For the support case, include the full HLK versions, failing job logs, debugger stack and HRESULT, and the cancellation/reproduction sequence you already documented. Your cross-adapter reproduction and the fact that the key returns after reboot are particularly useful. Share any requested registry excerpts through the support case rather than posting a full SYSTEM-hive export publicly.