I must ask what more is needed for this issue has some kind of reply. This seams to be a seriously issue because we can't update to the latest release of VB and it's confirmed by other users but still no response from the devs.

I can help on whatever you need but please inform me what's relevant for understanding this issue and fix it or put in the road map.

I can't reproduce the issue on my mac host, so it is not easy to find/fix the reason without help of any user who is able to reproduce it.
Could any of you please provide me with the list of machines you have registered (through VBoxManage)?
It may be also helpful to know if Virtualbox Manager still hangs (or not) after you will unregister all the machines (through VBoxManage too).

The file with the hang stack information attached by qosobrin (virtualbox.txt) is not informative. We will probably check the stack trace of the debug build.

There is a test debug build for Mac OS X (based on 4.2.7 version) available at:http://www.virtualbox.org/download/testcase/VirtualBox-4.2.7-83123-OSX.dmg
Please note, this build should NOT be used as normal installation (its a test build to debug this issue).
If you wish to help us to find the reason of the hang, you can install this package (better to remove already installed before that) and run VirtualBox Manager in gdb in console terminal, then reproduce the full hang and then press "ctrl+c" (in console) to interrupt application execution in gdb, then call for back trace using "bt" command in gdb. Probably the call-stack will be helpful.

Hmm, that stack is not informative too, without debug-symbols I seems can only guess what happens there. There are no links to actual GUI code, only base Qt classes. I will ask our build-engineers if it is possible to include debug-symbols (into test debug version).
From that I see its something with pixmaps caching stuff. Could you please try to reproduce the hang few times and check if it happens always on the same place? If the places are different, other stacks can probably enlighten the situation.
Also, just to clarify it for me, when the hang happens - GUI become fully non-responsible to mouse/keyboard interactions?
Thanks in advance.

The last two traces looks more like GUI hangs on worker thread termination (thread which acquires information from VM).
Could you please check if the issue happens with just one newly created VM in VM list? (you can unregister all your VMs with VBoxManage for example and you can backup your configuration folder before that). May be thats some particular VM configuration causes the hang.

Hmm, that is interesting.
I'm not able to reproduce the hang with inaccessible VM too. Indeed inaccessible VM handling even simpler than accessible one. So that makes issue even more strange. I hope you didn't removed that VM configuration file? Could you please provide me with .vbox from that VM folder? Also please check if returning back inaccessible VM declaration into VirtualBox.xml restores the hang behavior.
Thx in advance.

Hi Kimus,
I can provide you with full debug trunk build with debug-symbols (to check the same as in comment 6).
Is it possible to discuss it with you in some irc-channel? For example we have external channel at irc.freenode.net (#vbox).

We finally found a way to reproduce. One needs a very special type of inaccessible VM to trigger a rather strange corner case which then leads to the API sending bogus events to the GUI, which re-trigger the strange API corner case. Effectively it's an endless loop in cooperation between the API (VBoxSVC) and the GUI.