I had the same problem with Matrox Imaging Library filter driver and Wireshark not able to capture packets. Turns out netsh trace is able to capture the data. It is unfortunately slow and uses a lot of disk space and takes forever to save, but it is able to see the traffic. - Correction: by using report=disabled it is now fast. netsh trace with defaults or with report=no will create a cab file with system info, for some reason this takes forever the longer you trace for if you have high data rates, but with report=disabled the trace writes out within 10 seconds instead of taking minutes or longer.
You need to convert the etl file to a pcapng file then Wireshark version 3.6+ can read it, Microsoft created etl2pcapng to convert the file: https://github.com/microsoft/etl2pcapng.
The directions are outlined here https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/converting-etl-files-to-pcap-files/1133297:
netsh trace start capture=yes report=disabled maxsize=1024 filemode=circular tracefile=c:\temp\file.etl
netsh trace stop
etl2pcapng.exe file.etl newfile.pcapng
Then you can open the pcapng file in Wireshark and it displays like normal.
Beware: etl2pcapng will input a comment showing the PID and Thread of the "current process" but it was mostly useless data for me. The person who wrote that feature made a blog post about it here https://blog.didierstevens.com/2020/01/28/etl2pcapng-support-for-process-ids and includes this response from Microsoft,
The output pcapng file will have a comment on each packet indicating the PID of the current process when the packet was logged. WARNING: this is frequently not the same as the actual PID of the process which caused the packet to be sent or to which the packet was delivered, since the packet capture provider often runs in a DPC (which runs in an arbitrary process). The user should keep this in mind when using the PID information.
For me it was showing seemingly random processes, turns out this data is taken in by the network stack using a Deferred Procedure Call, and DPCs actually re-use the execution context of the thread that was interrupted to do the packet capture processing! So you can have notepad.exe be interrupted and its own execution context is then used by the "packet capture provider", this causes the notepad.exe PID to be listed in the resulting .pcapng file taken from the netsh trace data despite it otherwise being wholly unrelated (kinda cool to see exactly what was interrupted and when to process that packet though).
