$log.message | Select-String -SimpleMatch 'fail' | ConvertFrom-String | select p4, p5 PS C:\> $log.message | Select-String -SimpleMatch 'fail' | ConvertFrom-StringĪll I need to is select P4 and P5. The default name is p1 – p27, but the doesn't matter because I see that I want P4 (my local IP address and port) and P5 (the remote IP address and port).Īs shown here, I also already know the connections are failing with a timeout because that is what I found earlier: The output that comes back is a collection of 27 fields. $log.message | Select-String -SimpleMatch 'fail' | ConvertFrom-String
#Microsoft packet capture tool windows
But with Windows PowerShell 5.0, I can parse this in no time at all because I have the ConvertFrom-String cmdlet. I would have been falling back to write complicated REGEX patterns, and that would have taken some experimenting to get right. But what is it really? Well, I need to dive into the message field and see what is really connecting to what, and how many times the connections are failing.īefore Windows PowerShell 5.0, this could have caused me some concern. That sounds like it could be bad, and it would certainly explain the slowness of my computer. PS C:\> $log.message | Select-String -SimpleMatch 'fail' | measureĨ1 times in a 2 minute time frame. Hmmm…how often is this happening? Well, I pipe the output to Measure-Object ( measure is an alias): It appears that there are different connection attempts that are failing with a timeout. The specified I/O operation on %hs was not completed before the time-out period expired. Remote=127.0.0.1:443) connect attempt failed with status = $log.message | Select-String -SimpleMatch 'fail' I pipe the output to the Select-String cmdlet and do a simple match on the word fail. I wrote about it in PowerShell Looping: The Automatic Foreach.Īll I need to do is access the message property from my collection of 11,000 events stored in the $log variable. This is a huge time saving feature, and one of my favorites. Note Luckily beginning with Windows PowerShell 3.0, PowerShell has what I call an automatic foreach-that is, it will automatically expand a collection of objects and allow me to examine a single property. To parse this message field, one can use Select-String. But the Message field shows what is going on. The ID can be a great way to correlate events. In the trace log, the basic fields of the log are TimeCreated, ID, LevelDisplayName, and Message. Sure is a good thing that Windows PowerShell is great at parsing log files! Look at the Message field It turns out that I have over 11,000 entries:
I also want to see how many entries I have. This might be enough to document my problem. I can see that it covers 2 minutes and 15 seconds. New-TimeSpan -end ($log | select -Last 1).timecreated -start ($log | select -first 1).Timecreated Now I want to see what timespan is documented by this trace, so I use New-Timespan: The following image shows these commands and any associated output. $log = Get-WinEvent -Path $session.LocalFilePath –Oldest I have to specify the –Oldest switch to avoid errors due to the way the log contents are read. I read the contents of the network trace log. Now, I reproduce my problem, and then I stop my net event session: $session = New-NetEventSession -Name "Session1"Īdd-NetEventProvider -Name "Microsoft-Windows-TCPIP" -SessionName "Session1 Now I have removed my error, so I can create the session anew, add NetEventProvider, and start the net event session: The error message and the solution are shown in the following image: To clear up the matter, I need to use the Remove-NetEventSession cmdlet. That is a somewhat ambiguous error to say the least. Obviously an object already exists or it would not be an object. A big red error message appears stating that an object already exists.
How can that be? Well, obviously Windows PowerShell remembers what you did yesterday when you created the session in the first place. If you go to create a new net event session, and you call it session1 (like I did yesterday), you will get an error message today. You may be surprised if you have rebooted your computer, logged off and back on, and opened and closed Windows PowerShell. For more information about doing basic analytics, see Use PowerShell to Parse Network Log. Note For more information about setting up and making a packet trace, see Packet Sniffing with PowerShell: Getting Started. Yesterday I begin analyzing a packet trace log. Microsoft Scripting Guy, Ed Wilson, is here. Summary : Microsoft Scripting Guy Ed Wilson talks about looking at the message field in a packet log with Windows PowerShell.
0 kommentar(er)
