Geoff Chappell - Software Analyst
Some versions of an Intel® Wireless WiFi Link Driver are seen to flood the System Event Log with hundreds and thousands of the same event in quick succession. The event tells of nothing with system-wide importance, just of the driver’s receipt of an Intel proprietary request. That Intel does this to its customers plausibly has no reason other than thoughtless abuse.
One evening last week 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. Since 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 unexpected 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 System and Application logs 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.
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.
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!
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’s 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.” Yes, having spammed your System log with events that say nothing more helpful than “Intel proprietary”, Intel “fixes” it by making all the existing events be even more unhelpful. Were Intel not one of the innovators of integrated circuits and still the market leader, you might reasonably wonder if they’re incompetent. What we have instead is worse: disregard.
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 all but a few of the many types of these IHV requests, Intel’s driver writes event 7023. 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 has reduced them or even eliminated 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!
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.
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 from Netwt06. 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.
By the way, the list above looks to be the first publication of Intel’s names for its vendor-specific OIDs. More than few suggest interesting functionality that might usefully be examined for exploitability. That they are published here is not to help with that but is just for critical analysis of the nuisance that Intel made of writing its event 7023 into the System log in such unjustifiable quantity.
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 diagnostic value for Intel in exchange for Intel’s spamming of our System log? 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. Microsoft doesn’t have the function enforce that only those 15 are permitted. Microsoft’s documentation didn’t start specifying just these 15 until the Windows Driver Kit (WDK) for Windows 7, a decade ago. But it is conspicuous that all 15 are error codes. As events every one of them is at the Error level, not Warning and certainly not Information, let alone Verbose. Although earlier documentation does suggest that the error code for NdisWriteErrorLogEntry can be any “NDIS_STATUS_XXX code describing the I/O error”, 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 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.