For instance, say you get an error message:
How do you start debugging this? Well, you could start by trying to decipher the error message AppV has generated to a decimal value that you can then look at the first two digits to determine which 'part' of AppV generated the error and you can examine that specific log. Sounds kind of ridiculous when you spell it out.
Another thing you could do is you could enable all logs just to be sure, but then you have to sift through the logs to find the time stamp that corresponds closest to the event that generated the message. Sometimes it would be too far or close together or the debug logs generate so much information that your event viewer is just one big blob of 'the exact same time'.
 |
| One of these could be the cause of my issue. Going through them all is extremely cumbersome. |
Of course this isn't true that all these events are the same time, but it's all event viewer can display. If you view the XML of the event you can see there is more precise time stamps, but regardless, trying to compare each event with other logs is cumbersome and very difficult.
Is there a better way?
Yes! There is! And Microsoft has actually documented it here:
https://support.microsoft.com/en-us/kb/3037955
This is a powershell script that generates a ETL file on your desktop then converts it to a text format. The script is:
What does the output look like?
First thing to notice is that it's sorted chronologically, so if you can get a narrow time range to examine the error occurring it should be easier to spot. Second thing is all event logs are added, and events themselves are included as they are generated. So it should be easier to finding that specific component that causes the error.
If you are encountering AppV5 errors, this may be easier to help track down the error then trying to sift through the debug logs in event viewer.
No comments:
Post a Comment