Dealing with processes is not a trivial task, sadly.
From the terminal,
arara prints the compilation status and ends, as expected. When called from editors, I believe it's a matter on how each developer decided to handle process input/output. From TeXworks, things seem smooth, even if it requires user interaction. I once once a problem with TeXnicCenter when trying to rerun
pdflatex: the last process call got stuck somehow and files were locked. The only way to have my files "released" was to kill the offending process via task manager, so things started working again.
TeXnicCenter gave me a couple of headaches in the past, so I still believe there's nothing I could do on my end (the
arara part). That said, it's worth mentioning that Windows behaves quite differently from Unix.
arara is a Java program. Any calls to
arara will redirect to a call to
java -jar arara.jar and the Java Virtual Machine will be in charge of the execution. In Unix, we have that as a shell script (thanks to Karl for the suggestion), and in Windows, it's an
.exe; both are, in fact, wrappers to the
.jar itself. Maybe, maybe TeXnicCenter is confused with the
.exe resolving to a call to the JVM. What I can suggest is the following:
Try replacing the call to
C:\Program Files\arara\arara.exe in TeXnicCenter with a direct call to the JVM with
java -jar "C:\Program Files\arara\arara.jar", followed of course by the editor parameters. At least now we are "skipping" one expansion from the wrapper to a VM call. But this is just a thought, I have no Windows machine around to test it.
Sorry for the imprecise answer, but sadly the solution (if any) is on uncharted territory. As I mentioned before, calling stuff from stuff is very tricky and, most of the time, we just get the idea from phenomena observation.
I'm in the middle of developing a new version. I'll see what can be done when dealing with processes. That's also a hint for me to set a Windows VM. At least I'll have Windows inside a cage, where it should be.