4

The internet access code in our product works perfectly for 99.99% of people. However, for a few of them, it just doesn't work at all. We've been adding some trace code to try and figure out what the problem is, and it it turns out that InternetOpenURL is reporting error 2 - "The system cannot find the file specified" - from this function call:

options = INTERNET_FLAG_RAW_DATA | INTERNET_FLAG_RESYNCHRONIZE;
handle = InternetOpenUrl(internet,url,NULL,0,options,0);

(internet is the handle to an internet connection opened with InternetOpen, url is the URL to a simple text file that exists on our web server.)

We test two different web sites, one http and one https, which are located in totally different places (different domains, servers hosted geographically apart) and they both give the same error for this one guy and a few others. 99% of people, including ourselves, can access them with no problems at all. Not only that, the people affected can access the same URLs without a problem in their web browsers.

What on earth could be going on here? :(

EDIT: By luck, we found out what was going wrong! It turns out that some people have the "Use a Proxy Server for your LAN" checkbox checked in their internet options, without actually specifying a proxy server. We were trying to use the non-existent proxy server details, and of course running into problems doing it.

I still need to investigate a programmatic solution for this, but everyone who reports the problem has their problem solved by this solution:

  1. Open Internet Explorer
  2. Go to 'Tools -> Internet Options'
  3. Click the 'Connections' tab.
  4. There should be a button labeled 'LAN Settings' near the bottom. Click it.
  5. Under the 'Proxy Server' field, uncheck 'Use a proxy server for your LAN'
  6. Click OK to everything, restart Windows, and try accessing internet through the product again.

I have no idea why so many people have the box checked but no proxy server specified. But apparently this is what needs to be done to fix it.

Colen
  • 13,428
  • 21
  • 78
  • 107
  • Have you tried sniffing the actual packets sent back and forth using something like wireshark? as this could reveal more than just the error you've gotten(such as some form of conversion or missing conversion, ie: ' ' to %20) – Necrolis Sep 23 '10 at 06:57
  • Unfortunately this happens on user machines that we have no access to, so we can't do any sort of debugging like that. :( – Colen Sep 23 '10 at 15:37

5 Answers5

2

The solution may be as simple as opening Internet Explorer. I never use the browser, but a windows update broke calls to InternetOpenUrl.

Opening IE will setup the options so that reading proxy information will work again. Note that this is important when using INTERNET_OPEN_TYPE_PRECONFIG in InternetOpen().

Initially I only saw problems when INTERNET_FLAG_RELOAD was set, but soon everything degraded so that plain vanilla connections failed too.

tl;dr Open IE so it can bless your system

deancutlet
  • 581
  • 6
  • 6
2

GetLastError() is probably not the best way to find out what went wrong. From the docs:

To determine why access to the service was denied, call InternetGetLastResponseInfo.

Hugh Allen
  • 6,509
  • 1
  • 34
  • 44
  • The InternetGetLastResponseInfo docs say that you should only call it when GetLastError returns ERROR_INTERNET_EXTENDED_ERROR, which isn't happening. Is that incorrect? – Colen Sep 23 '10 at 15:36
  • @Colen: that sounds like it applies to FTP URLs. Just try it anyway and see what you get! – Hugh Allen Sep 23 '10 at 16:35
2

Given this info, I would guess these users have a firewall (or some type of security software) that has hooked wininet and is interfering with your call. Alternatively, they may have malware infestation.

dyasta
  • 2,056
  • 17
  • 23
1

Are these users using a proxy? If they have a proxy set in IE, it is possible that information is being picked up and is causing your errors.

Also, I agree with Hugh. Sometimes GetLastError() can be misleading. If you want to use this, you should make sure that you SetLastError(0) before you make your call otherwise you could be getting an error code set by some previous method call.

Mike
  • 3,462
  • 22
  • 25
  • We're already calling SetLastError(0) first, but thanks for the tip. The users say they do not have proxies set up - that was actually one of the things we checked, since a similar problem was caused by a user having "use proxy" checked but no actual proxy specified. – Colen Sep 23 '10 at 16:09
  • Do you see any information in the server logs for this request? Maybe the requests are making it to the server and the server is sending these users some bad/unexpected response? Essentially, Are we sure that this is a client problem and not a server problem? – Mike Sep 25 '10 at 13:35
1

Try something like the following:

On error, hook SetLastError function (manually by using hot-patch, or by using MS Detours or something other), and call InternetOpenUrl again.

In hooking function, if SetLastError argument in't zero, make a minidump. You will get a place where that error is set.

Abyx
  • 12,345
  • 5
  • 44
  • 76