Pro Tools quits while importing tracks...

I've been having a problem with importing tracks into our mix/editing sessions using Pro Tools 6. It only happens once the first time you import tracks into the session. Pro Tools will just quit with no error message and you are forced to restart and launch Pro Tools again. I can then import tracks as many times as I want after this occurs in this particular session. It would not happen with every session I worked on which was the confusing part but I discovered today that it only happens with the sessions that we use as templates (Stationary Pad). I have spoken with other people who work on post mixes the same way and they experience the same problem so I am wondering if anybody else has had this problem and how we can get it fixed. I am sticking with Pro Tools 6 and OS X but hate having my sessions quit at the start of a mix especially when you are dealing with 6 to 7 reels with clients always putting on the pressure to keep on moving. Here is the console crash log that I get when this occurs. Any help would be appreciated. This happens on multiple systems using anything from Hd, Mix, D24 etc. Date/Time: 2003-10-31 09:07:33 -0800 OS Version: 10.2.6 (Build 6L60) Host: HD-Playback-2.local. Command: Pro Tools 6.1 PID: 536 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xffffff78 Thread 0 Crashed: #0 0x01093210 in 0x1093210 #1 0x0105ab4c in 0x105ab4c #2 0x01056b78 in 0x1056b78 #3 0x0105ac9c in 0x105ac9c #4 0x00ffd21c in 0xffd21c #5 0x01054e8c in 0x1054e8c #6 0x00fd06b8 in 0xfd06b8 #7 0x00fd1590 in 0xfd1590 #8 0x00ffcf90 in 0xffcf90 #9 0x0106ba1c in 0x106ba1c #10 0x004c3b70 in 0x4c3b70 #11 0x009bd1c8 in 0x9bd1c8 #12 0x009bcc48 in 0x9bcc48 #13 0x009be3dc in 0x9be3dc #14 0x00a96504 in 0xa96504 #15 0x90163230 in __CFRunLoopDoTimer #16 0x90148d28 in __CFRunLoopRun #17 0x90180f58 in CFRunLoopRunSpecific #18 0x969a3b70 in RunCurrentEventLoopInMode #19 0x969b3a78 in ReceiveNextEventCommon #20 0x96a05090 in ReceiveNextEventInMode #21 0x003ec7f0 in 0x3ec7f0 #22 0x004ea314 in 0x4ea314 #23 0x003ecebc in 0x3ecebc #24 0x004c481c in 0x4c481c Thread 1: #0 0x90042668 in semaphore_timedwait_signal_trap #1 0x9003e894 in _pthread_cond_wait #2 0x90232770 in TSWaitOnSemaphoreCommon #3 0x9023b550 in TimerThread #4 0x90020d28 in _pthread_body Thread 2: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x90232754 in TSWaitOnSemaphoreCommon #3 0x90233094 in DeferredTaskThread #4 0x90020d28 in _pthread_body Thread 3: #0 0x90041b88 in mach_wait_until #1 0x90263c3c in MPDelayUntil #2 0x010046ac in 0x10046ac #3 0x009dcf38 in 0x9dcf38 #4 0x009dd30c in 0x9dd30c #5 0x00fff140 in 0xfff140 #6 0x902b739c in _MP_CFMTaskProc #7 0x9025d924 in PrivateMPEntryPoint #8 0x90020d28 in _pthread_body Thread 4: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x017665e4 in 0x17665e4 #4 0x0176625c in 0x176625c #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 5: #0 0x90073c28 in mach_msg_trap #1 0x90005f70 in mach_msg #2 0x036e4eb8 in DSI_GetIntMessage #3 0x01896e30 in 0x1896e30 #4 0x018952f4 in 0x18952f4 #5 0x01895298 in 0x1895298 #6 0x902b739c in _MP_CFMTaskProc #7 0x9025d924 in PrivateMPEntryPoint #8 0x90020d28 in _pthread_body Thread 6: #0 0x90073c28 in mach_msg_trap #1 0x90005f70 in mach_msg #2 0x901489f0 in __CFRunLoopRun #3 0x90180f58 in CFRunLoopRunSpecific #4 0x90148240 in CFRunLoopRun #5 0x036edd64 in _ZN15MessageReceiver8TaskMainEPv #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 7: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x0101764c in 0x101764c #3 0x00ffea60 in 0xffea60 #4 0x009ae544 in 0x9ae544 #5 0x009aee60 in 0x9aee60 #6 0x009ae5a4 in 0x9ae5a4 #7 0x009aea6c in 0x9aea6c #8 0x00fff140 in 0xfff140 #9 0x902b739c in _MP_CFMTaskProc #10 0x9025d924 in PrivateMPEntryPoint #11 0x90020d28 in _pthread_body Thread 8: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x0101764c in 0x101764c #3 0x00ffea60 in 0xffea60 #4 0x009ae544 in 0x9ae544 #5 0x009ae5e0 in 0x9ae5e0 #6 0x009ae5a4 in 0x9ae5a4 #7 0x009aea6c in 0x9aea6c #8 0x00fff140 in 0xfff140 #9 0x902b739c in _MP_CFMTaskProc #10 0x9025d924 in PrivateMPEntryPoint #11 0x90020d28 in _pthread_body Thread 9: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x0059e294 in 0x59e294 #4 0x902b739c in _MP_CFMTaskProc #5 0x9025d924 in PrivateMPEntryPoint #6 0x90020d28 in _pthread_body Thread 10: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x0101764c in 0x101764c #3 0x00ffea60 in 0xffea60 #4 0x009ae544 in 0x9ae544 #5 0x009aee60 in 0x9aee60 #6 0x009ae5a4 in 0x9ae5a4 #7 0x009aea6c in 0x9aea6c #8 0x00fff140 in 0xfff140 #9 0x902b739c in _MP_CFMTaskProc #10 0x9025d924 in PrivateMPEntryPoint #11 0x90020d28 in _pthread_body Thread 11: #0 0x90073c28 in mach_msg_trap #1 0x90005f70 in mach_msg #2 0x953ddd60 in _ZN15XServerMachPort14ReceiveMessageERiPvS0_ #3 0x953d1798 in _ZN16MIDIInPortThread3RunEv #4 0x953d55dc in _ZN7XThread9RunHelperEPv #5 0x90020d28 in _pthread_body Thread 12: #0 0x9002570c in recvfrom #1 0x00931440 in 0x931440 #2 0x0092e7e8 in 0x92e7e8 #3 0x0092e88c in 0x92e88c #4 0x0092df04 in 0x92df04 #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 13: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x017665e4 in 0x17665e4 #4 0x0176625c in 0x176625c #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 14: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x017665e4 in 0x17665e4 #4 0x0176625c in 0x176625c #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 15: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x017665e4 in 0x17665e4 #4 0x0176625c in 0x176625c #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 16: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x017665e4 in 0x17665e4 #4 0x0176625c in 0x176625c #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 17: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x017665e4 in 0x17665e4 #4 0x0176625c in 0x176625c #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body Thread 18: #0 0x90042668 in semaphore_timedwait_signal_trap #1 0x9003e894 in _pthread_cond_wait #2 0x9022f57c in MPWaitOnQueue #3 0x90736fc4 in _ZN13TNodeSyncTask12SyncTaskProcEPv #4 0x9025d924 in PrivateMPEntryPoint #5 0x90020d28 in _pthread_body Thread 19: #0 0x9003ea88 in semaphore_wait_signal_trap #1 0x9003e8a4 in _pthread_cond_wait #2 0x9029ff28 in MPWaitOnSemaphore #3 0x017665e4 in 0x17665e4 #4 0x0176625c in 0x176625c #5 0x902b739c in _MP_CFMTaskProc #6 0x9025d924 in PrivateMPEntryPoint #7 0x90020d28 in _pthread_body PPC Thread State: srr0: 0x01093210 srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x20000000 lr: 0x01055c48 ctr: 0x00fbbf00 mq: 0x00000000 r0: 0x01055c2c r1: 0xbfffe230 r2: 0x01ea7000 r3: 0x0db3f1c8 r4: 0x021313d0 r5: 0x00000053 r6: 0x00000000 r7: 0xbfffe080 r8: 0x00000001 r9: 0x00000009 r10: 0x036b439d r11: 0xa0221734 r12: 0xffffff78 r13: 0x00000000 r14: 0x00000000 r15: 0x00000001 r16: 0x00000000 r17: 0x00000001 r18: 0x035cda38 r19: 0x00000000 r20: 0xbfffeaa4 r21: 0xbfffea8c r22: 0x01cec9d0 r23: 0x01cec9c8 r24: 0x01e95df0 r25: 0x01e95df8 r26: 0x10995cb0 r27: 0x00000002 r28: 0x0db324f8 r29: 0x00000002 r30: 0xbfffe2dc r31: 0x0db3f1c8

I have the same thing but only when dragging a track from a cd directly onto a track from the workspace window. 6.1 G4 dual 1.25

The easiest workaround would be to open each template and save a session in the same folder as the template. Then you can import tracks from the sessions and the templates are still templates!!! Ironically, I have never imported tracks from a template, only saved sessions as needed from them.

I know there will be ways around this but I really need this problem to be fixed. I also don't think the problem is being understood. We have set up sessions for various types of mixes ranging from full blown 5.1 film mixes to smaller promo mixes. These sessions have no audio files in them, just tracks, i/o setups, plug-ins, memory locations for pro control layouts, automation enables etc. These templates are very involved and all it requires us to do at the start of a mix is to import the editors sessions and drag their regions into the tracks we have already laid out. I make these finished templates stationary pads (get info on session file and check stationary pad) so if a new mix comes in I just load the appropriate template, it asks if I want to edit the stationary or create a new session. I choose to create a session for the mix on our mix drive. I import the tracks I need to for the mix and pro tools will crash the first time I attempt this. This is the problem I need fixed. It can be re-created very easily. Make a session with 1 track and some audio in it. Make a new session and make it a stationary pad. Launch this file, choose the New Session option. Import the track from the first session created. Pro Tools will crash. I just hope that Digi will reproduce this and fix it in an upcoming release.

I work from a template too and I have seen this problem. The workaround was to use "refer to source media" instead of "copy from source media," then it would work....

The problem is that no Audio Files folder is createt when making a session from a template. If you record a second of audio you will have the folder and it will not crash. Option two is to create a new blank session and import data from the "template" which in that case don't have to be a "Stationary Pad". Maybe theres a workaround to get the Audio Files folder to be created when you derive a session from a Template / Stationary Pad. Good Luck.

....or rather, the Audio files folder is temporarily created in the Root folder of your Tempate, not in the session folder. If you close the new session without saving they're gone. So obviously the Disc Allocation is looking within the session folder where there are no Audio Files folder. Bug Digi?

Yeah we're experiencing this too on importing OMFs into new sessions created from templates. Definately an annoying bug! m.

I'm glad others are having this problem as well. I know there will be some ways around this but it is a problem that Digidesign should address and fix. I think recording a bit of audio after creating the session is the fastest and easiest solution and will use that until the bug is fixed. Thanks for the suggestion.