Last time I talked about the four switches that control which types of messages get logged:

• logEntireMessage: whether to log message bodies or just the headers of each message
• logMalformedMessages: whether to log the message when there is a decoding error, such as in a message encoder or serializer
• logMessagesAtServiceLevel: whether to log messages when handled as part of a dispatch operation
• logMessagesAtTransportLevel: whether to log messages when handled as part of the network transport (or quite often the message encoder)

Whether to log the entire message is more of a universal option so I'll focus on explaining how the other three options are used internally.

There are actually a very small number of circumstances for which messages are traced. However, some of those code paths trigger a wide variety of dependent operations. If you're trying to work out an issue by observing where message logging is occurring from, you will sometimes get a very specific understanding of what is happening and sometimes get absolutely no information at all. As a positive though, there's not much middle ground so it's relatively easy to recognize which of the two situations you're in.

A malformed message is one where there isn't enough information to figure out what the message means and processing can't continue.

• When using HTTP, if the content type header is missing or is not one of the supported content types
• When using the binary encoder, if the message is part of an encoded series of messages and that reader session has become corrupted
• When allocating the message, if reading the initial portion of XML fails or if for a wide variety of reasons that information is invalid, such as the wrong SOAP envelope version
• When dispatching the message, if the input parameters can't be deserialized from the message contents for a wide variety of reasons

A service level message is one that is being processed by an application or dispatch component rather than a message delivery component.

• When additional messages need to be passed in our out of the system as part of the exchange of security tokens
• When receiving a message, once the message is the next message that is about to be dispatched from the channel to the service
• When sending a response from a service operation, once the return parameters have been serialized back into a message
• In a client application, the corresponding points in time for sending and receiving messages, on the receive side just before the inbound message inspectors are invoked and on the send side just after the outbound message inspectors are invoked

Next time, I'll wrap up the discussion of the different trace options by going through the different locations where logging happens for message delivery components.