DOS ain't dead

The short answer is: No, CLI/STI won't fix your problem.

It is quite possible that your subroutine takes too long, you are overflowing the stack, or any one (or some combination) of several other issues you could be having. You'll need to do some more in-depth troubleshooting to fully understand and isolate what's going on.

For example, if you think the problem is a stack overflow (and that's pretty likely based on your symptoms), you can test for that specific issue. It should be pretty easy to monitor/display the value of the stack pointer (SP) and see if it's what you think it should be. If your program provides its own stack space, it makes things even easier since the value of SP should be pretty consistent. If your program doesn't provide its own stack space, you can still monitor things but it's a little trickier to see if the problem is really related to the stack. Simply knowing that the problem is a stack overflow doesn't solve the problem, of course, but helps you figure out where to start looking. CLI/STI won't fix a stack overflow problem.

And, just so you know, it's NEVER a good idea to call a subroutine from an IRQ handler (like INT 08) that takes a long time to process. If a lot of processing needs to take place, you usually need to gather the appropriate data during the IRQ handler and put it in some kind of buffer, and then process the data in the buffer from outside the IRQ handler when timing isn't as critical.

Do you use DJGPP for your code? I remeber the caution about a need to lock memory that belongs to ISR (and all routines it may call and all data it may manipulate) to prevent being swapped out from RAM (in case you use swapping-enabled DPMI server like cwsdpmi)
see functions:
int _go32_dpmi_lock_code( void *_lockaddr, unsigned long _locksize);
int _go32_dpmi_lock_data( void *_lockaddr, unsigned long _locksize);
But it would be probably something else...

---
DOS gives me freedom to unlimited HW access.