Perhaps we are less apart than it seems.

IMO:
the logging interface you call should be totally under your control - perhaps modelled after an interface of MS, but that is a dev decision.

Implementing the logging behavior MIGHT be done reusing EWT. Doubtful if EWT is ***always*** better - a simple counter incremented in-thread probably is faster than delegating such a task to another thread. Even saving a HighPerformanceCounter result in a C-array and incrementing the pointer to next slot might still be faster and probably the time needed is not less constant then that of a delegate to another thread.

Having a base behaviour totally under your control and using another behaviour depending on some external governor (config XML or program internal) would also be in my design.

Logging does NOT automatically imply for me always hitting the disc with some information piped in more or less structured way - it implies a call to an interface (perhaps embedded in preprocessor directives where available or hooked to minimally invasive calls where the first is not available, but function overloading is or a call to a standard method of a class loaded via factory or or ...) ;-)
which enables the dev to follow program execution in a manner fitting to the problem. And yes, the fallback/default option should be a self-wriiten pipe to disc which will never fail ;-)



>Logging should be mostly dead. It's slow, blocks the application, and requires external resources. ETW is built into Windows, happens on a different thread, is VERY fast, and allows you to capture lots of different things.
>
>
>>disagree ;-)
>>logging before and after each Getdescription/Add linepair might establish if those errors occur
>>somewhat randomly distributed across a dataload-weighted mean
>>or
>>clump on few/one particular table.
>>In second case, I'd start searching on the server, in first I's look at cable/network issues first.
>>
>>