Logging is enabled and disabled at the thread or process level,
depending on the flags passed to this function, and is not associated
with a specific client session. When logging is enabled, the information
is appended to the specified file. If the file does not exist, it
will be created. To limit the size of the file, enable and disable
logging only around those sections of code that you wish to debug.
If you do not provide a full path to the file, it will be relative
to the current working directory for the process. This can produce
unexpected results in multithreaded applications because the current
directory is global to the entire process and can be changed by
any thread at any time.
If logging is not enabled, there is no negative impact on performance
or throughput. Once enabled, application performance can degrade,
especially in those situations in which there is a large amount of
data being exchanged. The log file can contain detailed information
about connection attempts and authentication requests, potentially
exposing user credentials, authorization tokens and API keys. If you
enable logging in a production release of your application, this
information can also potentially reveal file structures, API endpoints
and data specific to your application. Exercise caution when preserving
or sharing the contents of the file.
The TRACE_HEXDUMP option can generate very large files because
it includes all of the data exchanged between your application and the
remote host. The TRACE_TRUNCATE option is only evaluated when logging is
first enabled for a thread or process. If logging is already active,
specifying this option will have no effect.
The log file has the following format:
APPNAME 105020 0000 INF: WSAAsyncSelect(46, 0xcc4, 0x7e9,0x27) returned 0
APPNAME 105020 0015 WRN: connect(46, 192.0.0.1:1234, 16) returned -1 [10035]
APPNAME 111535 0000 ERR: accept(46, NULL, 0x0) returned -1 [10038]
The first column contains the name of the process. The second column
is the local time in hours, minutes and seconds. The third column is the
elapsed time in milliseconds since the previous function call. The fourth
column identifies if the logged event contains information, a warning, or
an error. What follows is the name of the network function being called,
the arguments passed to the function and the function's return value. If
a warning or error is reported, the error code is appended to the record
and the value is enclosed in brackets.
If function parameters are passed as integer values, they are recorded
in decimal. If the parameter or return value is a memory address, it is
recorded as a hexadecimal value preceded with "0x".
Those functions which expect network addresses are displayed in one of
two formats:
aa.bb.cc.dd:nnnn
[xxxx:xxxx:xxxxx:xxxx::xxxx]:nnnn
With an IPv4 address, the first four numbers separated by periods
represent the IP address, and the number following the colon represents
the port number in host byte order. If an IPv6 address is used instead
of IPv4, the address will be a series of hexadecimal digits separated
by colons and enclosed in brackets. In the second line of the above
example, a connection is being made to a system with the IPv4 address
192.0.0.1 on port 1234.