Post reply

Scheduled Job fails with Process Exit Code -1073741819

  • May 15, 2007 at 4:14 am

    #178517

    Dear all,

    I'm at my wits end with this problem, so any help/advice is greatly appreciated.

    Random steps within scheduled jobs are intermittently failing with the following message: "Executed as user XXX. The step did not generate any output. Process Exit Code -1073741819. The step failed."

    I've checked/verified that all permissions are in place to run the steps. There is also nothing in the application or system event logs.

    Best regards

  • May 16, 2007 at 8:45 am

    #706827

    Hi many times a detailed message is not dispayed when u  see the step details in the job history section.A better way to view the errors is to create a Output file in the Steps-Advanced section of the jobs properties.Then force run the job and see the results in the  output file.This might help to get u detailed desc of the problem.

  • May 16, 2007 at 9:09 am

    #706840

    Hi, many thanks for your post. The majority of the steps within the SQL jobs are of the type: 'Operating System Command (cmdExec). I've just set up a job, with a single step that I know will fail. This job had an output file specified under the advanced tab of the step properties. Upon failure nothing is written to the output file, should I be expecting some info? (I'm using SQL 2000). Regards.

  • May 16, 2007 at 11:15 am

    #706888

    #1 on the Top Ten list of answers you do not want to hear from your DBA - "Well, it depends " ...

    You may or may not get any additional information.Other than permissions to shares/folders and files as causes initially the potential issues are only limited by the commands that you are executing. Once I get a failure in a CmdExec the first thing I do is execute the same command under the same credentials from a Cmd Window (I always use the advanced tab) and take it from there.

    Oh, I also use Google - Try  "Code -1073741819" with the double quotes as the search string ... I know that there are hits ... but not knowing the exact command ... well you know ...

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

  • May 17, 2007 at 2:01 am

    #707027

    Hi there, thanks for your response. The behaviour we are experiencing is rather bizarre and does not suggest lack of permissions - the jobs are scheduled to run overnight (e.g. start at 3am). Upon failure, the poor guy on support is notified, logs in and re-runs the whole job using the same credentials. This works everytime.

    I've tried goggling the error code, and the hits suggest probable causes as anti-virus or service pack related. I'm pretty sure that none of these have 'changed' recently. These jobs have been running fine for over a year and only recently have they started failing. All this does point to a change to the environment that is causing the failures...but the problem is what...

    With regards to the commands, they're simply calling a custom exe passing in some parameters. The first thing the app (exe) does when it kicks off is to log a 'I am starting' record in a table (sql server). It's not even getting here, which suggests a) SQL Agent is unable to kick off the exe or b) there is a problem with connecting to the database/server? Under each of these conditions I'd expect something to at least be written to the application event log or system log, but there is nothing in either of them...

    Anyone have any further ideas? Many thanks

     

  • May 17, 2007 at 10:36 am

    #707214

    Hi

    u could test the connectivity of the OSQL job by creating another job with same login parameters and executing a test procedure which could insert a row in a test table.If the data is inserted in the test table then there is no problem with the connectivity

    of the OSQL job.

    If this works then u could try to run the exe through outside of the sql server environment passing the same parameters and see if the exe is working fine.If the exe fails then that could be the problem.

  • August 9, 2007 at 1:44 pm

    #725840

    Did you ever find a solution to this problem?  We are having the same issue with the same frustrations and no common threads other than it is a cmdexec job step.

  • November 29, 2007 at 7:25 am

    #755420

    I get the same error sporadically when processing a virtual cube via DTS.

    The error would happen about 2-3 times a year on our test system, never on production.

    Now, after years of this behavior, the error has occurred twice in the last month on production.

    The DTS package does a full processing of two cubes and then the virtual cube based on these cubes.

    I've tried logging but it gives no useful information.

    Any ideas?

  • April 17, 2008 at 6:23 pm

    #804067

    The same thing: The job run for 5 months with success. Since 4 days I get this error.

    The funny thing is, that the log says "job failed after 4 minutes with error code -1073741819" but the job intern log lists the single steps of the DTS for over 10 minutes and all steps of the DTS end with success! This means, that the DTS proceding is perfect and is running after this ugly error.

  • March 29, 2009 at 4:40 am

    #967990

    We are currently grappling with this issue and have a case opened with microsoft but it does not seem to be progressing quickly at this point.

    I have been looking around and have found some references that may (...or may not) be of help.

    I will be taking these to work for testing this week, but someone on this blog may get the chance before us.

    http://www.windows-tech.info/15/d1137044ff1684d8.php

    "Our issue turned out to be lookups sharing memory space. The failing packages all had lookups that were defined with exactly the same query for the reference table. They also ran concurrently, so occasionally, one would clear the lookup cache while another package was still using it."

    also

    http://support.microsoft.com/kb/924016

    http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/f1e336db-41bf-4eed-aab7-7d881fee55c3/

    cheers

  • July 28, 2010 at 3:35 am

    #1199133

    Hi - Has anyone come up with a definitive answer to this problem? Hoping so as I'm experiencing a similar issue with a scheduled job on SQL Server 2000.

    It's running CmdExec that regularly fails with 'The step did not generate any output. Process Exit Code -1073741819. The step failed.' The CmdExec is running a 3rd party exe that is basically importing data. I've run several traces and on each occassion I'm getting an error in the log, the data has actually been successfully loaded/committed, so I don't know why I'm getting an error.

    I can see in the trace file that it's doing ( loads ) of inserts, it then commits. The trace file doesn't show any DB activity for about 5 minutes when the agent logs the error.

    Thanks - S

  • July 28, 2010 at 11:37 pm

    #1199610

    i never did pinpoint the problem but we upgraded to a new server in feb 2010 and i have not seen the error since. the new server has all the same software and version levels installed - maybe not since my original post in 2007, but the same coming from the old server. i'm pretty sure that i've seen that error in 2009 on the latest software levels (SQL 2000 Standard SP4, Win2003 Enterprise SP2, etc).

  • July 29, 2010 at 2:20 am

    #1199648

    ...amazing how many issues dissapear when you throw hardware at them! Did the behaviour I saw in the trace file sound familiar? i.e. Commits successfully and then appears to be no activity on the DB for several minutes and the job agent logs the failure?

    thanks - S

  • July 29, 2010 at 5:34 am

    #1199719

    i never got that far in the debugging ...sorry.

  • July 30, 2010 at 8:08 am

    #1200352

    hey, I'm just glad that someone has experienced the same pain I'm going thru'! I've Googled the error code extensively and everything I've found related to DTS and SSIS...

    S

Viewing 15 posts - 1 through 15 (of 24 total)

You must be logged in to reply to this topic. Login to reply