just tried to reproduce a similar case in Terminal.
#0) clear all stored  breakpoints (menu: Debug / View breakpoints / remove all)
#1) set the breakpoint in Studio using F9
#2) attach to process (shell if in Terminal)
#3) do ^yourroutine in terminal
#4) In Studio: <ctrl>+<F5>  let it run 
if your breakpoint is reached you see the yellow box

Hint: try it with some simple 5 line routine first

If you never see the yellow box then you just don't execute this line 

I've seen such behavior during debugging when I fell into some deployed system code (.obj only)
A similar effect happened to me when I touched some customized command, function, variable from ZLANG***
[which I tried to debug !!!]

I could gain control again by some <SHIFT><F11>  until returning to some code covered by .int
As Studio stores a lot of info in the Windows registry just killing Studion might cause some confusion. 

If it's just pure import / export  the .TIF you may access it as %Stream.FileBinary

But if you need some more sophisticated processing and have some working method (eg. in Python)
you may use it in some near future with the promised embedded Python  [@Bob Kuszewski ]
 

Until then you may take a look to my example in OEX about using Python methods & classes over CPIPE 

 

your code is : 

 Set classname mobj.FindClassName(SchemaName_"."_TableName)

 Set mgr.TableName SchemaName_"."_TableName
 Set mgr.ClassName classname

The class  to Export:  Class Persistent.PersonBackup Extends %Persistent

BUT you call it:

do setupExportImport^uTask12440("Export","PERSISTENT","PERSONBACKUP")

There is no class PERSISTENT.PERSONBACKUP
Try instead:

do setupExportImport^uTask12440("Export","Persistent","PersonBackup")

So the generator can find your class