I have reduced my code down as far as it will go and can duplicate
this issue at will. I have an ASP page containing a SQL insert. When
the page is first loaded, the insert happens twice. There is a
"response.write now" statement for debugging purposes, and it only
happens once.

The code is as follows:

<%

dim conn

set conn = server.createObject("adodb.connection")
conn.open "Provider=SQLOLEDB.1" _
& ";Persist Security Info=False" _
& ";User ID=MY_UID" _
& ";Password=MY_PWD" _
& ";Initial Catalog=MY_CATALOG" _
& ";Data Source=MY_IP" _
& ";Use Procedure for Prepare=1" _
& ";Auto Translate=True" _
& ";Packet Size=4096" _
& ";Use Encryption for Data=False" _
& ";Tag with column collation when possible=False"

conn.execute "insert into myTable (xtime) values ('" & now & "')"
conn.close
set conn = nothing
response.write now

%>

There is nothing else in the file. NOTHING. Just the code you see
here. No include files, no external function calls except the open
and execute methods of the connection, no javascript. Just what you
see here.

I've tried opening from Start >> Run >> http://myaddress/mytestfile.asp;
I've tried with "javascript: window.open('http://myaddress/
mytestfile.asp');" in the browser address line; I've tried the same
method from another webpage; I've opened a blank browser window and
typed in the address.

When I load the file in a new window, two records are created anywhere
from 1 to 15 seconds apart. It averages 5 seconds.

When I refresh the page, one record is created.

Open a window: two. Refresh: one.

I've tried different connection strings: SQLOLEDB, SQLOLEDB.1, ODBC.
I've added and removed parameters.

This happens in IE6. IE7, Firefox and Netscape do not have this
problem. Since this is a production app we have to write for multiple
browsers, meaning we can't tell people to not use IE6, much as we
would like to.

I've checked my logs, and found this:

2007-03-07 19:05:02 10.180.18.20 GET /templates/myTestFile.asp - 80 -
64.123.232.129 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT
+5.1;+SV1;+.NET+CLR+1.1.4322) 200 0 0

2007-03-07 19:05:04 10.180.18.20 GET /templates/myTestFile.asp - 80 -
64.123.232.129 Microsoft+URL+Control+-+6.00.8862 200 0 0

2007-03-07 19:06:00 10.180.18.20 GET /templates/myTestFile.asp - 80 -
64.123.232.129 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT
+5.1;+SV1;+.NET+CLR+1.1.4322) 200 0 0

2007-03-07 19:06:09 10.180.18.20 GET /templates/myTestFile.asp - 80 -
64.123.232.129 Microsoft+URL+Control+-+6.00.8862 200 0 0

2007-03-07 19:07:56 10.180.18.20 GET /templates/myTestFile.asp - 80 -
64.123.232.129 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT
+5.1;+SV1;+.NET+CLR+1.1.4322) 200 0 0

2007-03-07 19:08:01 10.180.18.20 GET /templates/myTestFile.asp - 80 -
64.123.232.129 Microsoft+URL+Control+-+6.00.8862 200 0 0

Note that each Microsoft URL Control entry is just a few seconds after
it's corresponding "Mozilla" entry.

Has anyone else encountered this and know a fix?

- Bill in KCMo

For posterity:

As of today, if you do a Google search on "Microsoft url control" (in
quotes) you will get approximately 79,300 results, of which 20 or so
are relevant. Not coincidentally, you will also get 20 different
opinions as to what it actually is.

Within the limited scope of searching I've got time to do from work
(pesky deadlines, dontcha know) no one really knows what it is, where
it came from, why it ate all the Cheetos, or when it's going home to
blog the experience.

1. it's a spambot looking for email scripts
2. it's an RIAA conspiracy, looking for MP3s
3. it's a leech looking for images
4. it's a rogue VB program that's become sentient

The most reasonable explanation I've heard is from
http://www.searchengineforums.com/apps/searchengine.forums/action::thread/forum::msn/thread::1104854988/,
and says:

<!-- begin cut -->
Microsoft URL Control is not connected in any way to Microsoft or its
search engine spiders, it is actually a "control" that allows programs
running on Windows to access the web.

Microsoft URL Control is used by many different types of programs,
some are nice and some are not. In many cases, it's an email address
sniffing bot, so you would want to probably ban the IP address it's
coming from, not necessarily the whole thing. I don't necessarily
think banning it in the robots.txt file would work.

The Microsoft search engine robot is called MSNbot.
<!-- end cut -->

That's fine as far as it goes, but lacks somewhat in specifics, as in,
say, how to deal with it. Another explanation suggests that the MUC
is actually the InetCtrl OCX that ships with Visual Basic - that would
make more sense to me since (in my office the four of us all have
similar configurations but only one of us creates the dual log
entries) the machine creating the dual entries is an IE6 machine, and
the IP address in the IIS logs indicates our office rather than some
third party.

Me? I think it's IE6, and just sloppy work on the part of Microsoft.
Not like there's no precedent THERE.

In our situation, where we generate our own customized logs through
our web engine, I fixed the issue with a check of the user agent,
issuing a "response.end" in the case of "microsoft url control". An
entry is still written to IIS logs, but the effect is negligible since
none of our clients use them for anything more than counting unique
visitors and filter our IP address.

I wish greatly there was a better explanation.