Diagnostic Traces
Traces are the publishing of specific messages that are generated during application execution. When using tracing, you must have a mechanism for collecting and recording the messages that are sent. Trace messages are received by listeners. The purpose of a listener is to collect, store, and route tracing messages. Listeners direct the tracing output to an appropriate target, such as a log, window, or text file.
One such listener, the DefaultTraceListener, is automatically created and initialized when tracing is enabled. If you want trace output to be directed to any additional sources, you must create and initialize additional trace listeners. The listeners you create should reflect your individual needs. For example, you might want a text record of all trace output. In this case, you would create a listener that wrote all output to a new text file when enabled. On the other hand, you might only want to view output during application execution. In that case, you might create a listener that directed all output to a console window. The EventLogTraceListener can direct trace output to an event log, and the TextWriterTraceListener can write trace output to a stream.
Enabling Tracing
To enable traces during transaction processing, you should edit your application’s configuration file. The following is an example.
<configuration>
<system.diagnostics>
<sources>
<source name="System.Transactions" switchValue="Warning">
<listeners>
<add name="tx"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "tx.log" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
System.Transactions traces are written to the source named "System.Transactions". You can use add
to specify the name and type of the trace listener you want to use. In our example configuration, we named the Listener "tx" and added the standard .NET Framework trace listener (XmlWriterTraceListener) as the type we want to use. Use initializeData
to set the name of the log file for that listener. In addition, you can substitute a fully qualified path for a simple file name.
Each trace message type is assigned a level to indicate its degree of importance. If the app-domain’s trace level is equal or lower than the level of an event type, then that message is generated. The tracing level is controlled by the switchValue
setting in the configuration file. The levels that are associated with diagnostic trace messages are defined in the following table.
Trace Level | Description |
---|---|
Critical |
Serious failures, such as the following, have occurred:
|
Error |
An error (for example, invalid configuration or network behavior) has occurred that can result in a loss of user functionality. |
Warning |
A condition exists that can subsequently result in an error or critical failure (for example, allocation failing or approaching a limit). Normal processing of errors from user code (for example, transaction aborted, timeouts, authentication failed) can also generate a warning. |
Information |
Messages helpful for monitoring and diagnosing system status, measuring performance, or profiling are generated. These can include transaction and enlistment lifetime events, such as a transaction being created or committed, the crossing of a significant boundary, or the allocation of significant resources. A developer can then utilize such information for capacity planning and performance management. |
Trace Codes
The following table lists the trace codes that are generated by the System.Transactions infrastructure. Included in the table are the trace code identifier, the EventType enumeration level for the trace, and the extra data contained in the TraceRecord for the trace. In addition, the corresponding trace level of the trace is also stored in the TraceRecord.
TraceCode | EventType | Extra data in TraceRecord |
---|---|---|
TransactionCreated |
Info |
TransactionTraceId |
TransactionPromoted |
Info |
Local TransactionTraceId, Distributed TransactionTraceId |
EnlistmentCreated |
Info |
TransactionTraceId, EnlistmentTraceId, EnlistmentType (durable/volatile), EnlistmentOptions |
EnlistmentCallbackNegative |
Warning |
TransactionTraceId, EnlistmentTraceId, Callback (forcerollback/aborted/indoubt) |
TransactionRollbackCalled |
Warning |
TransactionTraceId |
TransactionAborted |
Warning |
TransactionTraceId |
TransactionInDoubt |
Warning |
TransactionTraceId |
TransactionScopeCreated |
Info |
TransactionScopeResult, which can be the following:
new current TransactionTraceId |
TransactionScopeDisposed |
Info |
TransactionTraceId of the scope’s “expected” current transaction. |
TransactionScopeIncomplete |
Warning |
TransactionTraceId of the scope’s “expected” current transaction. |
TransactionScopeNestedIncorrectly |
Warning |
TransactionTraceId of the scope’s “expected” current transaction. |
TransactionScopeCurrentTransactionChanged |
Warning |
Old current TransactionTraceId, other TransactionTraceId |
TransactionScopeTimeout |
Warning |
TransactionTraceId of the scope’s “expected” current transaction. |
DependentCloneCreated |
Info |
TransactionTraceId, type of dependent transaction created (RollbackIfNotComplete/BlockCommitUntilComplete) |
DependentCloneComplete |
Info |
TransactionTraceId |
RecoveryComplete |
Info |
Resource Manager GUID (from base) |
Reenlist |
Info |
Resource Manager GUID (from base) |
TransactionSerialized |
Info |
TransactionTraceId. |
TransactionException |
Error |
Exception message |
InvalidOperationException |
Error |
Exception message |
InternalError |
Critical |
Exception message |
TransferEvent |
When a transaction is deserialized, or promoted from a System.Transactions transaction to a distributed one, the current ActivityID from the ExecutionContext and the distributed transaction ID are written. When the DTC calls back into managed code, the distributed transaction ID is set as the ActivityID in the ExecutionContext for the duration of the callback. |
|
ConfiguredDefaultTimeoutAdjusted |
Warning |
No extra data |
TransactionTimeout |
Warning |
The TransactionTraceId of the transaction being timed out. |
The XML schema for each of the preceding extra data items has the following format.
TransactionTraceIdentifier
<TransactionTraceIdentifier>
<TransactionIdentifier >
string representation of transaction id
</TransactionIdentifier>
< CloneIdentifier >
the clone id number
</CloneIdentifier>
</TransactionTraceIdentifier>
EnlistmentTraceIdentifier
<EnlistmentTraceIdentifier>
<ResourceManagerId>
string form of guid
</ResourceManagerId>
<TransactionTraceIdentifier>
<TransactionIdentifier >
string representation of transaction id
</TransactionIdentifier>
<CloneIdentifier >
the clone id number
</CloneIdentifier>
<TransactionTraceIdentifier>
<EnlistmentIdentifier>
the enlistment id number
</EnlistmentIdentifier>
</EnlistmentTraceIdentifier>
Resource Manager Identifier
<ResourceManagerId>
string form of guid
</ResourceManagerId>
Security Issues For Tracing
When you as an administrator turn on tracing, sensitive information might be written to a trace log that is publicly viewable by default. To mitigate any possible security threat, you should consider storing the trace log in a secure location controlled by share and file system access permissions.
Send comments about this topic to Microsoft.
Copyright © 2007 by Microsoft Corporation. All rights reserved.