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:

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_STATUS
OID_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_RESET
OID_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.