SSIS 2005 crash and dump near all the time now!!!

Question

Hi,

I'm suffering a crash & dump issue with SSIS 2005.

I'm running 50 packages from 1 "master" package. and now my process always crash near the end.

In the past the problem occurs rarely. but now its all the time!

the problem occurs around the same packages, but not always the same.

Runing in x64 or 32bit mode results in the same issue; changing the max concurrent option to 1 produce the same behavior!!! (in the past changing this generaly solve the problem, but this is no longer the case)

but manually running the packages works fine.

I have updated SQL Server to the latest SP3 + latest cumulative hotfix, but the problem still here.

What can I do to identify what is causing the issue?

Answer 1

The first suggestion I would have is to list any errors you are having.  Without seeing the errors we can't really help you...

---

Please mark answered posts. Thanks for your time.

Answer 2

simple:
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     ProcessID = 16148
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     ThreadId = 0
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     Flags = 0x0
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     MiniDumpFlags = 0x0
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     SqlInfoPtr = 0x000000000100C9A8
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     DumpDir = <NULL>
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     ExceptionRecordPtr = 0x0000000000000000
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     ContextPtr = 0x0000000000000000
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     ExtraFile = <NULL>
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     InstanceName = <NULL>
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,     ServiceName = <NULL>
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
10/14/09 08:16:17, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
10/14/09 08:16:29, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
10/14/09 08:16:29, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files\Microsoft SQL Server\90\Shared\ErrorDumps\SQLDmpr0055.mdmp
10/14/09 08:16:29, ACTION,                DTExec.exe, Watson Invoke: No

I do not have more information.
Except the mdmp file himself.

Answer 3

Have you set up log files for this process?  If not, can you do so and see what the actual error stack is (as opposed to the dump file)?

---

Please mark answered posts. Thanks for your time.

Answer 4

I'm logging the internal activity into a database using the SSIS integrated logging system.
and the batch file which call dtexec, log the errors into a text file.
When the crash occurs, the text file has nothing.

And the database contains a lot of logged events. (the onpipelinerowsent, onprogress and other events)
From what I can see, the logs generated just stops when the crash occurs.

finally the windows event log do not contains anything more.

So I don't have anything else in my hands.

Can I generate the error stack by logging something else?

for info, I have changed the registry entries to extend the content of the dump files. (SqlDumperFlags & SqlDumperMinidumpFlags)
so the dump file now contains more information (900mb instead of 15mb)
but I don'T have a tool to open it.

Answer 5

And the database contains a lot of logged events. (the onpipelinerowsent, onprogress and other events)
From what I can see, the logs generated just stops when the crash occurs.

In the logging table, check for the onError event.
Is there any entry for this event? if yes please provide that.

---

Hope this helps !!
Sudeep      My Blog

Answer 6

no there is no errors generated anywhere.
nothing more than what I describe in this discussion.

Answer 7

Your best bet is to call support and have someone look at the memory dump.

Its not an easy skill to open memory dumps and look at the stacks to figure out what is going on.

The support team uses a tool called WinDbg and you can get it from the public download.
http://www.microsoft.com/whdc/devtools/downloads.mspx
Install the bitness that matches your machine. (x86 for 32-bit x64 for 64-bit)
After install start WinDbg from the start menu.

Open the SQL0000*.mdmp file in WinDbg from the File > Open Dump menu.

Make a folder to hold symbols on your hard drive C:\symbols

In Windbg with the dump open, point your symbol path to the Microsoft public symbol server. This is the symbols path...
srv*C:\symbols*http://msdl.microsoft.com/download/symbols


More details on the public symbol server = http://msdn.microsoft.com/en-us/library/cc266473.aspx

Check the Reload box on the symbol path, and click OK. It will take a little while to download the symbol files - couple minutes maybe.

Next do .ecxr in the Windbg command line to set the context to the frame which has the exception.

Next do kL to show the stack of the crashing thread.

Paste that here, or call support :-)

Thanks, Jason

---

Didn't get enough help here? Submit a case with the Microsoft Customer Support team for deeper investigation - http://support.microsoft.com/select/default.aspx?target=assistance