none
Process exit code:1073741819 RRS feed

  • Question

  •    I have changed a SSIS package last week. Now, I met the problem that the package sometimes failed both in SQL agent and the BIDs.

      SQL agent  just give the detail: Process Exit Code -1073741819. The step failed.

       In BIDs,when I Check the log,there is even no error. But the last Infomation in the output windows is the package canceled. It just like somebody stop running package manually.

       The more strange thing is the package sometimes succeed with running the same data.

     

         Thanks for your help

     

    Thursday, July 13, 2006 4:27 AM

Answers

  • It looks like it crashes during the package execution. Could you describe your packages?

     

    The best advice I can give you is to contact the customer service guys and provide them the dump files. If you are lucky there might be already a hotfix available for your problems.

     

    Thanks,

    Bob

    Thursday, November 29, 2007 7:38 AM
  • 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.

     

    The resolution was to add a comment in each query to make sure each was unique. That fixed the problem for us.

    Saturday, February 9, 2008 2:45 AM
    Moderator

All replies

  • I have the same query, please help somebody..

    Thanks,

    Friday, September 7, 2007 6:12 AM
  • Is there anyone who can help us with this?

    Monday, September 10, 2007 7:02 AM
  • Be sure you have package logging turned on.  If so, are there any errors in the log?
    Monday, September 10, 2007 3:19 PM
    Moderator
  • I'm receiving the same error. 

     

    I'm running:

    Windows Server 2003 SP2 (64 bit, 4 cores)

    SQL Server 9.0.3204

    SSIS 9.0.3204

     

    My process has ~ 100 packages... there seem to be about 6-8 that fail with this error.  All the packages have unique GUIDs for all components.  The each package retreives data from a single table in DB A, transforms it, and places the data in a single table in DB B on on the same server.  No other processes use the databases.

     

    SSIS logging is on, but nothing is returned.  The packages are being run via SQL Agent (as a DOS command)... logging is on there as well, and only the start timestamp is returned for the processes that fail (DTExec is set to return all error messages).  We can identify packages that fail due to package level logging procedures, but no SSIS events seem to be firing.

     

    Any help would be appreciated...

     

    Cheers,


    David

    Wednesday, November 28, 2007 1:33 PM
  • Also... no errors appear in the event log and no errors appear in a Profiler trace.  Setting MaxConcurrentExecutables=1 for the packages that fail does not alleviate the problem.  SQL Server does, however, create a dump file when this occurs...

     

    Wednesday, November 28, 2007 3:20 PM
  • This thread has been unanswered for a while...

     

    [Microsoft follow-up]

     

    Wednesday, November 28, 2007 4:55 PM
    Moderator
  • It looks like it crashes during the package execution. Could you describe your packages?

     

    The best advice I can give you is to contact the customer service guys and provide them the dump files. If you are lucky there might be already a hotfix available for your problems.

     

    Thanks,

    Bob

    Thursday, November 29, 2007 7:38 AM
  • I work with David, so I thought I'd post an update. The support guys took a look at the dump, and pointed us to this KB article: http://support.microsoft.com/kb/924016

     

    It's a bug related to the same memory space being used by lookups running in parallel data flows. The symptoms David was experiencing don't match the article, but we're testing the suggested fixes to see if that resolves it.

    Friday, November 30, 2007 1:43 AM
    Moderator
  • I have the same issue as David's.  I wonder if there is any update/progress on this.

    Friday, February 8, 2008 10:53 PM
  • 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.

     

    The resolution was to add a comment in each query to make sure each was unique. That fixed the problem for us.

    Saturday, February 9, 2008 2:45 AM
    Moderator
  • Hi

     

    in my case; there are packages with multiple data flows; but none of them has lookups in it. still i am facing the problem where 1 out of 10 times my package fails

     

    is this because of maximum concurrency? can you suggest me any other options for the same

     

    Regards

    Viv M

    Friday, November 7, 2008 10:52 AM
  • It shouldn't be because of maximum concurrency.  You're getting the same error code?  What do your data flows look like?  What is the state of the machine when the error occurs?

     

    Everytime I've seen it, it's been because the machine is out of memory and paging occurs within SSIS.  In particular, this error occurs when a commonly shared piece of memory is paged, and a memory reference fails.

     

    Regards,


    David

    Friday, November 7, 2008 8:02 PM
  • Hi

    Apologies for the last response;

    Yes, i am getting the same error code. the data flow is a simple data flow reading from SQL source and inserting into single SQL destination;

    There is no change in the state of the machine; howeever when i restart the load again; it rans fine;

    are you refering about the RAM memory?

    Regards
    Vivek M
    Monday, February 1, 2010 3:03 PM
  • Hi,

    I have encountered a similar issue in one of my SSIS packages. The package performed the following tasks.

    • Check for the PSV files in the source directory. These files are of two types *phone*.psv format and *lead*.psv
    •   Convert the new files into .xlsx files and then log the processed file names into another table
    •  The file processing for the two types of files was being done in two different For Each Containers, which processed the files parallel'y if both the type of files were found.
    • The package ran fine when only one of the file types were found, but if both the types of files were found then the package failed with the same error. 

    "The return value was unknown.  The process exit code was -1073741819.  The step failed."

    On checking up the details provided on this thread i found the culprit was the parallel file processing causing a conflict in the cache usage, thereby causing this error. (Refer http://support.microsoft.com/kb/924016?wa=wsignin1.0 )

    I then changed the package execution process in a manner that the two for each containers executed one after other even if both the types (phone, lead) of files were found. I basically made the control flow sequential from parallel. 

    The issue didn't reoccur a single time after that.

    So the point here is to try and make the file processing tasks as serial (in CONTROL FLOW) as possible in the sequence of execution, thereby bypassing any instance where the two different operations doing similar job (thereby using the same cache) do not create a conflict in package execution.

    Hope this helps to clear the Air on this issue to some extent.

    Thanks

    Suvrat

    Thursday, May 23, 2013 1:55 PM
  • Hi Suvrat,

    I am also facing the same problem. Please let me know if your packages are 2008 version or 2005?

    Thanks,

    Keerthi

    • Proposed as answer by Davedan9 Monday, April 13, 2015 2:22 PM
    • Unproposed as answer by Davedan9 Monday, April 13, 2015 2:22 PM
    Friday, May 30, 2014 3:23 PM
  • I think I discovered the answer.  This error seems to come from more the one instance of a program that is created as to run as only one instance at a time.  So you receive a shared memory error.  In my case I was calling an FTP program to FTP some files. What the problems was, there was a copy of the same program running at the same time in the background and so the second instance of the program errored out. Once I made sure that only one instance of that program was running at a time, it ran ok.  I suspect this is mostly for items being called outside of either SQL or SSIS. 

    David


    Davedan9

    Monday, April 13, 2015 2:28 PM