Netwtw06 Driver Spams System Event Log

One evening I got into my head that since Windows was getting ever more insistent
that I should reboot my laptop to complete the installation of who know’s what updates
even though a week surely hadn’t yet passed since Microsoft last put me through
this disruption of shutting down my work, I would better change the irritation into
opportunity. I anyway had a growing list of experiments that I had long put off
because they too would require a few restarts. Now might as well be their time.
Part of this exercise had me open the Event Viewer to confirm the several expected
signs of the reconfigurations I was trying out and to check that my intended changes
hadn’t triggered any complaints.

Perhaps you ask why I make a story of such a routine exercise as looking at event
logs. Doesn’t every capable Windows user keep an eye on at least the System and
Application event logs, if not the other Windows Logs, just in the self-interest
of being aware of what’s normal for their computer? Therein lies a second part to
my story, for I confess that I have fallen out of the habit. These logs just aren't
as useful as they were. It’s not that fewer types of events that go into them are
useful. If anything, the variety of events that get logged these days is richer
and more useful than ever. Yet the logs as wholes are sometimes reduced almost to
complete uselessness by mass repetitions of events that cannot conceivably be the
slightest use to anyone in such quantity, if at all.

Time was that the Windows Logs could be relied on for a useful record of significant
events going back for months and even years. Mind you, in those halcyon days you
might reasonably expect that these logs would show no Error or even Warning in a
week of normal operation. Nowadays, even a fresh installation of Windows 10 comes
with errors and warnings in the Application and System logs just from Microsoft
components that complain of being misconfigured. And Microsoft bears much blame
for the cluttering, too. Operate your computer in some way that does not fit Microsoft’s
notions of Windows as a service and you can easily find that your Application log
is all but entirely given over to recurring Information events from some service
that Microsoft pretty much insists you must run even if it can hardly ever run usefully,
e.g., because you deliberately keep your computer off the Internet. But whether
the cause is a service or an application, from Microsoft or not, acting directly
or indirectly, the unwelcome practical consequence is that your Application log
has soon lost all record of anything significant about other programs even as recently
as yesterday. Flooding the System log seems to be less common, thankfully, but it
does occasionally get done by some errant driver.

Thus did it happen that I looked quickly at the System event log only to find
that it was full of events from Netwtw06—and not of some variety of events but of
just one event, 7023, logged every minute. These repeating instances of the one
event accounted for just short of 75% of all the events in the System log. This
one driver apparently thinks that this one piece of recurring information that is
very specific to this driver alone should have over 10 times the weight of all the
general-purpose system-level information from the various sources whose names start
with Kernel. I make this last comparison to emphasise, especially in case you’re
from Intel, how very, very arrogantly rude it is to write so much of one vendor-specific
thing to the primary shared repositories of significant general-purpose events.

Windows has long provided for special-purpose events to go to special-purpose
logs. It’s long past time that polluting the general-purpose logs was regarded as
unprofessional, at best. There is nothing but shame in the standard practice of
telling complainants that an event is harmless and can safely be ignored.
Though a single event may tell of no harm in and of itself,
repeating it by the hundreds and thousands into the general-purpose Windows Logs
causes the significant harm of exhausting these ordinarily capacious logs and robbing
users of potentially valuable history.

Problem

On a Lenovo X1 Carbon with an “Intel(R) Dual Band Wireless-AC 8265” as its built-in
wireless network adapter, but presumably on other computers and network adapters,
you find the System event log is flooded with events for which:

Source is Netwtw06;

Event ID is 7023;

the plain-text description is “7023 - Intel proprietary”.

The relevance of the wireless network adapter is that the source of the event,
Netwtw06.sys, is an Intel® Wireless WiFi Link Driver, according to the description
in the driver’s resources. If you call up the Properties for your wireless network
adapter in the Device Manager and ask for the Driver Details, you will see Netwtw06.sys.

Intel Support

Even without thinking what can be meant by Netwtw06 being named as the Source
of the event, you might start typing Netwtw06 into Google. You may find, as I did
yesterday, 18th August, 2018, that Google’s type-ahead soon predicts “netwtw06 7023
intel proprietary”. So, you are not alone! Indeed,
Wireless driver spamming Windows
Event Log on Intel’s community site begins with an observation of this same
event recurring “every 9-11 seconds” on an “Intel Dual Band Wireless-AC 8260 chip
on a Lenovo P50” in March 2018. Another participant reports 42,762 occurrences of
this event. Yet another, now in May, reports its recurrence “every minute”. This
“rate of 1 a minute” is observed independently for
Intel Wireless Driver generating
unnecessary windows events..

That you are not alone is no rescue. These threads at Intel’s site are an embarrassing
sample of how the software industry treats its customers. I do not mean anything
critical of the individual who “posted on behalf of Intel Corporation” and surely
did mean to help. The poor guy was likely just following his training about Intel’s
practices, which seem at the very least to be designed so that deflection and obtuseness
face no disincentive but initiative perhaps does. It would be sadly naive to hope
that the name of an Intel driver, a large-ish number and the text “Intel proprietary”
are recognised as specific identifiers to feed into a support database or even to
pass directly to the engineering team that would know why the event exists. No,
there must first be a standard collection of largely irrelevant information. Then
there must be a deflection: “we can’t prevent a driver from triggering events.”
And then a shooting of the messenger: “Event Viewer is not an Intel software, and
event tracking cannot be disabled from the driver”. Even after the patient, tactful
user (gabe_luci) points out that it is Intel’s software that provides the event
and Intel’s software developers who can stop doing so, Intel “can’t confirm if these
events are part of the driver design.” Seriously? What can be the point to “Intel
proprietary” in an Intel driver except that it’s by design? And, of course, the
passing on is still not to any engineer who might know immediately what 7023 ever
signified but is instead to “our business unit”. It goes on like this for some time.
Intel, please, lift your game!

Solution

It’s surely best to get to the good news now. The immediate
problem goes away in the 20.60.0.7 build. Presumably, later builds will be
good too.

The first of the Intel community threads that I cite above does by June 2018
proceed to announce with some authority the release of
Intel® PROSet/Wireless Software and Drivers for Windows® 10 version 20.60.0,
though without explanation and indeed with curiously little confidence that the
new build actually does fix the problem. In what I downloaded from this link yesterday,
18th August, 2018, the NETWTW06.SYS driver has version 20.60.0.7.

Of course, I do not say the problem goes away in version
20.60.0.7 merely because I installed it and have found that the problem does not
recur for me. No, I say with certainty that the problem has gone away in
this build because I know from inspecting the binary that in some build between
the 20.50.1.1 which I had been using and the newly obtained 20.60.0.7, Intel removed
the one C++ statement that had the driver write event 7023 to the System log. If
you’re not a reverse engineer, then you can get some (much) lesser assurance by
searching these versions of the driver for “7023 - Intel proprietary” as Unicode
text. It’is gone from the new driver’s resources. And if that’s too much trouble,
then just install the new driver and make do with the observation, which hits us
all, that those tens of thousands of Netwtw06 events with Event ID 7023 that were
put into your System log by the old driver now come with complaints of how “The
description for Event ID 7023 from source Netwtw06 cannot be found.”

Note also that I venture only that the immediate
problem goes away. Whatever caused earlier versions of the driver to write event
7023 to the System log very possibly still occurs. As I explain below, event 7023
means little more than that the driver received a network request from an Independent
Hardware Vendor (IHV) extensibility module. For some few types of IHV request, the
driver does not write event 7023. For all others, it does. In essence, event 7023
means just that Intel’s driver received an “Intel proprietary” request. It’s at
least a sound proposition that different users were seeing the event from having
received different types of these requests and that some were seeing it from multiple
types. It’s possible, of course, that Intel has found some sources of these requests
and dealt with them. It may also be possible that IHV requests can be received from
sources that have nothing directly to do with Intel or aren’t even Intel’s to control.
Either way, the one and only reason that you or anyone else ever got Netwtw06 event
7023 in the System log is that Intel’s Netwtw06 put it there, and the one and only
reason that neither you nor anyone else can ever see any repeat of event 7023 after
updating to version 20.60.0.7 is that this build simply
has no code for writing this event.

The wonder, of course, is that back at the coal face of customer support the
new build was presented only as something to try and see: “let us know if the events
keep showing up with the same frequency”. Intel’s programmers who work on Netwtw06.sys
must have known that the new version removes the code and cannot write the event.
That’s as conclusive as things ever are in software, so how could such definiteness
not feed back to the affected customers? Again, Intel, please lift your game!

Explanation

The removed C++ statement is in a routine that Intel apparently names
osal::CCmdPropIhvRequest::execute. This name is known
because Intel’s programmers carelessly leave it and many others in plain sight as
text for Windows Pre-Processor (WPP) tracing. This is remarkable because one of
the main attractions of WPP tracing is that the format strings of the trace statements
do not bloat the binary. They instead become annotations in the Program Database
(PDB) file, which is more commonly referred to as the symbol file. That any one
trace statement is at line number x in some source
file y and is within some routine
z is in the symbol file, safely removed from the
prying eyes of reverse engineers. Yet here is an Intel driver in which many of the
WPP trace statements pass the name of the containing routine as an argument. I don’t
complain about the help, but I do observe that it’s misplaced: if Intel wants to
help, then ordinary users are more deserving than reverse engineers.

Of course, that Intel names the routine to suggest execution for an IHV request
doesn’t mean that this is what the routine actually does, but inspection establishes
a flow of execution from the routine that Intel names osal::CNdis::miniportOidRequest
and which Netwtw06 registers with NDIS as its
MiniportOidRequest routine for handling what Microsoft’s NDIS documentation
refers to as an OID request, and the path from this entry point to
osal::CCmdPropIhvRequest::execute is specifically for
handling requests whose Oid in the
NDIS_OID_REQUEST structure is
OID_WDI_IHV_REQUEST (0xE440005D).

This OID_WDI_IHV_REQUEST is intended as distinguishing
requests that an IHV extensibility DLL in user mode sends to a WLAN Device Driver
Interface (WDI) miniport driver in kernel mode. It’s new for Windows 10. My take
on it is that it continues Microsoft’s tidying of an old free-for-all of vendor-specific
OIDs in competition wiith system-defined OIDs, though for this purpose it seems
curiously under-documented by Microsoft and as much under-discussed in public by
others. (A Google search for OID_WDI_IHV_REQUEST today,
26th August, turns up just three matches.)

Though a WDI miniport driver for Windows 10 does not receive vendor-specific
OIDs directly in requests to its MiniportOidRequest
routine, it can keep to any old scheme of vendor-specific OIDs by packaging them
into the vendor-specific information that they pass with the system-defined
OID_WDI_IHV_REQUEST. Thus do we get to the initial
work of osal::CCmdPropIhvRequest::execute, first with
the help of a member function named prepareNicSpecificOidFromWdiIhvRequest
to unpack the IHV request into the form of a request whose OID is the less new
OID_DOT811_NIC_SPECIFIC_EXTENSION, and then with the
help of a routine named oscMiniportTranslateProprietaryOid
to unpack the request as Intel presumably intended all along.

Expected OIDs

The very long table that follows lists the several hundred different OIDs that
Netwtw06 explicitly recognises in the unpacking of an IHV request. That I list all
these many OIDs is because I want you to take in the scale and variety, if only
as you scroll rapidly past.

For each OID in the table, an IHV request that has this OID gets non-trivial
OID-specific handling. For a relative handful that are marked “no” in the right-hand
column, Netwtw06 proceeds directly to this OID-specific handling. For all the many
others in the table, Netwtw06 first writes event 7023 to the System event log. For
any IHV request that Netwtw06 receives but whose unpacked OID is not in the table,
Netwtw06 also writes event 7023 to the System event log but then fails the request
as unsupported (specifically by returning the error code
NDIS_STATUS_NOT_SUPPORTED).

OID

Symbol

Event 7023

0x00010104

OID_GEN_MEDIA_IN_USE

0x00010107

OID_GEN_LINK_SPEED

no

0x01010101

OID_802_3_PERMANENT_ADDRESS

0x01010102

OID_802_3_CURRENT_ADDRESS

0x0D010101

OID_802_11_BSSID

0x0D010113

OID_802_11_ADD_WEP

0x0D010114

OID_802_11_REMOVE_WEP

0x0D010118

OID_802_11_AUTHENTICATION_MODE

0x0D01011A

OID_802_11_BSSID_LIST_SCAN

0x0D01011B

OID_802_11_ENCRYPTION_STATUSOID_802_11_WEP_STATUS

0x0D01011C

OID_802_11_RELOAD_DEFAULTS

0x0D01011D

OID_802_11_ADD_KEY

0x0D01011E

OID_802_11_REMOVE_KEY

0x0D01011F

OID_802_11_ASSOCATION_INFORMATION

0x0D010120

OID_802_11_TEST

0x0D010121

OID_802_11_MEDIA_STREAM_MODE

0x0D010122

OID_802_11_CAPABILITY

0x0D010123

OID_802_11_PMKID

0x0D010203

OID_802_11_NETWORK_TYPES_SUPPORTED

0x0D010204

OID_802_11_NETWORK_TYPE_IN_USE

0x0D010206

OID_802_11_RSSI

0x0D010207

OID_802_11_RSSI_TRIGGER

0x0D010209

OID_802_11_FRAGMENTATION_THRESHOLD

0x0D01020A

OID_802_11_RTS_THRESHOLD

0x0D01020B

OID_802_11_NUMBER_OF_ANTENNAS

0x0D01020C

OID_802_11_RX_ANTENNA_SELECTED

0x0D01020D

OID_802_11_TX_ANTENNA_SELECTED

0x0D01020E

OID_802_11_SUPPORTED_RATES

0x0D010210

OID_802_11_DESIRED_RATES

0x0D010211

OID_802_11_CONFIGURATION

0x0D010216

OID_802_11_POWER_MODE

0x0D010217

OID_802_11_BSSID_LIST

0x0D01031E

OID_DOT11_MAC_ADDRESS

0x0D010702

OID_DOT11_CURRENT_ADDRESS

0x0D010703

OID_DOT11_PERMANENT_ADDRESS

0x0E010280

OID_DOT11_PMKID_LIST

0xFF00070E

OID_IWLAN_INITIATOR_DELBA_REQ

0xFF00070F

OID_IWLAN_RECIPIENT_DELBA_REQ

0xFF000711

OID_IWLAN_MMAC_ADDBA

0xFF000712

OID_IWLAN_MMAC_INITIATOR_DELBA

0xFF000713

OID_IWLAN_MMAC_REMOTE_BA

0xFF000714

OID_IWLAN_RX_BACK_DISABLED

0xFF000715

OID_IWLAN_CALC_FRAME_DURATION

0xFF000805

OID_IWLAN_SEND_MIMO_PS_HT_ACTION

0xFF000806

OID_IWLAN_SEND_TX_CHANNEL_WIDTH_HT_ACTION

0xFF000C06

OID_IWLAN_SET_UAPSD

0xFF030FF0

OID_WIFI_SEND_MGMT_FRAME

0xFF100000

OID_WIFI_ANTENNA_DIVERSITY

no

0xFF100002

OID_WIFI_AP_BSS_ID

0xFF100004

OID_WIFI_CHANNEL_ID

0xFF100006

OID_WIFI_PROTOCOL_TYPE

0xFF100007

OID_WIFI_ADAPTER_DATA_RATES

0xFF100008

OID_WIFI_BSS_PROBE_REQ_ADDTIONAL_IES

0xFF100009

OID_WIFI_ASSOCIATION_STATUS

no

0xFF10000C

OID_WIFI_DISASSOCIATE

0xFF10000F

OID_WIFI_POWER_MODE

0xFF100010

OID_WIFI_TX_POWER_CONTROL

0xFF100011

OID_WIFI_POWER_SOURCE

0xFF100012

OID_WIFI_ADAPTER_STATISTICS

0xFF100013

OID_WIFI_FIRMWARE_VERSION

0xFF100014

OID_WIFI_ADAPTER_CONFIGURATION

0xFF100015

OID_WIFI_DEVICE_INFORMATION

0xFF100016

OID_WIFI_ADHOC_CHANNELS

0xFF100017

OID_WIFI_HARDWARE_RADIO_SWITCH

0xFF100018

OID_WIFI_REGISTER_PROFILE_SERVICE

0xFF100019

OID_WIFI_CURRENT_PROFILE

0xFF10001A

OID_WIFI_PROTOCOL_PREFERENCE

0xFF10001B

OID_WIFI_BAND_PREFERENCE

0xFF10001F

OID_WIFI_FEATURES_SUPPORTED

0xFF100020

OID_WIFI_BSS_MODE

0xFF100022

OID_SV_ANT_SAD_MODE

0xFF100026

OID_WIFI_AUTHENTICATION_MODE

0xFF100027

OID_WIFI_ENCRYPTION_STATUS

0xFF100028

OID_WIFI_CTS_TO_SELF

0xFF100029

OID_WIFI_PREAMBLE_MODE

0xFF100030

OID_WIFI_INTEL_PACKET_BURST

0xFF100031

OID_WIFI_ATIM_WINDOW_SIZE

0xFF100032

OID_WIFI_CURRENT_BAND

0xFF100034

OID_WIFI_CISCO_LEAP_ROGUE_MODE

0xFF100037

OID_WIFI_IS_INTEL_CARD

0xFF100038

OID_WIFI_CISCO_ENCRYPT_EAP_PKTS

0xFF100039

OID_WIFI_CISCO_CWMIN_CWMAX

0xFF10003A

OID_WIFI_PLATFORM_MOTION_DETECTOR_STATE

0xFF10003B

OID_WIFI_PLATFORM_MOTION_DETECTION

0xFF100040

OID_WIFI_CISCO_MIXED_CELLS_MODE

0xFF100041

OID_WIFI_CISCO_TPC

0xFF100042

OID_WIFI_CISCO_ASSISTED_ROAMING

0xFF100043

OID_WIFI_PROFILE_SECURITY_SETTINGS

0xFF100044

OID_WIFI_CISCO_RADIO_MEASURMENTS

0xFF100045

OID_WIFI_CISCO_CCX_VERSION

0xFF100046

OID_WIFI_CISCO_QoS_PARAMETER_SET_IE

0xFF100047

OID_WIFI_PROP_AUTHENTICATION_MODE

0xFF100048

OID_WIFI_PROP_ENCRYPTION_STATUS

0xFF100049

OID_WIFI_ROAM_AGGRESSIVENESS

0xFF100051

OID_WIFI_GET_CURRENT_POWER

0xFF100052

OID_WIFI_GET_POWER_LEVEL

0xFF100053

OID_WIFI_GET_CISCO_VERSION

0xFF100055

OID_WIFI_GET_CISCOACU_PARAMS

0xFF100056

OID_WIFI_SET_CLNTNAME_CISCOAP

0xFF100110

OID_WIFI_GET_IWA_VERSION

0xFF100111

OID_WIFI_GET_EXCLUDE_LIST

0xFF100112

OID_WIFI_ADD_EXCLUDED_AP

0xFF100113

OID_WIFI_REMOVE_AP_FROM_EXCLUDE_LIST

0xFF100114

OID_WIFI_CLEAR_EXCLUDE_LIST

0xFF100115

OID_WIFI_EXCLUDE_ENABLE

0xFF100116

OID_WIFI_11K_RADIO_MEASURMENTS_STATE

0xFF100117

OID_WIFI_11K_RADIO_MEASURMENTS_REQUEST

0xFF100118

OID_WIFI_AD_HOC_CONNECTION

0xFF100119

OID_WIFI_ACK_MODE

0xFF100120

OID_WIFI_IBSS_QOS_STYLE

0xFF100121

OID_WIFI_ANT_RSSI

0xFF100122

OID_WIFI_CURR_RSSI_ACTIVE_AP

no

0xFF100123

OID_WIFI_NMPR_STATS_STATUS

0xFF100124

OID_WIFI_NMPR_CLOCK_SYNC_STATUS

0xFF100132

OID_WIFI_VOW_FEATURES_SUPPORT

0xFF100133

OID_WIFI_MAIN_UPDATE_IES

0xFF100134

OID_WIFI_GET_IWT_NOISE_DATA

0xFF100135

OID_WIFI_SET_IWT_SAMPLE_VALID_PERIOD

0xFF100136

OID_WIFI_APP_DRV_INTERFACE_VERSION

0xFF100137

OID_WIFI_ISV_SNIFFER_STATE

0xFF10013A

OID_WIFI_11N_MODE

0xFF10013B

OID_WIFI_11N_CHANNEL_MODE_52

0xFF10013C

OID_WIFI_11N_FAT_CHANNEL_INTOLERANT

0xFF100140

OID_WIFI_APP_SET_ASSOC_INFO

0xFF100141

OID_WIFI_CCX_SDK_KEEP_ALIVE_REFRESH

0xFF100142

OID_WIFI_CCX_SDK_SEND_PACKET

0xFF100143

OID_WIFI_CCX_SDK_NEIGHBOR_LIST

0xFF100144

OID_WIFI_CCX_SDK_DIRECTED_ROAM

0xFF100145

OID_WIFI_CCX_SDK_RM_REQUEST

0xFF100150

OID_WIFI_CCX_SDK_TSF

0xFF100152

OID_WIFI_CCX_SDK_LAST_BCN_TIME

0xFF100153

OID_WIFI_11N_CHANNEL_MODE_24

0xFF100301

OID_WIFI_COEX_SDK_SCAN_ERROR_CODE

0xFF100302

OID_WIFI_BT_COEX_BT_ACTIVE

0xFF100303

OID_WIFI_BT_COEX_WLAN_ACTIVE

0xFF100304

OID_WIFI_BT_COEX_FORCE_SHARED_ANT

0xFF100305

OID_WIFI_SET_PTA_MODE

0xFF100355

OID_WIFI_TIMINGMSMT_RQ_REQUEST

0xFF100356

OID_WIFI_TIMINGMSMT_REQUEST

0xFF100357

OID_WIFI_TIMINGMSMT_PTM_WA

0xFF100380

OID_WIFI_AP_AVERAGE_BEACON_RSSI

0xFF100381

OID_WIFI_DEVICE_SENSITIVITY

0xFF100382

OID_WIFI_DEVICE_SENSITIVITY_SETTINGS

0xFF100400

OID_WIFI_GENERIC_DEBUG

0xFF100450

OID_WIFI_MCC_API_TEST_MODE

0xFF100451

OID_WIFI_MCC_CONFIGURATION

0xFF100460

OID_WIFI_SAR_CONFIGURATION

0xFF100461

OID_WIFI_GEO_OFFSET_CONFIGURATION

0xFF100462

OID_WIFI_SAR_CONFIG_BIOS

0xFF100463

OID_WIFI_SAR_CONFIG_PSENSOR

0xFF100464

OID_WIFI_GEO_OFFSET_CONFIG

0xFF100465

OID_WIFI_SAR_CONFIG_PSENSOR_VER_2

0xFF100524

OID_WIFI_RX_FILTER_CONFIG

0xFF100525

OID_WIFI_BEACON_CHANGE_IND_CONFIG

0xFF100530

OID_WIFI_PEER_STAT

0xFF100540

OID_WIFI_NETDETECT_PROFILES_LIST

0xFF100541

OID_WIFI_WAKE_REASON

no

0xFF100542

OID_WIFI_NETDETECT_HOTSPOTS_LIST

0xFF100543

OID_WIFI_REMOTE_WAKE_CONFIG

0xFF100544

OID_WIFI_ARP_OFFLOAD

0xFF100546

OID_WIFI_REMOTE_WAKE_API_VS

0xFF100550

OID_WIFI_INSTANT_CONNECT

0xFF100600

OID_WIFI_11AC_NIC_CAPABILITIES

0xFF10060B

OID_WFDE_SET_PREFERRED_OPERATING_CHANEL

no

0xFF10060D

OID_WFDE_WFA_SIGMA_SET_GO_NOA_PARAMETERS

0xFF100800

OID_WIFI_WAPI_MODE

0xFF100801

OID_WIFI_WAPI_SET_ADD_CIPHER_KEYS

0xFF100802

OID_WIFI_SET_KEEPALIVE_PACKET

0xFF100803

OID_WIFI_WAKE_ON_TUNNEL_PACKET

0xFF100804

OID_WIFI_SET_ORBWEB_PACKETS

no

0xFF100805

OID_WIFI_APP_SET_WOWLAN_CONFIGURATION

no

0xFF100806

OID_WIFI_APP_GET_WOWLAN_CONFIGURATION

no

0xFF100807

OID_WIFI_APP_GET_WAKE_DATA

no

0xFF100808

OID_WIFI_P2P_GO_PREFERRED_CHANNEL

0xFF100809

OID_WIFI_P2P_GO_RESET_PREFERRED_CHANNEL

0xFF10080A

OID_WIFI_P2P_GO_QUERY_OPERATING_CHANNEL

0xFF10080B

OID_WIFI_P2P_GO_QUERY_SUPPORTED_CHANNELS

0xFF10080C

OID_WIFI_P2P_DISCOVER_FILTER

0xFF10080D

OID_WIFI_P2P_REMOVE_DISCOVER_FILTER

0xFF10080E

OID_WIFI_LEGACY_GO_SCAN_FILTER

0xFF10080F

OID_WIFI_RESET_LEGACY_GO_SCAN_FILTER

0xFF100810

OID_WIFI_S5_CONFIG

no

0xFF100811

OID_WIFI_SCAN_OPTIMIZATIONS_CONFIG

0xFF100812

OID_WIFI_BSS_LINK_STATISTICS

0xFF100E20

OID_PSM_CORE_SET_P_STATE

0xFF100E21

OID_PSM_CORE_GET_TEMPERATURE

0xFF100E22

OID_PSM_CORE_GET_CURRENT_P_STATE

0xFF100E23

OID_PSM_CORE_GET_SUPPORTED_P_STATES

0xFF100E24

OID_PSM_CORE_TEMPERATURE_BOUNDARIES

0xFF100E29

OID_TT_SIMULATOR

0xFF100F02

OID_WIFI_ALLOWED_TX_ANTENNAS

0xFF100F04

OID_WIFI_WEB_ENABLED

no

0xFF100F05

OID_WIFI_COEX_20_40_SEND_REPORT

0xFF100F06

OID_WIFI_DPPM

0xFF100F07

OID_WIFI_ADAPTER_MAXIMUM_TXPOWER

0xFF100F08

OID_WIFI_SAR_PSENSOR_EXTENDED_HID

0xFF100F11

OID_INTEL_LTE_COEX_MODEM_STATE

0xFF100F12

OID_INTEL_LTE_COEX_CONFIG_INFO

0xFF100F13

OID_INTEL_LTE_COEX_DYNAMIC_INFO

0xFF100F14

OID_INTEL_LTE_COEX_REPORTED_CHANNEL

0xFF100F15

OID_INTEL_LTE_COEX_SPS_INFO

0xFF100F16

OID_INTEL_LTE_COEX_WIFI_PREFERRED_CHANNELS

0xFF100F17

OID_INTEL_LTE_COEX_GET_ASSOC_INFO

0xFF400000

OID_SV_API_VERSION

0xFF400001

OID_SV_DIRECT_ACCESS

0xFF400002

OID_SV_INDIRECT_ACCESS

0xFF400003

OID_SV_PCI_CFG

0xFF400004

OID_SV_EEPROM

0xFF400005

OID_SV_LOG_LEVEL

0xFF400006

OID_SV_LOG_BUFFER_DESC

0xFF400007

OID_SV_COMMAND

0xFF400008

OID_SV_RESPONSE

0xFF400009

OID_SV_RESET_DRIVER

0xFF40000A

OID_SV_DRV_OBJ_ADDR

0xFF40000B

OID_SV_DRV_MEM

0xFF40000E

OID_SV_CONTINUOUS_TX

0xFF40000F

OID_SV_RX_HDR_MODE

0xFF400011

OID_SV_ORDINAL

0xFF400012

OID_SV_EEPROM_MAX_TX_POWER

0xFF400013

OID_SV_STA_CONFIGURATION

0xFF400014

OID_SV_SET_STA

0xFF400015

OID_SV_RX_ON_STATE

0xFF400016

OID_SV_SNR

0xFF400017

OID_SV_TX_CMD

0xFF400019

OID_SV_POWER_TARGET_CONTROL

0xFF40001A

OID_SV_RADAR_THRESHOLD

0xFF40001D

OID_SV_RELOAD_CHANNELS

0xFF40001F

OID_SV_JAWS

0xFF400021

OID_SV_CONNECTION_PRIORITY_SWITCH

0xFF400022

OID_SV_SET_STA_FLAGS

0xFF400023

OID_SV_TLC_THRESHOLDS

0xFF400024

OID_SV_TLC_PARAMETERS

0xFF400028

OID_SV_VHT_OPERATING_MODE

0xFF400029

OID_SV_RLC_PARAMETERS

0xFF40002A

OID_SV_OID_BA_HISTORY

0xFF40002B

OID_SV_LINK_QUAL_CMD

0xFF40002C

OID_SV_EEPROM_BURN_QUERY

0xFF40002D

OID_SV_LOG_MODULE_LIST

0xFF40002E

OID_SV_TX_LOOP

0xFF40002F

OID_SV_STA_CONFIG_NEW

0xFF40003A

OID_SV_THERMAL_MANAGEMENT

0xFF40003C

OID_SV_DRV_API_VERSION

0xFF40003D

OID_SV_DEVICE_SW_INFO

0xFF400044

OID_SV_SET_RATE

0xFF400050

OID_SV_READ_EEPROM

0xFF400051

OID_SV_EEPROM_COMMIT

0xFF400052

OID_SV_NVM_TYPE

0xFF400053

OID_SV_EEPROM_HIGH

0xFF400054

OID_SV_EEPROM_COMMIT_HIGH

0xFF400060

OID_SV_TX_FILTER_MODE

0xFF400061

OID_SV_TX_LINEARITY

0xFF400070

OID_SV_BF_TRIGGER

0xFF400071

OID_SV_BF_RESULT

0xFF400072

OID_SV_READ_BFEE_MATRIX

0xFF400073

OID_SV_UPLOAD_BFEE_MATRIX

0xFF400080

OID_SV_XVT_GET_CALIB_DATA

0xFF400083

OID_SV_SEND_TX_TEMP_GAIN_TABLE

0xFF400084

OID_SV_ADD_CH_CALIB_DATA

0xFF400085

OID_SV_PHY_CTX_SWITCH

0xFF400086

OID_SV_TRIGGER_ADC_SAMPLE

0xFF400087

OID_SV_ADC_SAMPLE_QUERY

0xFF400088

OID_SV_DTS_TRIGGER

0xFF400089

OID_SV_GET_SUPPORTED_CALIBRATIONS

0xFF40008A

OID_SV_USE_DEFAULT_TXPWR_TABLE

0xFF40008B

OID_SV_DIAGNOSTICS_EVENTS

no

0xFF400090

OID_SV_SYSTEM_MONITOR_CONFIG

0xFF400091

OID_SV_SYSTEM_MONITOR_DATA_REQ

0xFF400092

OID_SV_DRIVER_VERSION

0xFF400093

OID_SV_REGULATORY_DATA_QUERY

0xFF400094

OID_SV_DTS_TRIGGER_DRIVER

0xFF400100

OID_SV_STA_TBL_FLD_TX

0xFF400102

OID_SV_STA_TBL_FLD_SECURITY

0xFF400103

OID_SV_BSS_TBL_FLD_SECURITY

0xFF400104

OID_SV_KEY_TBL

0xFF400106

OID_SV_BSS_TBL_FLD_POLICY

0xFF400108

OID_SV_QOS_PER_STA_PER_TID_DATA

0xFF400109

OID_SV_CHANNEL_TBL

0xFF400110

OID_SV_BT_COEX_PROFILE

0xFF400111

OID_SV_BT_PROFILE_NOTIFICATION

0xFF400120

OID_SV_UCODE_TRACE_STOP_SAMPLING

0xFF400121

OID_SV_CLOCKS_INIT_OFDM_MIB

0xFF400122

OID_SV_CLOCKS_INIT_CCK_MIB

0xFF400123

OID_SV_CLOCKS_INIT_ANALOG_MIB

0xFF400126

OID_SV_PM_ADD_WOL_PATTERN

0xFF400127

OID_SV_PM_ADD_PROTOCOL_OFFLOAD

0xFF400129

OID_SV_ND_HOTSPOTS_DEBUG_QUERY_DATA

0xFF40012A

OID_SV_START_PSEUDO_S3

0xFF40012C

OID_SV_SET_POWER

0xFF40012D

OID_SV_PM_PARAMETERS

0xFF40012E

OID_SV_D3_MANAGER_DEBUG_CONFIG

0xFF40012F

OID_SV_NET_DETECT_DEBUG_QUERY

0xFF400130

OID_SV_QUERY_ERROR_LOG

0xFF400131

OID_SV_ERROR_LOG_ENABLE

0xFF400132

OID_SV_QUERY_MMAC_DEBUG_DUMP

0xFF400136

OID_SV_D3_MANGER_DEBUG_QUERY

0xFF40013A

OID_SV_ENABLE_INDICATIONS_TO_SV

0xFF40013B

OID_SV_QUERY_TFD_QUEUES_INFO

0xFF40013E

OID_SV_OVERRIDE_TARGET_TX_POWER

0xFF40013F

OID_SV_OVERRIDE_TX_POWER_RADIO_CONFIG

0xFF400140

OID_SV_GET_TX_POWER_INFO

0xFF400144

OID_SV_SET_LPRX

0xFF400146

OID_SV_CONTINUOUS_WAVE

0xFF400148

OID_GENERAL_PURPOSE_UT

0xFF400190

OID_SV_FLUSH_DDD_RECORDS

0xFF400191

OID_SV_DDD_INSERT_PLAYER_BREAKPOINT

0xFF400200

OID_SV_WIFI_CORE_RESETOID_SV_SET_DATA

0xFF400201

OID_SV_INDIRECT_ACCESS_EX

0xFF400202

OID_SV_NVM_CACHE_WRITE

0xFF400203

OID_SV_NVM_CACHE_COMMIT

0xFF400204

OID_SV_NVM_CACHE_READ

0xFF400205

OID_SV_OTP_TEST_AREA

0xFF400206

OID_SV_GET_SET_PHY_DB

0xFF400207

OID_SV_LMAC_BUS_ACCESS

0xFF400208

OID_SV_EVM_METER_MEASUREMENT

0xFF400209

OID_SV_RUNTIME_CAL_HANDLE

0xFF40020A

OID_SV_NVM_CACHE_GETSIZE

0xFF40020B

OID_SV_MOTION

0xFF40020E

OID_SV_RX_PACKET_FILTER

0xFF40020F

OID_SV_RLG_FLUSH_LOG_FILE

no

0xFF400210

OID_SV_APPLICATION_PRINT

no

0xFF400220

OID_SV_ANT_DRV_API_VERSION

0xFF400221

OID_SV_ANT_COUPLING

0xFF400302

OID_SV_EXECUTE_SNIFFER_CMD

0xFF400303

OID_SV_CONFIG_FW_DEBUG_CAP

0xFF400650

OID_SV_WFD_ROLES_INFO

no

0xFF600101

OID_INTEL_ISV_PMODE_ENABLE

0xFF600102

OID_INTEL_ISV_PMODE_DISABLE

0xFF600103

OID_INTEL_ISV_CHANNEL_LIST

0xFF600104

OID_INTEL_ISV_PMODE_BAND_CHANNEL

0xFF600105

OID_INTEL_ISV_ASSOCIATION_STATUS

0xFF600106

OID_INTEL_ISV_PMODE_PACKET_SLICE

0xFF600107

OID_INTEL_ISV_CURRENT_BAND_CHANNEL

0xFF600108

OID_INTEL_ISV_PMODE_BAND_CHANNEL_EX

0xFF700000

OID_SV_TLC_FIXED_RATE_UPDATE

0xFF800000

OID_XVT_IWL_CMD_HCMD

0xFFA0070A

OID_IWLAN_QOS_UAPSD_DEEP_SLEEP_MODE

0xFFEDC101

MH_OID_CCX_RAP_STATUS

0xFFEDC103

MH_OID_CCX_MIXED_CELLS

0xFFEDC105

MH_OID_CCX_8021X

0xFFEDC106

MH_OID_CCX_8021X_RESULT

0xFFEDC107

MH_OID_CCX_ADD_KRK

0xFFEDC108

MH_OID_CCX_REMOVE_KRK

0xFFEDC180

MH_OID_KEY_CAPABILITY

0xFFEDC182

MH_OID_KEY_MATERIAL

The symbols are Intel’s, from two tables that Netwtw06 has specifically for OIDs
that are unpacked from IHV requests. For the low-numbered OIDs, these names are
the same as defined in Microsoft’s NTDDNDIS.H and WINDOT11.H headers. OIDs whose
high byte is 0xFF are vendor-specific. For these, the only known symbols are Intel’s.
MEASURMENTS is reproduced correctly: if it is a mis-spelling, it is Intel’s. The
driver’s tables of OIDs for IHV requests repeat each OID 0x0D01011B and 0xFF400200,
and give two symbolic names each. The OIDs 0xFF400144 and 0xFF400190 also appear
twice each in the tables, but with only one name each.

Writing Event 7023

Please take in the table and its interpretation: Netwtw06 event 7023 in the System
event log means just that the Netwtw06 driver received an IHV request—or, if you
like, an “Intel proprietary” request—that wasn’t one of a handful of types that
are presumably too frequent or unremarkable to be worth logging.

Take in this notion of worth. Intel’s programmers perhaps don’t think that an
event in the System log has any cost or needs to pull its weight, but neither can
they have believed that mere receipt of each of these very many different types
of IHV request has any sort of system-wide significance. Still, let’s be generous.
We might, just about, accept a driver writing something of no system-wide significance
to the System log, and even writing the same thing over and over to the System log,
if the event data at least recorded something distinctive about the cause so that
it has diagnostic value. Do we get at least this in exchange from Intel?

No, different types of IHV request are distinguished by different OIDs, which
are only 32-bit, yet Intel’s programmers somehow didn’t trouble to include the OID
with the event data. They could have easily enough. They just didn’t. The way that
Netwtw06 writes event 7023 to the System log is by calling the documented NDIS function
NdisWriteErrorLogEntry. This provides for passing one of 15 defined error
codes and some number (up to some limit) of arbitrary unsigned 32-bit values. How
many and what they mean is up to the caller. Netwtw06 passes exactly one extra value.
You can see it at the end of the EventData for every event 7023. It’s always the
same in all your tens of thousands of these events because it’s hard-coded into
the driver: 0x56524457 as an integer or WDRV as text. So, not only does Netwtw06
event 7023 in the System event log mean just that the Netwtw06 driver received pretty
much any IHV request, but it doesn't even have the (minimal) diagnostic value of
recording which type!

Again, we might be generous. Hard-working programmers missed that the function
they call provides an opportunity for increased diagnostic value. Not everyone sees
everything. But Intel’s programmers don’t have just the sin of omission, having
missed what the function might have done for them: they also have a sin of commission,
having stretched what the function is meant to do. Think again of those 15 defined
error codes. Though Microsoft doesn’t have the function enforce that only those
15 are permitted—and Microsoft’s documentation didn’t start specifying just these
15 until the Windows Driver Kit (WDK) for Windows 7, a decade ago—it is conspicuous
that all 15 are error codes. As events they are at the Error level, not Warning
and certainly not Information. Earlier documentation does suggest that the error
code for NdisWriteErrorLogEntry can be any “NDIS_STATUS_XXX
code describing the I/O error” but Intel’s programmers don’t even keep to that.
To write event 7023, they make up their own error codes: in this case 0x40001B6F,
being the event ID in combination with 0x40000000 to indicate the Information level.
They must have known all along that they were abusing this function to write to
the System event log things that were not as substantial as the function existed
to help with. And if they didn’t know it from stretching what the documentation
might mean by an error code or by an “NDIS_STATUS_XXX
code”, they surely ought to have known from the documentation’s Comments. A lot
of Microsoft’s documentation barely adds to the prototypes from the C-language headers,
which is very poor of Microsoft, but on the plus side is that where Microsoft does
provide comments and remarks of any substance, they mostly are worth heeding. Microsoft’s
documentation of NdisWriteErrorLogEntry from at least
as far back as the MSDN Library dated January 1999 is very plain:

Logging an I/O error at every possible opportunity is not particularly helpful
to users either, so a miniport should log only critical I/O errors that can help
a user or system administrator to debug a network failure for which the NIC is
responsible on a particular machine or a configuration resource conflict discovered
during driver initialization

There is, of course, no sense in which Netwtw06 event 7023 is any sort of critical
I/O error, even in one occurrence, let alone by the hundreds and thousands. If you’ve
been spammed by Intel’s driver, then I can’t see any reasonable disagreement that
Intel owes you an apology. The bar is so low in this industry, however, that many
would count it a reasonable excuse that Intel has been no worse than any other.
Still, from the customer support all the way back to the programming, Intel has
put on a poor show. Please, Intel, lift your game.

This page was created on 19th
August 2018 and was last modified on 28th
August 2018.