Comments on: Identifying the source of SQL Server login failures (18456 errors)

By: Anonymous

Anonymous — Tue, 27 Dec 2011 20:49:27 +0000

Searched for hours until coming across this entry — great article! Thank you for sharing!

By: Ajmer Dhariwal

Ajmer Dhariwal — Sat, 10 Dec 2011 17:56:59 +0000

This is the sql server agent account and it sounds like the account is locked out or disabled in some way.
From a dos prompt run “net user /domain” where is the full service account name (including domain name) and check the Account Active status and there is no password expiry for the account.
If that doesn’t help then send me the full fragment from the error log showing the login failure.

By: philip

philip — Fri, 09 Dec 2011 15:55:48 +0000

awsome article, it allowed me to find the process and the service but i’m still getting the lock outs. they are happening on the master database of our sql1/sql1 instance. the process is sqlagent90.exe and the service is SQL Server(sql1) i have verified that the account running the service is correct, i have verified that the service account is in the security folder of the master database.

our sql enviorment is in a MS cluster. this failure aduit is only happening on this node of the cluster. i’m lost as to what to do now.

By: Ashish Jain

Ashish Jain — Fri, 25 Nov 2011 08:49:29 +0000

Very important and nicely written post

By: Ajmer Dhariwal

Ajmer Dhariwal — Thu, 03 Nov 2011 17:43:34 +0000

The trace can be stopped or paused and saved so you can go back over it in your own time.
You can capture a similar trace of the processes and their PIDs by running an e.g. perfmon trace, or you can just open a DOS prompt (command window) on the host sending the invalid logins and typing “tasklist” and hitting return.
This will list all the processes running on that host along with their PIDs which you can then reconcile with the trace output. You can also redirect the tasklist output to file via “tasklist > c:\temp\tasks.txt”. If you use the following syntax with “tasklist >> c:\temp\tasks.txt” you can append the output to a text file, which means you can repeatedly run the tasklist command on a scheduled basis, for example, and this will allow you to capture all the processes and their PIDs over the time interval you schedule it for. With the trace and tasklist data saved you can go over it at your lesiure to reconcile the logins with their PIDs.

By: Diane

Diane — Wed, 02 Nov 2011 16:06:17 +0000

Thank you for the information. This has been somewhat helpful, at least more so than other articles I have found. I am having one issue though. The trace is capturing the information but it goes by so fast I can’t catch the PID on task manager when it’s caught in profiler. Is there anything I can do to see this? I don’t know what process is running to cause failure and that is what I am trying to catch. Please advise.

Much thanks!!!

By: Crystal Reports Generating SQL Server Error 18456 Severity 8 Error Logs « Justin Cooney – Senior Programmer / Analyst

Mon, 03 Oct 2011 17:42:39 +0000

[...] Identifying the source of SQL Server login failures (18456 errors) Share this:TwitterLike this:LikeBe the first to like this post. [...]

By: Deb

Deb — Fri, 12 Aug 2011 20:34:23 +0000

I was getting those mysterious Error: 18456, Severity: 14, State: 38. messages every three minutes on one of my test servers, and this helped me pinpoint the db name and the client process that was trying to access it. I had suspected it was a database we recently migrated to a production server, and the application support person was arguing it couldn’t be, he had changed all the pointers. This solved the argument quickly and finally.

Thanks very much for posting this info.

By: Ozie

Ozie — Tue, 19 Jul 2011 16:02:03 +0000

Thank you for pointing me in the right direction

By: Myra Rosa

Myra Rosa — Fri, 08 Jul 2011 22:44:00 +0000

Thank you! This is very helpful. You have some excellent SQL Karma coming your way