procedure=xp_cmdshell text=An error occurred during the execution of xp_cmdshell

we are occasionally getting

Server message number=15121 severity=16 state=200 line=1 server=MARILYN procedure=xp_cmdshell text=An error occurred during the execution of xp_cmdshell. A call to 'LogonUserW' failed with error code: '1909'.

and this seems to fix it, albeit temporarily!?

Exec sp_xp_cmdshell_proxy_account NULL
Exec sp_xp_cmdshell_proxy_account 'domain\account', 'therightpassword'

any ideas why this may be happening?
this is fully patched w2k3 server R2 SP2 x64; sql2005 SP3 - Microsoft SQL Server 2005 9.00.4053.00 (X64)
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Could it be the account is getting locked out due to some policy about maximum concurrent (NT) sessions or something? Can you have a look in the Windows Event Log (Security) for any errors associated with the account?
gddl630Author Commented:
not sure I've never had to do anything to limit maximum concurrent (NT) sessions - how do I check that?
as for the event log I can see entries like this one although no specific account is being mentioned
Event Type:	Failure Audit
Event Source:	Security
Event Category:	Logon/Logoff 
Event ID:	529
Date:		10/04/2010
Time:		05:39:23
Computer:	MARILYN
Logon Failure:
 	Reason:		Unknown user name or bad password
 	User Name:	
 	Logon Type:	3
 	Logon Process:	Kerberos
 	Authentication Package:	Kerberos
 	Workstation Name:	-
 	Caller User Name:	-
 	Caller Domain:	-
 	Caller Logon ID:	-
 	Caller Process ID:	-
 	Transited Services:	-
 	Source Network Address:	-
 	Source Port:	-

For more information, see Help and Support Center at

Open in new window

You could look at the Resultant-Set-of-Policy for the user to see if there's anything weird going on with policies. Here's a Microsoft KB on how to do this:
gddl630Author Commented:

I couldn't see anything unusual, but to point out again executing this fixes it:
Exec sp_xp_cmdshell_proxy_account NULL
Exec sp_xp_cmdshell_proxy_account 'domain\account', 'therightpassword'
gddl630Author Commented:
used ALTools.exe to discover the server and process locking the account. it turned out the account was used on another machine and the password was mistyped

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server 2005

From novice to tech pro — start learning today.