Microsoft Support will analyze the data and will report back with any conclusions or next steps.īut what if you want to review the captured data as well? S imply opening the CAB file you can see there are lots of TXT files with human readable S ystem I nformation, R egistry K eys, and Event L ogs. It also captures some related diagnostic information and compresses that information into a CAB file.Īt this point, S upport will ask for either the ETL file, or both the ETL and CAB file depending on the information they are looking for, to be uploaded for analysis. Notice that NETSH trace generated an ETL file and saved i t in the folder specified when starting the trace. Once reproduced, stop the trace to generate the ETL file. With the trace now running, the issue now needs to be reproduced. Use the switches they provide you if asked.) (Note: If working with Microsoft Support, the Support Engineer may give you a slightly modified version of this command to enable certain trace options specific to your reported issue.
Windows Performance Analyzer is a great tool to view ETL files that contain system performance data, but not the best thing for network traces.
No improvements to Netmon have been made since 2010 but is still available for download from Microsoft.
įor the last few years, Microsoft has used a variety of tools to decode and view the data in ETL files, mainly NetMon, Windows Performance Analyzer and Microsoft Message Analyzer. When using NETSH to capture a network trace, it generates a specialized file with an ETL file extension. You can read all about what NETSH can be used for here. NETSH is a great tool built into the Windows OS and can be used to configure many parts of the networking stack within your Windows OS. If your issue requires network traces to be captured, Microsoft Support will often ask you to capture the m running a built-in utility called NETSH. Maybe you or your staff also has the technical expertise to review the data and make some preliminary observations while waiting for Microsoft Support to complete the investigation. Maybe y ou want to review that data yourself. Sean Greenbaum here with a tale from the field.Īs many of you have probably experienced, when working with Microsoft Premier support, you’ll often be asked to capture some data and upload it to Microsoft for analysis. Sox is a audio analysis tool that is run from the command line.Īfter looking at some examples online of different tools, I pieced this together from other people's examples, with a few modifications.Hello.
It's installed on centos boxes using yum install wireshark-gnome. Tshark is a command line version of wireshark. I've been wanting to do a packet capture during the test and convert it back to audio afterwards, then do a wav comparison on the expected audio vs. But how do I know I get the right end point? In the past, I'd have the phone number I dial, record voice mail and send me an email, and the sipcli client would send over text to speech audio.īut I dont always have the luxury of being able to configure the phone number to voice mail. I currently drive automated SIP calls via SIPCLI and ruby for a variety of tests at work. After following a lot of different tutorials (some of which worked some of which didn't), I came up with a shell script using a couple tools to scrape a packet capture file, pull out the rdp packets, and then convert them back into audio.įor me this will be useful in automated testing.