A Single Line of Client Trace
Just the other day I was writing a section of a new uber-Client-Tracing-Technote, when it was pointed out to me by one of the lead developers that I should explain what a simple, single line of Client Trace means.
I wrote the section, and added it to the technote, but here it is outside of that, because it’s important. Here is a single line of client trace:
16/12/2011 14:19:08.881[3368][L]: AddinStartup::MainStartup
16/12/2011 14:19:08.881
The date and time of the trace. The date and time are logged in UTC. So if the end-user workstation is in a different timezone, the trace files will always be constant.
[3368]
The thread ID of the thread logging the trace (ie performing the action). The thread ID is recorded in the trace in decimal, and is in square brackets. It is worth remembering that it is in decimal, as when reviewing a user dump of Outlook with WinDBG for example, the thread IDs are in hexadecimal.
At the beginning of the trace you will observe the thread termed the ‘main thread’. As the Add-in starts up, other threads will be spawned to do specific tasks and will add trace to the trace file as necessary.
[L]
The next part is the level of verbositity.
AddinStartup::MainStartup
The ‘line’ of trace, function name, descriptive text, etc.
Some trace also logs the result-code being returned from a function eg:
16/12/2011 14:19:08.560[3368][L]: CDesktop::FinalConstruct: 0×0
15/12/2011 11:21:26.855[3284][H]: A COM error occurred: 0×80040205
0×0 means a successful result. Error results tend to be like : 0x8nnnnnnn, or 0xCnnnnnnn. If a function does return an error you may see it logged in several places in the client trace as a low level function logs it, and the same error is then logged by the next level function, and so on, until at some level the error condition is hopefully handled.
It is also worth noting that the presence of an ‘error’ result like this does not necessarily mean that an error occurred. For example the above ‘error’ can be logged when a retrieval/view of an archived item takes place with Vault Cache enabled. The Outlook Add-in knows that this condition exists because the item is not in the content cache, and proceeds to handle that condition (by downloading the item, and inserting it into the content cache for future retrievals)
Photo Credit, schoschie
