Quantcast
Channel: Windows Performance Toolkit (WPT) v5 forum
Viewing all articles
Browse latest Browse all 275

ETW PID accuracy when coming from a kernel provider such as NDIS

$
0
0

I'm not sure that this is the absolutely correct forum to post this but hoping it's close.

I've been playing around with Event Tracing for Windows events, the networking events, NDIS-PacketCapture and TCPIP in particular. Each ETW message has the PID field and I'm trying to figure out the logic behind the assignment. It seems that the vast majority of TCPIP events have the correct PID in the PID field and the majority of NDIS-Packet capture as well. However, there are many instances, perhaps 30%, where the PIDs are obviously incorrect. Some of these incorrect PID information are false-positives and some false-negatives. For example, it will miss that certain packets coming from Chrome and it'll just assign PID 0 to that case (false negative). Sometimes I get PID of the application I'm running to catch these events in the the PID field (false positive). As far as I can analyze, there is no way to determine whether an ETW event contains correct or incorrect information by looking at any other header/property info.

Another interesting thing to note is that some TCPIP events contain a "PID" property that sometimes agrees with the PID in the header. This "PID" property seems to be more accurate than the header PID but it still exhibits false-positives and false-negatives.

Am I seeing a bug? Am I not understanding the purpose of the PID field in ETW messages? Are these providers just choosing to put in garbage whenever they feel like it?

I'm using the Win32/64 trace functions in C++ such as StartTrace, EnableTraceEx2, OpenTrace, and the ProcessEventRecordProperties(PEVENT_RECORD pEvent) callback, etc.

Any help is greatly appreciated.


Viewing all articles
Browse latest Browse all 275

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>