Edited by Morbius on Oct 28 2006 10:59AM (2 times)
The lowest common denominator, in my opinion, comes down to the network stack for this issue.
GPG has stated that in their testing, it appears that the network socket is not initializing properly. Now GPGnet can not communicate to supcom, and it freezes, waiting for info that never comes. Terminate the gpgnet process and supcom can at least continue, albeit we now can only do sandbox mode.
So, if GPG has correctly isolated it down to that being the problem, then where does that leave us, the beta participants? It generally means there likely isn't going to be one program specifically, that is a fix.
Now, its been a while since I've rebuilt my stack from the ground up. So I may be off in some terminology or what not. But, here's my theory on it.
From System Info (start / all programs / accessories / system tools / system info), on the left side we open components, then network, then protocol. We can see our network stack settings in here. Generally there should be 14 or 15 entries for a clean system install (forget which number is the correct [14 or 15]). Generally, these are all protocols provided by MS. But if we install a virus scanner or firewall, it loads itself into the network stack here, so that it can intercept certain things as they come in. So in mine, the first four entries are NOD32 (NOD antivirus), rather then MS entries.
Could this be the cause of my software conflict, causing the network socket not to initialize? It very well could be. Will that be the cause for everyone else though? Nope. Disabling NOD may not be enough. I might have to physically remove NOD, so that these entries are put back to their original state with MS drivers. This, may or may not be the issue, but its very definitely a good working theory.
This would explain why we have so many varying solutions that only work on a few systems. Some are fixed with this network management thing and others don't even have that software. The list of of what has fixed it for some people is probably at about a dozen entries so far. Some have fixed it with dotnetfx, others by disabling firewall/anti virus, and even one fixed it by reinstalling directx (even though he already had the current version).
This tells us something. First off, that its not likely hardware specifically that's causing it. And secondly, with so many varied solutions, GPG will have to most likely find another way to program their network interactions. Whatever they are doing, it conflicts with far too many systems (systems that otherwise work fine).
At any rate, to test this, I then completely uninstalled NOD. Just disabling it, was not enough because that leaves NOD's drivers in the network stack (as seen in system info). Totally removing NOD, replaces the network stack back to the original MS drivers.
So, check your stack. If you see entries like NOD (in the top line of each entry, which is the Name field), then uninstall it. You may have a different anti virus. You may have a different firewall and it might show in the list. It could be an anti trojan or some network management thing. The thing to keep in mind, is that you should not guess which things are MS or not. If you do not know, then leave it be. But you might recognize a program name that you have installed yourself. If you do, uninstall that program and see if you can get in now.
For me, I just tested it. And this was my first time ever getting past the black screen of death. This means, wrong or right in my theory, that at least we know that NOD users also have to completely uninstall NOD to get it working.
So my assumption then, is that GPG has directly tried to interact with the network socket, but those of that have certain portions of our stack replaced with a virus scanner or other tool, are now hosed.
If someone is willing to check their stack, and and possibly identify what items are non-MS and uninstall those. That would help verify this.