I notice... DebugSession >> resumeProcess "Make sure the interrupted process is restored properly and restart the low space handler" interruptedProcess isTerminated ifFalse: [ errorWasInUIProcess ifTrue: [ UIManager default resumeUIProcess: interruptedProcess ] ifFalse: [ interruptedProcess resume ]]. "restart low space handler" Smalltalk installLowSpaceWatcher. and... MorphicUIManager >> resumeUIProcess: aProcess "Adopt aProcess as the project process -- probably because of proceeding from a debugger" UIProcess := aProcess. UIProcess resume This doesn't seem to do anything regarding the second UI process spawned in... MorphicUIManager >> debugProcess:context:label:fullView:notification: With Process Browser running with auto-update on, running the following experiment confirms that the second spawned UI is killed. TestCase subclass: #Example2 Example2 >> test1 Processor activeProcess name: 'ORIGINAL UI'. self halt So I'm curious, where is the code killing the second UI ? Also curious, when the first UI turns into a debuggger, why later reinstate the first UI and kill the second UI? If the second UI started clean and is running happily, why not leave it running and let first UI thread terminate normally? I get some strange behaviour** sometimes , and wonder if the swap back it might be related to this. ** Like today #testUserPriority below not opening a debugger at the first halt statement, or opening a pre-debug window that has a blank pane. testUserPriority debug := true. Processor activeProcess priority: 38. self halt. highPriorityProcess := self highPriorityRunLoop. Transcript cr. debug ifTrue: [self halt]. 3 timesRepeat: [ Transcript crShow: 'U'. self wakeHighPriorityLoop.]. highPriorityProcess terminate. cheers -ben