more news:

There has been no change after uninstalling the SDK.  Since there may
be some who will no doubt ask, I will share a few more pieces of
information.
I have used netstat to verify there is indeed a program listening on
the prescribed Tcp port, but I can also verify nothing is going on
under the hood:
---------------
H:\> telnet localhost 8080
Connecting To localhost...Could not open connection to the host, on
port 8080: Connect failed
---------------
Correct behaviour, as everyone here knows, should have been standard
http traffic at that point (I'd issue my GET, the server would issue a
2xx response, followed by an RFC-compliant message [the requested
page], and then either drop the line or hang out in case I start
requesting other files, like images or anything else with a ``src''
attribute in the tag).  As we can see, nothing like this is
happening.

The Windows Firewall (Internet Connection Sharing Service) is not
active, nor has it ever been active.

Before anyone gets into file ACLs, I will remind everyone those checks
are performed *after* a connection is established; at the moment I am
not connecting to anything.

I have tried both the launcher ``WebDev.WebServer.exe'' in my
framework dir, as well as my VS dir, as well as a copy from another
machine (one which works correctly), and still no joy.

I am not in any mood to re-install VS2005 Team Edition, so I am
looking for other options.

Many thanks in advance.

</RANT>

corrections to previous post: discard the word ``aforementioned'' in
first paragraph.  That should have been removed after a minor
reformat.

[ top-posting on purpose ]

Short answer: read the event log.  Long answer follows...

Success! First I'll explain what was going on, and I'll point out my
mistakes.
I should mention that I should have been able to diagnose this *MUCH*
earlier, and we will visit that mistake in detail; for now let's look
at all of this.

We all know that programs just don't ``go bad'' like eggs.  Programs
stop working because someone changed something (most of these wounds
are self-inflicted).  I (wrongly) assumed the VSSDK was the culprit
because that was the last thing I installed.  I wasn't sure if I had
installed it before or after the last web project I had to do, so I
erred on the side of ``self-inflicted wound''.  This was not the only
thing which had changed.  Unbeknownst to me, the IT staff changed a
setting on the Alteris server.
Alteris is a program much like MS's SMS; it remotely monitors
computers and pushes installations and configurations.  So the change
made wasn't even on my computer, but it did cascade downwards.  The
staff directed the Alteris program to check up on the Cisco Security
Agent program on each of the computers, and activate said service if
it is not running.  The default rules they gave it prevents a host
from accepting Tcp connections.  Like a shim, it slides in between the
IP device and the TCP device, so services which are ``allowed'' carry
on w/o any impact, and services which are ``denied'' never even
receive the handshake (SYN packets).  So when I did a quick netstat I
could see several things listening, but none of the interesting things
were receiving accepts.  What lead me to the correct diagnosis was not
the correct means at diagnosing this trouble (this is *my* second
mistake, which I'll cover in a little bit).  Since the CSA operates as
an IP filter, it could ion theory block any transport we like
(brilliant idea, just bad luck on my part since the default rules are
geared for Average Joe Desktop, not Random Joe Hacker).  I was able to
diagnose this by installing the simple tcp services and take a gander
at the echo/chargen/qotd demons.  Sure enough, even though they were
installed and listening no connections were allowed.  I then wrote a
quick program (single-user echod) and verified my program was never
receiving the connection requests.  So a change on one machine (host
X) was the cause of networking troubles on another machine (machine Y)
because the very design goal of Alteris is to cascade.  This is all
very cool (a good idea for anyone who has to maintain several hundred
computers), but if the wrong rules are pushed out then watch out
baby.

This is one of the few instances of which I know where changes on one
machine borked a second machine (Kerberos and LanMan changes are of
course obvious).

Mistake #1:
Since UNinstalling the SDK didn't ``fix'' my troubles I should have
instantly stopped where I was, raised my hand, and said ``I need an
adult!''.  Monkeying around with the network subsystem, fooling around
with IIS, etc, threaten to make things even worse, because I could
foul up a command and introduce a SECOND problem.  It's hard enough to
trouble-shoot one error at a time; I don't need to self-inflict five
more on my own head.

Mistake #2:
I should have, from the very very begining, checked the event logs and
ran a network trace, rather than rely on some twisted form of
philosophy.  The event log clearly indicated the CSA was blocking
these ``bad-boys''.  Installing the chargend or echod should have only
been done after checking the OBVIOUS.  Right there at the very top of
the event log was a bunch of CSA stuff.  A blind man could have read
it.  I neglected to follow proper trouble-shooting practices on NT-
based systems and risked exacerbating my troubles.  Also, if the echod
or chargend aren't working, writing my own high-level socket
application would most likely tell me even less.  If I really wanted
to know what was going on I'd have to write my own IP filter (just
specify Raw for protocol when opening the socket), and this is absurd
when all this is solved by simply reading the event log first and
foremost.

I'm sure I made five or six other mistakes which ego and subconscious
prevent me from seeing, but if I had only read the event log first and
foremost I would not have made any other mistakes.

In short it is just as Wilferd Brimly says: You check your event log
and you check it often.  It's the right thing to do.
Don't be a fool like me.  *blush*

Now that my face is all red, I think I finally have a reason to quick
drinking bleach on Saturday nights.  Eh-yup I'm pretty embarrassed.

Juan has my thanks for his response, and those who didn't respond (but
were thinking about it) have my gratitude in anonymity.

</RANT>