Event ID 538 Explained
Created 2003-06-17 by Wajih-ur-Rehman.
Updated 2003-06-25 by Wajih-ur-Rehman.
In this paper, I will try to explain the Event ID 538 and some of the
problems associated with it and what can be done to remove these problems.
The following events are involved in the discussion in this paper:
What is Event ID 538?
If you audit for logon events, every time a user logs on or logs off at a
computer, an event is generated in the security log of the computer where the
logon attempt occurs
. As we are specifically interested in Event ID 538 in
this paper so I will not digress away by explaining other Event IDs. Event ID
538 is generated when a user log offs. Following are the parameters that are
associated with this Event ID 538
- User Logoff
- User Name
- Logon ID
- Logon Type
When is Event ID 538 Generated?
Event ID 538 can be generated under one of the following conditions
ID 538 Possibilities
|Net use disconnection
Problem with Event ID 538
1. According to the above mentioned table, when a user log offs
interactively, an Event ID 538 should be generated with a Logon Type = 2. But in
most of the situations this does not happen. When a user log offs interactively,
still an Event ID 538 is generated with Logon Type = 3. Due to this problem, a
Network Administrator is not able to distinguish between an actual Interactive
Logoff and the rest of the types mentioned above in the table. Microsoft has
confirmed that this problem occurs in the following products
- Microsoft Windows 2000 Server SP1
- Microsoft Windows 2000 Server SP2
- Microsoft Windows 2000 Server SP3
- Microsoft Windows 2000 Advanced Server SP1
- Microsoft Windows 2000 Advanced Server SP2
- Microsoft Windows 2000 Advanced Server SP3
- Microsoft Windows 2000 Professional SP1
- Microsoft Windows 2000 Professional SP2
- Microsoft Windows 2000 Professional SP3
2. Sometimes Event ID 538 is logged many times without corresponding Logon
Events. This problem is also very commonly seen in the security newsgroup of
Detailed Explanation of Problems
Eric Fitzgerald of Microsoft has explained the cause of the problem # 1
mentioned above. Whenever a user logs on, a logon session is created that is
uniquely identified with a number, called Logon ID which is logged as a
parameter with the event in the Windows Security Log. Similarly, when a user log
offs, then under normal conditions, this logon session is destroyed and an entry
is made into the Windows Security Log with a Logon ID similar to the one with
which the session was created. In other words, we can correlate these log on and
log off events based on the Logon IDs and irrespective of the Log on type that
is mentioned above.
The logon session that has been described above is associated with a token.
When a system component or any other application requests access to this token,
the system increases the reference count to this token. In other words, if the
reference count to this token is not zero, the system will assume that it is
currently being used by some application or some system component. This token
cannot be destroyed until the reference count to it becomes zero and the logon
session with which this token is associated with, cannot be destroyed until the
token is destroyed. In other words, a logon session can only be destroyed if the
reference count to the token that is associated with it is zero.
Theoretically, an application closes the handle to the token when its
finished with it and this reduces the reference count to it. When the reference
count reaches zero, the token is destroyed which in turn destroys the logon
session causing an Event 538 to be generated in the Security Log. Practically
this rarely happens! The main reason for this behavior are some applications
that exhibit something which is called a "Token Leak". A "Token Leak" occurs
when an application requests access to the token described above and then looses
the handle to it. Now when the application is finished, the reference count to
the token is not decremented and the system assumes that still the token is in
use by some application which further means that the reference count would never
reach zero. As explained above, if the reference count to a token is not zero,
the logon session would not be destroyed which means that a log off session
would not be generated.
Microsoft has identified a number of token leak problems within the OS and
have removed them in SP4. Since the current token architecture has no back
reference capabilities so Microsoft currently cannot guarantee the complete
removal of this problem because of the third party poorly designed applications
that are mainly responsible for the Token Leaks.
The above described problem would be more severe with a machine that has lot
of applications on it and would be less severe on a freshly installed system. We
are currently in the process of testing this problem on a freshly installed OS.
I will update this paper as soon as I get some results.
In response to Problem 1, Eric Fitzgerald of Microsoft says, "The issue is a
class of bug called a "Token Leak". It is fixed for many cases (but not all) in
Service Pack 4. It's not possible to fix in all cases because applications can
cause this problem.". As explained above that even if you install SP4, some
of the Token Leak problems that are associated with the OS will be removed but
as far as the third party applications are concerned you cant do much about it.
I thank Rainer Gerhards of Adiscon for reviewing this paper.
Many thanks to Eric Fitzgerald of Microsoft for
providing a great description of the actual cause of the problem associated with
Event ID 538. I would also like to thank Gord Taylor
for providing his feed back on the paper.
The information within
this paper may change without notice. Use of this information constitutes
acceptance for use in an AS IS condition. There are NO warranties with regard to
this information. In no event shall the authors be liable for any damages
whatsoever arising out of or in connection with the use or spread of this
information. Any use of this information is at the user's own risk.
Have your logs consolidated but it's too complicated to review them or create reports? Take a look at
With MonitorWare Console you can not only review your stored log data. You can automatically create reports for Windows events and PIX firewall logs and let them be sent via e-mail and much more.
Take a Quick Tour to MonitorWare Console to know more about its exciting features or directly download the free and full-featured 30 day trial version.
Would you like to discuss this object? Have a look at our
Windows event forum or post a question there!
Analysis, monitoring, near-real-time alerting of the Windows event log can be done with
by MonitorWare Agent.
All information in this section is to the best of our knowledge but without warrenty of
any kind. This is free information - use it at your sole risk.
[Back to the Security Reference]