views:

1267

answers:

1

I kept recieving error 12029 (ERROR INTERNET CANNOT CONNECT, The attempt to connect to the server failed.) when using the the MFC wininet classes on Windows Vista. The cause of the error was due to Windows Defender. Is there a better way to get around this than completely turning off Windows Defender? I tried turning off "real time protection" to no avail, I had to completely turn WD off to stop the 12029 errors.

If there is no better solution hopefully someone else with the same issue will see this question and be able to fix thier own problem. I searched the intertubes high and low and didn't find any crossreferences between wininet error 12029 and WD.

My code for reference

::CInternetSession session;
::CHttpConnection* connection = session.GetHttpConnection(L"twitter.com",80,m_csUserName,m_csPassword);   
::CHttpFile* httpfile = connection->OpenRequest(CHttpConnection::HTTP_VERB_GET,L"/account/verify_credentials.xml");       
httpfile->SendRequest();
+1  A: 

If Windows Defender displays a warning message after blocking your program, you should have the option to add your program to a list of "allowed items" which will allow it to run unencumbered while real time protection remains enabled. Admittedly, this is only a viable option if you are working with non-production/personal code (and if Defender is even displaying a warning message at all).

That said, it is possible that Defender has detected some possible risk based on the way you are using the wininet library -- would it be possible to use lower-level sockets instead? If this is the only network code you use, it would be easy to replicate it through the generic winsock library and there's a good chance that Defender would be much less inclined to block your program if you use it instead of wininet.


Edit: In addition to testing the MFC fragment separately as I suggested in the comments below, it may be worthwhile to try it the standard WinAPI way -- the idea being, if there's something wrong with the wininet library on your computer, this code should also fail to connect:

int read = 0;
char* str = "*/*", buff[1024] = {};
HINTERNET inet = InternetOpen("GRB", INTERNET_OPEN_TYPE_DIRECT, NULL, NULL, 0);
if (!(inet=InternetConnect(inet, "twitter.com", 80, "username", "password", INTERNET_SERVICE_HTTP, 0, 0))) 
 cout << "conn failed" << endl;
if (!(inet=HttpOpenRequest(inet, "GET", "/account/verify_credentials.xml", NULL, NULL, (const char**)&str, 0, 0))) 
 cout << "open failed" << endl;
if (!HttpSendRequest(inet, NULL, 0, NULL, 0)) 
 cout << "send failed" << endl;
InternetReadFile(inet, buff, 1023, (DWORD*)&read);
cout << buff << endl;
system("pause");

(designed to be a console program, be sure to include the correct headers/libraries)

GRB
I guess I should have realized that maybe WD wasnt problem because I did not recieve a warning that WD had blocked anything. (see comment on orignal question) Do you know of anything besides WD and Windows Firewall that could be blocking this? Thanks for your great response.
JohnG
Unless you have some antivirus program running then I doubt anything else could be interfering with your program. Knowing that, my guess is that the problem may be on Twitter's end and that their server is failing to respond within the timeout. A way to check this could be to loop some wininet InternetCheckConnection calls in a small console app and see how many times the connection to twitter fails. I tried doing this myself with ICC and the connection failed a couple times, with some coming very close to the timeout, as opposed to calling ICC on google.com which never failed.
GRB
Another reason why I think this is likely is that twitter has been the victim of some DDOS attacks recently, so it's possible that they are still going on or that the servers are still recovering from the additional load.
GRB
So I tried google.com with no success. I created a short console app that connects everytime with twitter, with no problem. I also tried increasing the timeout in my GUI app with CInternetSession::SetOption with no luck. I uninstalled McAfee the day I got the PC (1 year ago) so Windows Defender and Windows Firewall are the only suspect apps and I turned them both off. I am completely lost on this one. I thought about the DDOS but I get the error almost immediately, I would think some time would go by if the twitter servers we being crushed.
JohnG
Its so strange the the console app works but the GUI app doesnt.
JohnG
That is strange (make sure though that for the URL you use in ICC, you use the full twitter.com/accounts/verify_credentials.xml URL -- I got better results with just twitter.com). The next thing I would try is taking literally just the code fragment you have there and inserting it into a blank MFC project, to see if you get different results.
GRB
So I took your code above and compiled and ran it. (thanks for providing it) The InternetOpen call works but InternectConnect bombs out. (I get "conn fail" in the console) I then copied my original code into a blank MFC project and it ran fine. wow, just...wow. I have no idea why I get such inconsistent results.
JohnG
Hmm, well at least we know your code is fine, but the inconsistency between cases makes it hard for me to believe something along the way is blocking the connection (the on/off nature doesn't make sense in terms of a program like WD blocking it, and it's nearly impossible a firewall would block traffic on port 80). This makes me want to go back to the idea that it's on their end. Here's a question: when you do these tests, are you sending a real twitter username/password? If so, try it using fake data (e.g. "username" and "password" like in my code) and see if that changes anything.
GRB
Thanks for sticking with me. I would vote up your answer but I can't (not enough rep, as an aside, I seem to be at a wall with rep) So, I checked out the twitter dev group, it seems they are still working on the DDOS. I have been using my real credentials, so I took your suggestion and used fakes. No luck. I am using this code in a thread started with AfxBeginThread. I use the primary thread's security attributes (pass NULL) so I don't think security is the problem, but perhaps this creates an issue? The code works in the primary thread of the blank MFC project I copy and pasted it into.
JohnG
In that case I doubt it's their end anymore. I suggested the fakes only because legit information may require more processing on their end and heighten the chance of a timeout (I don't have a twitter acct so I couldn't test this). As for being in a secondary thread, the code would still *sometimes* connect, right? I mean there was a time where it was working (when you thought the prob was WD), which suggests that it couldn't be a security issue (you would never have been allowed to connect if there were such an issue). Have you tried the code fragment in the main thread of the original prog?
GRB
The code did work about 3 times one evening, but since then nothing. (this caused me to erroneously think turning off WD fixed it) I have just tried the code in the primary thread of the original program and it works only when I run the app as Adminstrator. It still fails when I run the code in the secondary thread even if I run the app as Adminstrator. I wonder if there are some compiler options that must be enabled to allow the app network access? I am going to work on this over the weekend. All ideas are appreciated.
JohnG
I highly doubt that compiler options are having an impact on your code, but at the same time I'm currently out of ideas. I'll keep following this answer and think things over, but for now I have nothing more to suggest.
GRB
So I have been thinking about this. I think the issue may be security related. Specifically I think there is a problem with the access token that the application recieves when launched. I turned off UAC (no change). I think its security related due to the fact that the code works in the primary thread when it is run as Adminstrator. So I think network access requires elevated permissions. Some how when a new thread is created this permission is not being passed on. This could explain what I have seen so far. Researching....
JohnG
Just tried creating the CInternetSession object in the primary thread and then using it in the secondary thread. No luck.
JohnG
Just tried changing the DACL of the underlying kernel object wrapped by CHttpFile* httpfile. I used SetSecurityInfo, but the function fails when called like this:::SetSecurityInfo((HANDLE)httpfile,SE_KERNEL_OBJECT,DACL_SECURITY_INFORMATION,NULL,NULL,NULL,NULL);The function returns 6 (invalid handle). Research continues...
JohnG
Success!!! maybe! The code just worked! In the secondary thread without running as Admistrator! I went in to IE > Tools > Internet Options > Lan Settings and unchecked "automatically detect settings". Fix found at http://www.daniweb.com/forums/thread64271.html. Hopefully this will continue to work!
JohnG
haha, great to hear! Looks like I was totally barking up the wrong tree, good to hear you solved the problem though.
GRB