After encountering the weird fail-to-start problem of StarDict 3, I did a few more experiments, the results were quite interesting.
Basically, I used two methods to start StarDict: one way is to use a shortcut create by the StarDict installer; the other is to go to "C:\Program Files\StarDict" and run stardict.exe by double-clicking it. The essential difference of the two is that the former starts in "C:\Program Files\Common Files\GTK\2.0\bin" (as can be seen from the properties of the shortcut), while the latter "C:\Program Files\StarDict".
If I start StarDict by the first method, no mater how many times I close it and restart it (by the same method), it works well. However, if I try the second method, no mater how many success or fail starts previously tested, it will no longer be able to start (using either method), well, unless I log off and then re-login (or restart the computer). There might be other ways that could fix this, e.g., renaming the directory as I did last night. Anyway, trying to open stardict.exe directly from its own directory is worse than unsuccessful, it's somewhat poisonous -- it causes the original working method to fail as well.
I do know how this happens, but I guess it might have something to do with the dynamic loaded libraries StarDict uses. Given the fact the the first approach uses the GTK bin directory, I would further guess the GTK+ DLLs (or the way StarDict uses them) might cause the problem. But why does it has to start from that GTK bin directory, when once we try to start it somewhere else it would not start again even from the GTK bin directory? Perhaps StarDict would look for some files and some flag is issued when it fails to find them, and perhaps Windows preserves such a flag until something special happen. Not sure if the OS could detect flaws in the program (such as overflow) and stop allowing it being run (for protection of the system). When the directory is renamed, it might be consider as another program so it could work again. But this does not explain why when the file itself is renamed it would not work, nor can it explain why once the directory name is renamed, we can start it directly without going back to the GTK bin directory. Well, it looks like a DLL conflit problem. Maybe I should use the
Process Monitor (which, BTW, just released a new version v1.22 today) to check what exactly StarDict has done to the system when it starts.