The problem lies with Moby. It makes a local connection to listen on any ports, and when this is denied it causes Moby to crash.
After "debugging" for a long time (which almost killed me
) I can now say with confidence that this port listening issue is not in any way malicious nor is it any bug in Moby code.
Moby is developed in Visual Studio .NET 2005, which offers this brand-new option to "Make single instance application".
What it does is only letting the end-user have just one copy of the program running at the same time. If another session of the same program is initiated, what you'll see is the first instance of that program gets focused and brought to the front on screen.
If the application is compiled without "Make single instance application" checked, it does not listen to any port. Also I made a compilation of Moby without enforcing "single instance", it turned out no port was opened/listened to.
Unfortunately, I was not able to find anything online, or in MSDN archives, that talks about this issue.
However, thank god I was able to capture this fleeting "connection established" event:
It basically showed that the second Moby instance launched was communicating with the first one that was already running, after this split-second contact, the second instance closed itself and the first one was focused and brought to the front. And that established connection was dropped.
So based on Overview of the Visual Basic Application Model
, I'm guessing this port listening is necessary for a "make single instance" application to:
1. Raising the "StartupNextInstance" event
2. Pass command-line arguments to the first instance
3. Tell the first instance to focus self
etc. before the second instance auto exits.
I do encourage everybody to test this out on Visual Studio 2005 Professional or Express
edition, with Process Explorer
, which is a marvelous free tool for monitoring application runtime behaviors.
Thank you again Defenestration
, I'll def use Process Explorer heavily to test & improve Moby before releasing.