What you describe is atypical and it's very likely that outside factors that are not under Remote Buddy's control lead to the phenomena you describe.

To investigate further on what is happening on your system when Remote Buddy is unresponsive on your machine, I'll need more information from you:

1) When the "hang" occurs, please start /Applications/Utilities/Activity Monitor.app (AM), select "Remote Buddy" from the list, then select "Analyze process" from AM's toolbar or AM's menu. Please cut and paste the result and send it to me.

2) To get an idea of what your machine looks like, please send me a system profile. Therefore, launch /Applications/Utilities/System Profiler.app (SP), then select "Save as.." from SP's menu. Please choose the XML format and send me the file you save.

For sending both pieces of information, please use the email address from the imprint ( http://www.iospirit.com/imprint/ ).

...

Regarding the "force quit doesn't work": there's nothing in Remote Buddy that could prevent it from being force quit. On a healthy system, this will always work. Remote Buddy is really just a normal application like any other application.

There are, however, general situations, where quit and force quit won't work on many applications on a system, and that neither have to do with or are specific to Remote Buddy. The same situations may also turn applications unresponsive without the application causing this state or being in the position to do anything about it. So, possibly, both of your issues eventually end up being caused by the same basic - and general - problem on your system.

Examples for such situations include:

a) external harddrive / network volume disconnect or I/O error. I've seen this a lot with external Western Digital drives (especially if they try to implement "power saving" on their own - I eventually stopped using two MyBook drives because of their unreliability) and - often enough - with Windows/SMB/Samba shares. When this occurs, many basic filesystem operations will never complete, causing the application to first hang, then the inability to force quit the applications because of unfinished/hanging I/O operations. This one's easy to identify, though: just try to access the volumes in question with the Finder. If the Finder locks up now, too (or just never presents the content), you know which drive/volume is causing you trouble. For USB drives, at least OS X Snow Leopard returns to normal operation when unplugging the respective drive (=> warning: just unplugging a drive may lead to data loss on that drive). If I recall correctly, unplugging the drive won't make any difference on earlier releases of OS X.

b) the use of IORegistryExplorer from the Xcode Developer Tools. There appears to be a bug in this tool that - under some circumstances - prevents services inside the kernel's IOKit from terminating. Running this tool for a prolonged time, I always end up in a situation where pretty much any application starts to hang sooner or later and then can't be force quit, either. I can reproduce this on a pristine, fresh install of OS X, too. Likewise, other tools (although I'm not aware of any existing) that dive deep into the kernel's IOKit and register for notifications on all of the services in the kernel may cause similar issues.

In both cases, you'll often be able to permanently "hang" pretty much any application by doing things as simple as trying to open a file with them - using the standard "open file" dialog window.

I may be able to say more - or even pinpoint a basic problem of your system - when I have seen the System Profiler profile for your system.

Best regards, 
Felix Schwarz