Okay. Somehow I've stepped into another hole. Maybe this helps someone else avoid it and might shed light on it here -
So the main question for me while trying to troubleshoot a POSSIBLE problem - which I always first blame ME - for is :
What triggers Windows to read STRING DESCRIPTORS?
And I know - its buried in Windows so its behind the curtains. So here's the WHY part - I am supposed to do some teaching about some USB applications we use. And I figured Wireshark would be sufficient enough capture capability to do what we need. I don't THINK I need a ON THE WIRE SNIFFER versus a DRIVER LEVEL capture. So I have an STM32L476VG running the USB DEVICE - CDC/VCP firmware example from back about Cube 1.6 days. This has (apparently) always worked for us. The example code has strings for MANUFACTURER, PRODUCT and SERIAL NUMBER and the device descriptor has the indexes as 1, 2 and 3. THESE SHOW UP IN WINDOWS DEVICE MANAGER. Com ports are assigned as expected by VID/PID/SERIAL NUMBER. And the PRODUCT ID STRING shows up in DETAILS- Bus reported device description. So I fire up Wireshark (Using USBPcap as capture engine - it come with Wireshark 4.0.3) and plug my phone in to see which PCAP channel to use and I see enumeration complete with String descriptor requests and responses. PERFECT!
Unplug phone and restart capture to clear screen and input buffer.And plug in the ST micro.
I see NO REQUESTS for STRING DESCRIPTORS. ??? I DO see the DEVICE, CONFIGURATION, INTERFACE, ENDPOINT and COMMUNICATION requests and responses along with a couple of SET commands and responses. So I don't think I should see the Com port working as expected nor should I see the BUS REPORTED DEVICE DESCRIPTOR VALUE in device manager since something looks fishy.
However -
The data is ALL PRESENT in THE PC with Device manager. ????
Com port works fine.
REBOOT - CHANGE PRODUCT STRING COMPILE - LAUNCH WIRESHARK - PLUG IN - NO STRING DESCRIPTOR REQUESTS - and the newly changed product ID shows up in Bus reported device description in Device manager.
SO WINDOWS sees it and WIRESHARK DOES NOT.
Yes I have put this on Wireshark and Github with the Capture developer .
Anyone have anything similar or able to embarrass me in some way with an obvious reason ? (Other than a bug somewhere other than my code?)
No... I AM NOT filtering the string descriptors out with a Wireshark Filter. SO Something other than that one.
