August 24, 2010 at 2:47 pm
I have a Job with only one step. That step invoke an ETL package (in the same SQL server).
The ETL gets and deletes some data from the database (again, same server), and then it has a Script Task, where I'm invoking a .exe file (a .NET 2005 console application).
I'm doing something like this:
mobjProcess = New Process
mobjProcess.StartInfo.Arguments = String.Format("{0} {1}", iBillingId.ToString(), tUsername)
mobjProcess.StartInfo.FileName = tAppPath
mobjProcess.StartInfo.CreateNoWindow = True
mobjProcess.StartInfo.WindowStyle = ProcessWindowStyle.Hidden
mobjProcess.StartInfo.UseShellExecute = False
mobjProcess.StartInfo.RedirectStandardOutput = True
mobjProcess.StartInfo.WorkingDirectory = Directory.GetParent(tAppPath).FullName
mobjProcess.StartInfo.LoadUserProfile = True
mobjProcess.StartInfo.UserName = tProcessUsername
mobjProcess.StartInfo.Password = objSecureString
mobjProcess.StartInfo.Domain = tProcessDomain
mobjProcess.Start()
tStdOut = mobjProcess.StandardOutput.ReadToEnd()
mobjProcess.WaitForExit()
Now, the problem I'm having is that when I execute that Job from my application, the .exe is not being executed. Everything works fine until the ETL script task step, where I'm invoking the .exe. The jobs keeps running (never ends) and the following message is logged on the Event Log:
Application popup: MiConsoleApp.exe - Application Error : The application failed to initialize properly (0xc0000142). Click on OK to terminate the application.
This was working just fine last month. There may be changes like hotfixes applied on the server. Also, the ETL was imported again (but the same working version as before). But all the code involved is the same as last month.
Any ideas on what could be causing this error?
I also tryed to copy the .exe to another server and it works fine, so the problem must be with the invokation in that particular server...security issues?
I'm using 2005 SQL Server and .NET.
Thanx!!
p.d. I also post this question in: http://www.sqlservercentral.com/Forums/Topic762679-148-3.aspx
August 25, 2010 at 9:35 am
Check the service account SQL Agent runs under has the relevant permissions (and compare it to the agent service account on the server that works)
August 26, 2010 at 6:52 am
How do I check the account on which SQL Agent runs under? Checking the "Log on as" property of the SQL Server Agent (MSSQLSERVER) service? Or you mean checking the owner user of the job I'm executing?
What permission should that user have?
Thanx!!
August 27, 2010 at 8:19 am
I assigned read and write permissions (just to be sure) to the user on witch SQL Server Agent service is running, to the folder where the console application is hosted, but I'm still getting the same behavior...
About the other environments you asked, in Dev and QA the service is running under NT AUTHORITY\NetworkService account while in production is using a domain account, but since there are others application running on that server, I can't change that...
And again, this was working just fine...the only thing changed was the ETL package, that had to be re-imported...
Thanx!
August 30, 2010 at 8:59 am
I was able to identify that the waiting is on the line:
[font="System"]tStdOut = mobjProcess.StandardOutput.ReadToEnd()[/font] (after executing the line mobjProcess.Start()).
The ReadToEnd() is executed and it get stucked there waiting for the answer...
August 31, 2010 at 9:42 am
I haven't being able to solve this yet 🙁
Any new ideas?
I also tried to reproduce this problem in different environments without any luck, it seems to work just fine. What server configuration could be causing this Process.StandardOutput.ReadToEnd() never to end?
I also replace the .exe I'm invoking for a simple console application with only one line that log something (so I'm sure that the problem is the invocation and not the console app) and I'm still getting the same behaviour (the ETL doesn't execute anything after the ReadToEnd() line)
Thanx again!
Regards
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply