Open dmiller-nmap opened 2 years ago
To create a NetCfg performance trace/log, use the following procedure:
<OutputLocation>
, <RootPath>
, and <Subdirectory>
elements. Alternatively, this can be done via Performance Monitor after the template is imported.logman import netcfg_trace -xml netcfg_trace.xml
logman start netcfg_trace
logman stop netcfg_trace
The XML config was generated by creating a trace in Performance Monitor for the "Microsoft-Windows-Network-Setup" trace provider and exporting it with the "Save template..." action.
@jtippet: Is there any way to use this trace to identify a problem? Do you have any ideas or suggestions?
Wow, you've stumbled deep into the dark alleyway of INetCfg guts...
"Compatibility key projections" is the bit that writes out all the registry keys that NetCfg used to write, prior to win10. The OS itself doesn't use any of these keys anymore, but we leave them lying around for all the apps that think they're entitled to go rummaging through NetCfg's internal state. (Anecdote: Early in win10, we had an appcompat bug because one of our supposedly-private registry keys contained an stringified representation of a GUID that used lowercase for the hexadecimal digits, while the 3rd-party app only worked if the GUID was written in UPPERCASE.... So after banging my head against the desk on that, I made a unit test that runs both the win8 netcfg and the current netcfg inside parallel sandboxes, then asserts that both write the exact same stuff to the registry during typical driver operations.)
14393 is a very old OS build. I remember one problem we had in roughly that timeframe was that when writing to a driver's service key (like HKLM\System\CurrentControlSet\Services\foo\...
), some 3rd party antimalware product would block the write. It did this in a very messy way: it allowed usermode to open the key with the KEY_SET_VALUE
right, but then returned STATUS_ACCESS_DENIED
when actually calling the syscall behind RegSetValueExW
. Since that's a violation of the semantics of the syscalls, NetCfg did not handle that situation very gracefully in earlier builds of win10. I'm not sure that's what's happening here, but it is plausible, since the plugin is trying to write keys all over the system. tldr: have the customer try temporarily suspending any 3rd party antivirus and retrying the install.
We keep persistent logs in c:\Windows\Logs\NetSetup
. I believe you need to work at Microsoft in order to decode that file, but I'd be happy to do that for you. We don't consider those logs to have personally-identifiable information (it's just the names of network drivers, hardware IDs, timestamps and PIDs), but out of an abundance of caution, please don't publish the raw ETL files publicly, unless the log is from a test/lab machine that you don't care about. You can email them to my github account name @microsoft.com. The customer does not need to attempt another repro; the logs typically go back at least a month, and would include any NetCfg errors in that time.
It may help to know if indeed we're getting back some error on a write to the registry -- procmon can gather the evidence for that. The customer would have to attempt another repro for that, and that trace file definitely contains personal information. So this is optional.
Thanks so much! We'll look into these options for the customer.
Thanks @jtippet, this is great info!
A customer has reported Npcap fails to install with the error 0x80070006. Logs show that the driver installation via SetupAPI succeeds (no errors in SetupAPI.dev.log), but the installation/binding as a NDIS LWF via the NetCfg API fails. OS is Microsoft Windows 10 Enterprise 2016 LTSB, build 14393, x86_64.
Relevant portion of NPFInstall.log:
Previously, we were unable to further diagnose problems like this because NetCfg does not provide a text log or event log entries. However, we have identified a way to use performance tracing to produce a log of NetCfg internals (posted below as comment). Unfortunately, we have so far not identified the reason for the error. Here are the relevant results from the most recent API call that failed:
So the error stack appears to be:
ObjectEventSink::OnModifyObject
returns -2,147,418,113, which is 0x8000ffff E_UNEXPECTED "Catastrophic failure"