FtpOpenFile and InternetWriteFile broken/changed in IE11 - by MichaelTDN

Status : 


ID 808279 Comments
Status Active Workarounds
Type Bug Repros 60
Opened 11/11/2013 1:33:04 PM
Duplicates 809080 809393 809734 810760 810781 810970 813479 Access Restriction Public


I have existing code in which FtpOpenFile and InternetWriteFile worked in IE9 and IE10 but is broken in IE11.

Under Windows 8.1 InternetWriteFile() appears to work correctly, but after the file transfer is completed (no error messages), the file on the FTP server is too small. Running the same code on Windows 8 (with IE10), Windows 7, & Windows XP works properly. The file is sent in chunks via multiple calls to InternetWriteFile(), which always returns successfully.

Under Windows 8.1 FtpOpenFile appears to work for an upload, but subsequent calls to FtpOpenFile on the same session handle return NULL (GetLastError() returns 12003, InternetGetLastResponseInfo() then returns some FTP status messages). The same code works fine under Windows 8.
Sign in to post a comment.
Posted by TrooperKal on 7/27/2015 at 8:18 AM
Is anyone aware if Windows 10 will be fixing this problem?
Posted by xNuno on 6/9/2015 at 10:56 AM
I have upgrade this week 400+ machines to IE11 and now users are unable to use Windows Explorer to browse ftp servers...when they try to open any file they got IE11 with broken link...checked IE temp folder and all files have 0 bytes...

Any solution for this!?
Posted by Erik Jacobsen on 2/23/2015 at 1:03 PM
I can reproduce this problem as well. The update rollup package was already installed on our systems and we are still getting only partial transfers from InternetWriteFile. Please fix.
Posted by merrifie on 12/4/2014 at 4:09 PM
I have been using CInternetSession::GetFtpConnection() with default arguments for port, etc. All the information on this problem suggest making sure the connection uses active mode which is the default. After other suggested workarounds failed, I tried explicitly setting the passive flag. It turns out that passive mode works while active mode generates a 12003 error when using PutFile.
Posted by Mikey Matteo on 11/30/2014 at 2:06 PM
This is ridiculous. I have 10+ customers that cannot upload products and graphics to their websites. not to mention the countless projects that I cannot continue working on because I cannot upload files. I am forced to have this update as IE11 cannot be downgraded on windows 8.1 / Server 2012r2. This needs resolving now! I shouldn't have to install another FTP server along side JUST so I can do my uploads. then this wouldn't fix the issue for my customers as they rely on Plesk which only uses the windows FTP...

Common Microsoft, pull your finger out of your behind!
Posted by merrifie on 11/18/2014 at 3:51 PM
No, the (win7 hotfix) update related to KB2996207 did not work. Still getting error number 12003.
Posted by Bala Natarajan MSFT on 11/11/2014 at 11:24 AM
The fix was released in October 2014 windows Roll Up (KB2995387).

released for 8.1 and 7, documented here:




This talks about Network printers that use TCP/IP port cannot print after first document has printed in Windows issue . But the root cause is client computer does not send a FIN packet to the print server after the first print job is finished. This root cause is also same as the FTP issue in IE . But it is fixed . So please install the October Update and let us know

Posted by merrifie on 11/6/2014 at 1:36 PM
Just ran into this problem as well. Grateful for this content so I can quickly diagnose the problem. However, it seems appalling that nothing has been done to provide a solution.
Posted by Brian RB on 7/9/2014 at 7:25 PM
Can I ask how this has been a confirmed issue since November of last year, and yet we are all still sitting here waiting for a fix? This is a huge problem Microsoft. It puts a lot of us developers in a really bad spot, both in ease of our development, and in interactions with our clients who don't understand this is your issue and not ours. Come on!?!?!?
Posted by Gary Braden on 6/11/2014 at 6:33 PM
I have written a program in MS Visual Basic which uses MSINET.OCX to download updated information to users of this program. This has worked for years. All of a sudden, as people get new computers with Windows 8.1, the download is apparently getting corrupted making the program useless. When they sign on to the FTP section of my web site with IE to download the files, they are also getting corrupt versions. I have over 1000 users of the program, and I have to individually email them the files now to update them, which is a real pain as the number of 8.1 computers increases. I also have one Windows 7 user having the problem, but they probably have IE 11 installed. Is this bug being addressed, and will it ever be corrected?
Posted by usonianhorizon on 6/1/2014 at 1:20 PM
I am continuing to experience problems that might be related to this. Two of our vendors, Lutron and URC, use ftp to upload system programming to their processors. Both have released patches that purport to fix the problem but with both we sometimes have success and sometimes we don't. It seems to be dependent on the complexity of the network. Basic SOHO setups with a single subnet work fine, at least with these two vendors' software. Layer 3 networks with tagged VLANs seem to fail, albeit inconsistently.

My question is whether it might be possible to use an XP instance under Hyper-V to test whether the issue continues to be related to the IE11 installation? Or would the XP instance still use the underlying Windows 8.1 networking calls and hence would still fail with ftp?

Posted by Noraa2 on 5/28/2014 at 9:41 PM
Hi Eric,
I'm experiencing the issue also. We have the latest cumulative security update for Internet Explorer and have tried disabling anti-virus (NOD32) and the firewall (Windows firewall). Please help.
We using Windows 8.1. Trying to upload a file via FTP results in a 0KB file with the same file name being created on the FTP server. This happens whether we are performing the FTP upload via our own programs or via IE11.
Posted by Rknol456 on 5/24/2014 at 3:24 AM
Has anyone tried the suggested uninstall and re install of AVG? Struggling to understand how we have now nearly got to the end of May and still no fix from MS. How about making available an uninstaller of IE 11 for windows 8.1
Posted by snh2014 on 5/23/2014 at 6:54 AM
Please can MS start doing something about this

Had this error since 2013 - have sent numerous emails to our FTP supplier - only to find ouot this is MS

Posted by Top Notcher on 5/9/2014 at 10:56 AM
I can confirm this is not working again in the file dated 3/18/2014.     Directory listings also stopped working......
Posted by Kevin Perkin on 5/7/2014 at 2:18 AM
I have this issue with FtpGetFile but only when I'm retrieving text files. I can get images and application files without a problem. I'm compiling the application under Windows 7.

This is causing my colleagues and myself some considerable inconvenience so a speedy resolution would be greatly appreciated.
Posted by John-Developer on 5/5/2014 at 7:11 AM
I have this issue also. I use dreamweaver from Office PC and From home. I have Win8.1 on both with all the latest updates . Office PC works fine, Home is having the issue. When i first had the issue I was using AVG. Removing AVG and installing Avast worked UNTIL the latest update, Now even removing Avast and having no AV in play, I have the issue again.

Please fix!

Posted by ZanByte on 4/13/2014 at 1:27 PM
I dont know how, but I had this issue when I was working at another location. When I got home, there are no problems at all. Does anyone know what external influences could be at play here?
Posted by DeveloperB on 4/13/2014 at 5:50 AM
I am having problems uploading via FTP with windows 8.1, constant timeouts, basically making my home computer useless for working on.

My ftp client is Filezilla and I am running AVG 2013. Disabling my anti virus every time I want to upload doesn't seem like a viable solution.

Any update on a fix would be helpful.
Posted by Aaron Jay Lev on 4/2/2014 at 1:47 AM
I can't use my computer to work on ftp file in any program. Since I do this for a living, I've been forced to use a mac instead.
Posted by mharpen on 3/31/2014 at 11:07 AM
I can confirm that the issue with uploading chunks of data (using FtpOpenFile and InternetWriteFile) is now working again. Thank you!!

However, there seems to be a new issue now with sending the full file (not in chunks) using FtpPutFile(). I have verified that this issue seems to be related to only when AVG antivirus is activated. I'm on win8.1, have wininet.dll version: 11.00.9600.16521, and up to date AVG vsn: 2014.0.4354

I have verified this issue over and over with code that does the following:

1) create a dummy test.txt local file with 59,000 characters in it.
2) make sure AVG anti-virus is activated.
3) in a code loop: upload the test.txt file 15 times using FtpPutFile()
4) after each upload, use FtpFindFirstFile() and check the file size against the local file size.
5) on average, 3 out of 15 times, the file size on the remote server will only be 54904 bytes (not 59000 bytes).

No error is returned when the file is uploaded partially. Obviously, this can cause havoc for applications that upload files to their websites (malformed: xml files, script files, html pages, etc).

Also, It doesn't seem to just cut off the file at the end. Chunks from the middle of the file are getting dropped.

In my case, many of my applications were converted to use FtpPutFile() after the bug was discovered in the previous wininet.dll version that returned 12003 errors. So for the meantime, it looks like we'll have to switch back to using InternetWriteFile(), since FtpPutFile() has a bug if AVG is being used.

I've verified that FtpPutFile() works when MalwareBytes AV software is activated only. I have not tried it with Norton, Mcaffee or others.

Posted by HolgerRudolph on 3/17/2014 at 5:18 AM
Hi Eric!

Thanks for taking care of the problem. I postet some comments here already. After the fix the whole thing iumproved but isn't gone. Especially when I use Dreamweaver CS6. Right now I follow your suggestion to turn off the antivirus software (AVG 2014). So far it worked in the last two days. If the problem comes up again. I drop a note here.

Posted by EricLoe on 3/13/2014 at 5:46 PM
Hi Paul,

No there are no known issues which are side effects of KB2909921. What I am saying is that the issue fixed by KB2909921 masked the underlying antivirus/firewall interaction since the FTP communication never reached the point where it should complete. The main clue to this is that it turns out several apps which were experiencing the same issue, and as Travis pointed out WinSock and WinINet mode were both having the problem, whether or not they used WinINet for FTP.

Right now the investigation for the antivirus/firewall issue is still ongoing and I don't know what the permanent fix will be or when it will be available.

Posted by Paul Baker on 3/13/2014 at 5:50 AM
Eric, I would appreciate some clarity on something here. Have you found any problems with people who have applied KB2909921 that are side effects/new behaviour with this change? This would include behaviour that triggered firewall/antivirus/etc. behaviour that was not triggered before (false positive, I suppose). Or, are you just essentially providing support for firewalls, antivirus, etc. at this point? Those things always have the potential to cause problems. Or, is it unknown/under investigation? With all the comments here, I can't tell if there is a problem list that is growing, or a single problem that is fixed and merely a support issue. If I am not explaining this clearly enough, please email me. And, as a developer myself, I have to say that you are brave to step forward when noone else did :)
Posted by Pynchros on 3/8/2014 at 8:44 AM
Thanks, EricLoe. I omitted to say that I have no Antivirus or Firewall active on the local machine. There is a hardware firewall on the remote server. I also have KB2909921 to no effect.
Posted by EricLoe on 3/6/2014 at 12:11 PM
Hi Pynchros,

Please see my comment below yours.


"Currently the best work around I have for you is to disable your third party Antivirus/Firewall while executing FTP upload operations. If this does not help your situation please reply to this thread."
Posted by Pynchros on 3/6/2014 at 11:51 AM
Since 8.1 upgrade Adobe Dreamweaver CC's FTP client experiences 2-3 minute delays while it is "waiting for the server". Connections drop in FileZilla as though it missed some part of the server's acknowledgement. Additionally, any desktop tool I use to access a remote MySQL database loses the connection. A simple change to a value in a database field can take 2-8 minutes while the software goes through a series of lost connection/re-connection loops. I can confirm that the same software (FileZilla, Dreamweaver, Toad for MySQL and SQL Maestro for MySQL) functions without these issues on Windows 7. My high-powered notebook has been reduced to a major productivity drag. If we can't downgrade either Windows or IE what workarounds can I try to avoid completely re-building my machine?
Posted by EricLoe on 3/5/2014 at 1:00 PM

We narrowed down the root cause in several users cases to an interaction between Windows and the Antivirus/Firewall software installed. We are actively investigating solutions in the product to resolve this issue, but I cannot comment on the time frame or version for which a fix will be available.

Note that KB2909921 is required to be installed as part of fixing this issue as it fixes the original issue reported in this connect.

Currently the best work around I have for you is to disable your third party Antivirus/Firewall while executing FTP upload operations. If this does not help your situation please reply to this thread.

It would also be helpful for you to reply with the Antivirus/Firewall you are using so we can test against those while developing a fix.

If this workaround still does not fix the issue, please reply to this thread.

Posted by Bjørn Omsland on 3/5/2014 at 3:32 AM
Hi Eric,

don't forget me. Ftp-upload from Visual Studio still don't work and I have not received any e-mail from you.

Posted by Travis_J on 3/4/2014 at 11:11 AM
Since I feel like I've been one of the more vocal here on this topic about this issue, I just wanted to post on this again, in case other people who were, like me, *still* having problems with publishing, even after downloading Microsoft's newest Windows Update, its fix, for Windows 8.1 , for utilizing FTP in Web-Design, or in whatever capacity people are trying to use FTP and may be having issues.

I was still having issues, too, even after that new Windows Update, but here on this topic on this page, EricLoe is able to help individual users come up with workarounds to the problem. He helped me come up with a workaround that did NOT involve my doing any changing of any system files in Windows, I didn't rollback/uninstall/reinstall anything; didn't buy any new software, didn't buy a new machine--nothing like that. They helped me see how I could disable a certain thing on my machine, and then my project files publish perfectly fine, and things are working well.

So if you're still having issues publishing/FTP file-transferring/desktop-publishing or whatnot, EricLoe is able to look at your situation on your machine and help you.

Just passing along my experience in hopes it may help my fellow web-designers and Microsoft enthusiasts.

--Travis J, MBA
Posted by EricLoe on 2/27/2014 at 11:17 AM

I sent an email to the email address associated with your user handle. If you can please check that account I would like to work with you to determine what is still going wrong with this scenario.

Posted by RTIS1 on 2/27/2014 at 8:26 AM
Same problem here - KB2909921 did not fix the issue.
Our firm uses Dreamweaver CS6 and we are finding that when we try to save any file over 20Kb to a remote server via FTP, we are unable to do so. The program will try to save the file and upload only a portion of it before it stalls. If we stop the process and try again eventually it will work, but it is after 10 - 20 times.

Just to get this off my chest - Windows 8 seems like a complete nightmare of an OS (and 8.1 is now even worse). The fact that this issue still exists after months is completely unacceptable. Our firm is now developing a plan to abandon windows 8 and revert back to windows 7 or move to the Mac platform.
Posted by Bjørn Omsland on 2/26/2014 at 12:49 AM

I still have problems uploading files from Visual Studio Express 2012 to the ftp-server. Small files are ok. Larger files fails.
KB2909921 did not fix the problem.

Posted by Angelique2014 on 2/25/2014 at 9:55 AM
Hello Eric, and others.

I'm not too technical, but I have all the latest updates installed (IE11 and Win 8.1) -including KB2909921 on Feb 14th- and I STILL have been dealing with this shit all day working from home (I'm a web developer).
IT"S STILL NOT WORKING! FTP is hardly connecting. If I see FTP notifying 'Waiting for server...' one more time when I want to upload I might blow out my voice screaming.

I use Adobe Dreamweaver CS6 and I've been frustrated all day as I do have a deadline at work. This has been ongoing for half a year (!!!!) now and working from home 1 day a week has been hell because of this (at work we use Macs). And you don't even offer the opputunity to roll back to version 8 or IE10 or whatever! How is this professional or respectful of us paying customers?

[ Browsers also have loading problems loading a lot of times, sites hang while loading on all sorts of scripts it seems. Stopping it from loading and hitting refresh usually helps and the site will load normally after that or after several tries, seems random. My network settings are fine, my pc is new, I have glass fiber 100mbit internet (Holland). Problems started directly after upgrade of Windows 8.1 was finished installing. ]

FIX THIS SHIT!!! Please. Thank you.
Posted by SergioElFlaco on 2/25/2014 at 8:19 AM

KB2909921 doesn't fix the issue in every case.
In my particular case, it make it worse.
I have W7 installed, and when the IE11 was installed, it broken my FTP app transfer.
I uninstalled IE11 back to IE10, and everything went back to normal.

This morning, when my customers began to download zip files from my FTP server, called me claiming that my app stopped working.
After further investigation, I learn that some of the zip archives uploaded to my FTP server were just corrupted.
I came here to see what's new, and found out the KB2909921 update.

In my case, KB2909921 was applied last february 14, (I don't know why IE11 was not installed this time ...).
Consistently, all the zip files uploaded since last february 14 are corrupted.

I tried to do a clean upload of the corrupted files, deleting it from the FPT server first, but the zip files ended corrupted again.

I uninstalled KB2909921, and now the zip files are uploaded correctly.

I hope you fix this issue ASAP.

Posted by EricLoe on 2/24/2014 at 1:08 PM

My name is Eric and I am a developer on the WinINet team at Microsoft. I apologize that this issue has been causing some headaches for you, but I am glad to see that for many of you this issue is resolved with KB2909921. However I do see that some of you are still having issues. I have reached out to those who have already posted that they are having issues. If you continue to have issues using FTP in Windows 8.1 after applying KB2909921, please leave a note here and I will follow up with you via email.

Posted by LHarding on 2/17/2014 at 1:18 PM
Our testing after the applied cumulative update KB2909921 shows that these FTP issue have been corrected. Our users are also reporting that the problem no longer occurs. Thanks Microsoft. I'm just very disappointed that it took this long to correct.
Posted by Paul Baker on 2/17/2014 at 9:55 AM
Travis_J and HolgerRudolph: Interesting that you both sometimes see it waiting for the server. This kind of sounds like they overcompensated for the previous behaviour of essentially failing to wait for the server. However, if the server is behaving correctly, something is wrong here.

Graham F: Glad it works for you with vsftpd.

I said I would test this on Monday (today), but I decided I will not. We were left with little choice but to workaround the problem - our workaround is permanent, so we are no longer affected. Microsoft did not document that KB 2925463 resolves this bug. Finally, users indicate that the fix does not work ("sometimes works" is the same thing as does not work). So I really have no motivation to look at this fix that is compatible with business needs.
Posted by Graham F on 2/17/2014 at 9:42 AM
I have tested KB2925463 as part of the cumulative security update KB2909921 with IE11 on Windows 7 and with Windows 8.1 using both passive and active mode FTP and the problems I had previously seen using WinINet via MFC are resolved by the update. In case it is relevant, the FTP server used for testing was vsftpd.
Posted by HolgerRudolph on 2/16/2014 at 1:38 PM

I can confirm that the problem still exists but it has improved. I'm able to upload much more files than befor. But the problem "Waiting for server..." comes up again and the files are not entirely uploaded or not uploaded at all. I tested the whole thing with Dreamweaver and FileZilla.
So MS has to take care of that again. It's important, cause it has an impact on my work as webdesigner...
Posted by Paul Baker on 2/16/2014 at 9:32 AM
Okay, Travis. Can anyone else confirm or deny that KB 2925463 solves the problem entirely for them?
Posted by Travis_J on 2/15/2014 at 3:42 PM

Thank you for your response; but I mean, while that's right, that "Winsock" bypasses "Wininet" entirely--that's true. Understood. However, that's only *that* part of it. My primary point was that Wininet, in fact, *still* is *not* 100% for me, like it used to be with this web-publishing/file-uploading software that I use. And the thing is, it is not my project files that are the issue, or the web-servers onto which I am publishing/file-uploading that are the issue, because I have now had to move these exact same project files to another machine in order to work on them and publish to the corresponding web-servers, and they publish to the same web-servers just fine, from my other machine to where I moved them (because on that other machine where my publishes/file-uploads *WORK* with my software, I did not do an upgrade to Windows 8.1 on that other machine last year and did not have to go through this problem about which we're all talking, here in this thread, with Windows 8.1/IE11/Wininet/etc.). So my web-servers and software aren't the issue--they're working just fine from another machine.

So, yeah, I'm just hoping Microsoft isn't marking this "resolved" because it still is *not* resolved on my primary system where everything was working *perfectly* before this Windows 8.1 upgrade last year that disrupted everything. It is *not* 100% resolved.
Posted by Paul Baker on 2/15/2014 at 9:36 AM
Travis, I believe "winsock" mode in WYSIWYG Web Builder bypasses WinInet entirely. If you're having problems with "winsock" mode, most likely it is a network problem and not the software.
Posted by Paul Baker on 2/15/2014 at 9:33 AM
If will try this on Monday. If KB 2925463 is supposed to fix this, someone from Microsoft should say so here. I commented to that effect on the KB article.
Posted by Travis_J on 2/14/2014 at 10:10 AM
Posted by Travis_J on 2/14/2014 at 10:09 AM
It's weird for me--the update "Sort of" worked for me. But no, the issue is not resolved and I am hoping Microsoft is not treating it as resolved. Since I sintalled this newest Update 2909921, now the piece of software that I use to publish my web-projects *SOMETIMES* successfully finishes it's "Publish" process/file-upload process, and sometimes still FAILS in its "Publish" process/file-upload process. My software allows me to either use the "wininet" or "winsock" protocol for FTP file-transfer. And with both modes, with the way my system is sitting right now, here on February 14, 2014 and with this newest update Microsoft released that should supposedly fix this issue, which is Update 2909921, it did not seem to completely solve the issue for me, no. Sometimes my Publish process/file-upload process just quits because it gets hung on some .PNG image file it is trying to upload. It is not always the same file on which it gets hung, either--it seems to be a different file on which it gets hung up, each time.

But it does finish a Publish/file-upload process *sometimes*. So it's like, "Improved but not fixed" for me. And I am hoping Microsoft isn't treating it as "Fixed" or "Resolved", because it is not for me.

By the way, the piece of software I am using/about which I am talking is this one: https://connect.microsoft.com/IE/feedback/details/809080/problem-with-ftp-wininet-after-installing-ie11 ; the piece of software is called "WYSIWYG Web Builder", which has worked wonderfully and error-free for years and years.
Posted by RTIS1 on 2/14/2014 at 6:36 AM
RE: http://support.microsoft.com/kb/2925463 - Update 2909921 did not work for me, the problem still exists. Anyone else have any luck with it?
Posted by WitteWim on 2/13/2014 at 9:40 AM
see http://support.microsoft.com/kb/2925463.
Posted by Luiz Felipe Stangarlin on 2/10/2014 at 4:15 PM
I had this problem the previous month and my client was waiting too much time, I needed to solve it.
The way I solved it was by copying an old version of the wininet.dll that I have found on the SxS folder to SysWow64 with the name WinInet8 (it was the oldest version I've found).
Then I changed my code to load "wininet8.dll" instead of "wininet.dll", worked just great. But you need to use LoadLibrary to make it work, if you use static linking, then I don't know if it will work, perhaps with some hacking on the linking, but whatever.
I hope this helps someone.

Luiz Stangarlin
Expert Informatica
Posted by HolgerRudolph on 2/7/2014 at 11:08 AM
I experience the same problem after updating from Windows 8 to 8.1. I'm working with Dreamweaver CS6 and the FTP upload process doesn't work properly which causes much problems in my work flow being a webdesigner. Other FTP clients are affected too. The bug should be fixed quickly!! Why does that take so long?
Posted by HFSNETMaps on 2/6/2014 at 12:53 PM
Mr. Microsoft,

WHEN WILL THIS BUG BE FIXED? We are working with Software that uses a former reliable wininet.dll that is now BROKEN!
We are losing lots of productivity because any Workaround costs lot of time AND MY MONEY.
WHAT IS THE PROBLEM that you are NOT FIXING this bug?

Posted by WiWo on 2/6/2014 at 4:33 AM
I have the same problem with the communication between cash points and back office systems. The cash point program is written in VFP and uses WININET.DLL. For data exchange it is using a kind of protocol in a single FTP session; this code worked for almost 12 years.
Currently only a few customers are involved by the WININET-issue, because most of the systems are still Windows XP. I planned to make a big upgrade campaign this year, but now I had to stop that. On Win7/8 systems de-installation of IE11 worked in all cases, but I cannot be sure for the future.
I made also some tests with Visual Studio. FTP transfers based on WININET are involved too. Using Net.FtpWebRequest is not an alternative, because it does only one operation per session. I tried also a library based on socket operations (with FTP command language); it works fine for this topic, but to write something like this for VFP would cost me too much time. I assume, the pressure on Microsoft is not so big, because most complex applications are using such socket based operations instead of WININET.

Posted by Lucasw1 on 2/6/2014 at 2:49 AM
Also having the same issue like everyone else has, this is critical to my job, as I cant work at all right now. How come this cannot be fixed for over 4 months?
Will Microsoft pay my salary during this because I'm in no use for my company when the situation are what it is
Posted by Flam3r on 2/5/2014 at 6:44 AM
I'm having the same issues. After upgrading from Windows 8 to 8.1 (with the so much forced in my face upgrade) i started getting issues.

I'm using Adobe Dreamweaver CS 5.5 and the FTP upload doesn't work. I tried FileZilla and CuteFTP, both give me issues. The same settings and options work on other computers with different operating systems.

Some of the files seem to pass and then every other file will not. It doesn't work at all if you try to upload a multitude of files at the same time as well.

This is impacting my work MASSIVELY! I work with FTP every single day. I'm considering throwing this OS and getting another one. MS fix this problem and MAKE QUALITY SOFTWARE for once!
Posted by chacke2 on 2/5/2014 at 6:41 AM
So it should be clear now that this is a bug
Why isn't this fixed yet !!!
Why does this have to take more than 4 months ?
Posted by Paul Baker on 2/2/2014 at 8:44 AM
To clarify, the problem acknowledged by Microsoft as a bug with FtpOpenFile/InternetWriteFile is nothing to do with exposing a problem with the server. This is entirely a WinInet problem.
Posted by Paul Baker on 2/2/2014 at 8:43 AM
The problem that is acknowledged as a bug by Microsoft is as described in early comments with FtpOpenFile/InternetWriteFile. However, there is other evidence that suggests that it is part of a more widespread problem related to the command-response flow affecting other commands. Microsoft may be taking time to understand the bigger picture. However, they should be able to look at what the changes were in IE 11 to help with that.
Posted by GizmoBowler on 1/31/2014 at 8:50 AM
Is this a problem with the latest FtpOpenFile/InternetWriteFile not working correctly (as per the RFC) or was the previous version covering up an issue with servers returning an extra response and now it doesn't?

Along the same lines, is there an argument in the InternetWriteFile call that is defaulting to sending a single "chunk" rather than the entire file causing a premature completion?

I just find it hard to believe that an issue with this impact is taking so long to resolve or even get an "official" response on.

I have been designing process systems for over 30 years and realise that sometimes a bandaid is required to "get it working" but eventually the bandaid needs to be removed. Is this that time?
Posted by Top Notcher on 1/29/2014 at 7:25 AM
Deleting files via FTP using WININET appears also to be broken now. PLEASE MS fix this!
Posted by CrowDogsDamnIt on 1/28/2014 at 3:35 PM
I uninstalled IE 11 via "Turn Windows Features On or Off" and have been able to upload/download within Dreamweaver and FileZilla.
Posted by Bjørn Omsland on 1/27/2014 at 3:04 AM
I have the same problem when uploading files from Visual Studio 2012. The problem started after upgrade to Windows 8.1. Microsoft: Do you know if it will take days or months to fix this?
Posted by chris_long2 on 1/26/2014 at 9:21 PM
Karen1961: WYSIWYG may have released an update to workaround this bug, but they didn't "fix" this bug. This bug is a major problem in IE11 (which means all Win 8.1 users among others) and has NOT yet been fixed by Microsoft. WYSIWYG is only one of probably hundreds of programs that work with FTP that are affected by this bug. Microsoft needs to get this one fixed NOW.
Posted by Bembi22 on 1/26/2014 at 2:08 AM
I'm really wondering, that only a few prgrammers found this threat, we have the same problem and it affect several hundred users with different OS on their computers.
But if I count the programmers here and multiplicate them with all of their customers, several thousand may come together.

For us, it is currently a gigantic effort to work around this issue, because our users are nativ comupter users which rely on windows updates, but do not really know
how to help themselves. They just recognize the non working programs and don't know what to do. Even uninstalling some Updates is not really an option as not all of them are
aware how to do it. And because they even don't know for what to search in the internet, they will now find this page to confirm the error.

So the only thing what we can do is to warn our users to use IE11 or Win 8.1 not to run into additional desasters, when users installing updates.
Posted by Zardos11 on 1/25/2014 at 4:48 AM
Why Fix it take so long? The problem is very serious, they should increase the priority!
I wait and wait ...
Posted by Karen1961 on 1/24/2014 at 2:47 PM
I had the same problem using WYSIWYG website builder and I am using Chrome. I had to buy a newer version of WYSIWYG with an update that fixed this bug. Everything is working fine now.
Posted by leocard56 on 1/22/2014 at 7:49 AM
I think it's fair to release a beta fix immediately within 24 hours then take all the time you want for a version of IE12.
tank you
Posted by chris_long2 on 1/21/2014 at 9:09 AM
It's nice to see that Microsoft is working on this, but I'll be honest: Microsoft, there is NO excuse for the delay in fixing this. You basically broke a major Internet protocol (FTP) for ALL Windows 8.1 users as well as any Windows 7/other users that download IE11. This issue was posted almost 2 months ago, and I have seen reports from even a lot earlier. This should have been a major priority fix for you to rush out the door via an Automatic Update, but it seems like you are taking your good old sweet time on it. Do you not understand the importance of this fix - the seriousness of this issue?? There are two really disconcerting things about this issue: (1) That such a major problem could even be released and not be caught or remedied during beta, (2) That once released, you haven't apparently taken it very seriously. The fact that it took you a month and a half to even say "we're investigating" is really concerning.
Posted by dennisht on 1/19/2014 at 9:07 AM
Hello, I have the same problem as everyone else hear. Cannot upload or update any of my websites or the ones that I am managing for others.
Please let us know if your going to fix this or not. Please give some kind of time frame, Please.
To update my software will change the functions of a lot of the sites I currently have built. Some will have to be totally redone.
So Please let me know of your intensions. Thank you.
Posted by Microsoft on 1/14/2014 at 8:15 AM
Thank you again everyone for all of the feedback.
We are aware of the problem and are working on a fix.

Best regards,
The Internet Explorer Beta Team
Posted by Ramon Smitherman on 1/13/2014 at 9:33 PM
All I do in my work is FTP files. Thought it would be good to upgrade due to promises of improvement performance. Now I am *((#(W( stuck. I had to activate an XP machine to transfer files I created on my windows 8.1
It seems insane that something so terribly broken was released. It appears no testing or very poor quality control. Something I would expect from a garage vendor not a major company.
Posted by leocard56 on 1/13/2014 at 10:55 AM
I urgently need I work with incomedia website.
Thanks to the Internet Explorer team
Posted by Zardos11 on 1/13/2014 at 12:25 AM
Thank you Microsoft. I urgently need the fix.
I'm waiting eagerly
Posted by Top Notcher on 1/7/2014 at 1:49 PM
Thank you Microsoft! This needs a fix!
Posted by Microsoft on 1/7/2014 at 11:40 AM
Thank you everyone for all of the feedback we are investigating this issue.
Best regards,
The Internet Explorer Team
Posted by Paul Baker on 12/22/2013 at 6:46 AM
Rick, I have a support request on this that is now closed, as it has been reported as a bug that I am led to believe the product team at Microsoft is actively working on. However, we will not likely hear anything until they have concluded their investigation. Let's not assume they are "ignoring" the issue or "doing nothing", but they certainly did not appropriately communicate the progress of the issue. I find it very odd that with all this speculation about what Microsoft is, and is not, doing about it, they did not deem it necessary to comment.
Posted by Rick Strahl on 12/20/2013 at 5:15 PM
I have a product that uses FTP functions as part of a developer toolkit and since the IE11 update on older versions of Windows we too have seen a huge number of support requests regarding this bug. Same issue - using InternetOpenFile/FtpOpenFile/InternetWriteFile combo fails. FtpPutFile() works as a workaround in *most* but not all situations but it's not really a good option given that we don't control the code that our developers use.

Sure would be nice if someone from Microsoft would at least deem it considerate to post a response to this issue - it's been open for over a month and no replies from anybody at Microsoft. Lame MS, lame! If there's a legit reason for this break - great lets hear it and show us the proper way, but leaving it like this and ignoring the issue is shameful.
Posted by Paul Baker on 12/20/2013 at 5:15 PM
I don't think FileZilla is affected. Maybe CrowDogsDamnIt has a different problem.
Posted by Paul Baker on 12/20/2013 at 5:08 PM
WebSite X5 Evolution 8 is affected - http://answers.websitex5.com/post/80429

It seems a lot of the products affected are web site builders.
Posted by Paul Baker on 12/20/2013 at 4:43 PM
WebPlus is affected - https://community.serif.com/forum/webplus/5316/website-will-not-upload-connects-to-server-but-just-keeps-retrying-to-upload
Posted by Paul Baker on 12/20/2013 at 4:38 PM
Xara Web Designer is affected - http://www.talkgraphics.com/showthread.php?65002-pictures-corrupt-since-updating-to-Windows-8-1-when-using-FTP-publish
Posted by Paul Baker on 12/20/2013 at 4:37 PM
Clipper Visual Objects is affected - https://groups.google.com/forum/#!topic/comp.lang.clipper.visual-objects/kg9zwebVzNw
Posted by Paul Baker on 12/20/2013 at 4:35 PM
CodeCharge Studio 5 is affected - http://forums.yessoftware.com/posts.php?post_id=122225
Posted by Paul Baker on 12/20/2013 at 4:23 PM
90 Second Website Builder is affected - http://youtu.be/hF7nS2hZFp8
Yep, it's on YouTube now that the Internet Explorer 11 update "affected literally thousands of people". I am kind of suprised it isn't higher profile actually.

When I last spoke to Microsoft support, yesterday afternoon (who I do not think is actually Microsoft), they mentioned that Microsoft generally updates Microsoft Connect with information. I pointed out that much of the frustration expressed here is because, despite the fact that dozens of developers can reproduce it and each of those may have many affected customers, Microsoft did not comment here. I suggested that they at least explain that they are looking into it. They said they would pass on the feedback.
Posted by Paul Baker on 12/20/2013 at 4:07 PM
WYSIWYG Web Builder is affected - see http://www.wysiwygwebbuilder.com/forum/viewtopic.php?f=10&t=58619
Posted by CrowDogsDamnIt on 12/19/2013 at 4:47 PM
Neither Filezilla nor Dreamweaver connect via FTP using Windows 8.1 both worked using Windows 8.
Posted by gn_ctax on 12/19/2013 at 1:58 PM
It's been a month since the issue was reported here and still no updates from Microsoft.
Posted by JBES77 on 12/18/2013 at 4:13 PM
I have the basically an identical issue as posted by Andy Schmidt on 11/22/2013 at 8:48 AM except in assembler (code reduced down):

invoke InternetOpen,addr Useragent,INTERNET_OPEN_TYPE_PRECONFIG,NULL,NULL,0
mov hInternet,eax

invoke InternetConnect,hInternet,addr lpszServerName,INTERNET_DEFAULT_FTP_PORT,addr lpszUserName,addr lpszPassword,INTERNET_SERVICE_FTP,INTERNET_FLAG_PASSIVE,0
mov hConnect,eax

invoke FtpOpenFile,hConnect,addr szPackedFile,GENERIC_WRITE,FTP_TRANSFER_TYPE_BINARY,NULL
mov hInetFileHandle,eax

    invoke InternetWriteFile,hInetFileHandle,addr BufferFile,lpdwNumberOfBytesRead,addr lpNumberOfBytesWritten
.until lpdwNumberOfBytesRead==0

invoke InternetCloseHandle,hInetFileHandle
invoke CloseHandle,hFile

--Fails here, works on non IE11

Seriously tired of Microsoft...
Posted by Graham F on 12/12/2013 at 2:06 PM
One of our customers has now reported an FTP-related problem caused by IE11 on Windows 7. In this case, it is in an MFC application where now CFtpFileFind::FindFile() is unable to find files with .txt extensions on the server. Other files extensions such as .xml.gz are not affected. A fix is urgently needed. We expect that many other customers will encounter this problem quite soon. (The MFC application is used to upgrade firmware in embedded devices.)
Posted by myhairisgreen on 12/11/2013 at 10:52 AM
Trying to use FileZilla (ver.3.7.3) on Windows 8.1 will no longer work. Was going to trouble shoot with Wireshark (1.10.3) but it also will no longer work. Had to use old PC with Windows 7 and IE 9 to get work done.
Posted by HCSSHutch on 12/11/2013 at 9:46 AM
I find it interesting that someone mentioned that under IE11, FTP is broken for one of MICROSOFT's own products (Excel 2010).
If that isn't a clear indication that something is screwed up, I don't know what else Microsoft wants.
Any of our product's users who have updated their systems with IE11 (or have devices with Windows 8.1) are unable to upload files via FTP. We currently are having them roll back to IE10 (though our users who have devices with Windows 8.1 are completely out of luck).
This is a real pain point for us as we have thousands of customers who use FTP on a daily basis to transfer files back and forth from their remote field operations to their office and many of them are encountering problems because of this issue.
This issue needs to be fixed.
Posted by Bubbi Smith on 12/9/2013 at 10:26 PM
Same deal, the FTP problem goes away for everyone that has switched back to IE:10. I'm still stuck on IE:9 for myself do to a separate FTP issue (http://social.technet.microsoft.com/Forums/ie/en-US/4ec48d5f-741c-404b-b027-90e6ea2a11dc/ie10-wont-allow-me-to-open-ftp-files-in-explorer-view?forum=ieitprocurrentver)
Posted by LHarding on 12/9/2013 at 7:04 PM
Andy, you can simply click the "I can too" option under the Users can reproduce this bug. Any comments here may help too. Microsoft has not provided me any updates. This issue is very frustrating to my end users. I will continue to ask my support rep. Right now only 20 users have clicked this option. More would help.
Posted by Andy Schmidt on 12/7/2013 at 5:52 PM
>> We currently have a pending support incident with Microsoft on this issue <<

LHarding - maybe you should explain HOW we can "attach" to the same incident to up the priority.
Posted by chacke2 on 12/7/2013 at 8:20 AM
I have a problem using WiniNet ref in IE11 using ftp rename

in IIS log I do not see the command
return code ftp prog/Err.LastDllError
RenameFTPFile error code: 12003

Posted by Paul Baker on 12/6/2013 at 8:57 AM
This version of WinInet was actually released with Windows 8.1, Microsoft's flagship product, on 10/23. Most people started noticing it with the Internet Explorer 11 update for Windows 7 that was released to Windows Update on, I think, 11/11 (the same day this was reported).
Posted by Antagony on 12/6/2013 at 8:10 AM
It's now coming up to a month since this issue was reported and we have multiple customers whose FTP utilities are now broken. This is ridiculous, Microsoft! How can you release something that breaks (probably) thousands of third party applications in such a fundamental way? It staggering to me that testing the impact of changes in a library file – that is crucial to so many users and developers alike – is so woefully inadequate that a bug of this magnitude is released. Come on Microsoft... get your act together and get this fixed ASAP!
Posted by jimbursch on 12/6/2013 at 7:10 AM
I was having trouble using FileZilla version 2.2.30 -- file would upload about 16k then fail. I have updated to FileZilla 3.7.3 and the problem so far has resolved.
Posted by ninjapiraatti on 12/5/2013 at 11:38 PM
My FTP is messed up as well after updating to 8.1. Any progress on this?
Posted by Paul Baker on 12/5/2013 at 6:00 PM
Flaviomr (and probably others), you can provide feedback during FtpPutFile() by using it asynchronously, as described here:

However, it is not an easy transition if you are unfamiliar and I still don't have any information from Microsoft about whether FtpPutFile() is affected in some way.
Posted by Flaviomr on 12/5/2013 at 8:59 AM
Same problem for me using internet Explorer 11 (it's not a Windows 8.1 problem, but related to the latest build of ie11).

Wininet.dll distributed with ie11 seems to have a lot of problem.

For example using wininet ftp function and try to create an existing directory you will get ok, then try to change to that directory and you will get the error that you cannot create a file (or just try to create the directory twice the first one the result will be ok the second time the result will be wrong, and i aspected Always a wrong result code), and there are many of this kind of problem to make impossible to use any wininet ftp related function.

It seems that the return code of the previous ftp function will be reported in the next call of any wininet function.

Using ftpputfile for me is not a workaround because i cannot give a progress indicator. And anyway this can solve the problem of sending files, but not the other related to the fact that the result code are out of sync with the operation.

Hope to have a fix really soon, in the meanwhile we reversed to previous internet Explorer when possible

Posted by jimbursch on 12/4/2013 at 2:40 PM
I just want to weigh in on this issue -- since I updated to 8.1 I have problems ftp files bigger than 16k. Hoping for fix soon.
Posted by GrahamAuty on 12/4/2013 at 4:33 AM
I've encountered this problem at 4 sites so far (and counting) using FTP to send / receive files between a Windows 7 PC running our software & an EPOS system with an embedded FTP server.

The work around for us in each case has been for the Windows 7 site to uninstall IE11, but we'd obviously like a proper solution ASAP.
Posted by SergioElFlaco on 12/3/2013 at 12:45 PM
Please Microsoft, fix it ASAP !!! TIA
Posted by Paul Baker on 12/3/2013 at 10:01 AM
Top Notcher, what is your "non Microsoft solution"? Does it work for all file sizes?

Microsoft tells me that the product team is actively working on it and has a product engineer assigned as well as an escalation engineer. However, we must wait for a response from the product team. I could not get an answer as to whether or not FtpPutFile() is affected.

I have a case open with SolarWinds, who provides support for Serv-U, to see if they can make a change so that Serv-U is more resilient to Microsoft's bug. WinInet is not waiting for the reply to the STOR command, and it is not sending a QUIT command. It is just disconnecting! However, WinInet does send all the data and close the data port, and Serv-U did receive all the data. So it seems they should be able to flush a buffer.

What other third party FTP servers are affected?
Posted by Guang_Interalia on 12/3/2013 at 9:10 AM
Our software is experiencing the same FTP upload problem, on Windows Server 2008 with IE11 updated.

We are waiting for Microsoft's fix.
Posted by LHarding on 12/3/2013 at 5:52 AM
Our software that has been doing FTP transfers for over a decade now is having similar issues with calls to FtpOpenFile, InternetWriteFile, FtpRenameFile on systems running IE11. We are are telling our customers to go back to a restore point (pre IE11) for their FTP activity to work consistently. We currently have a pending support incident with Microsoft on this issue. According to my Microsoft support rep, the more people that attach to this issue the higher the priority Microsoft will give it.
Posted by Alex Yorke on 12/2/2013 at 3:55 PM
This is ridiculous, as reported below we are experiencing similar issues. FTP over windows 8.1 with IE11 is unusable. We need a fix for this ASAP!!
Posted by MChiasson on 12/2/2013 at 7:57 AM
I really can't believe Microsoft hasn't issued a fix for this yet. We rely on programs that have built in FTP functionality and are dead in the water without being able to use them now. You can't downgrade from IE11 to IE10 or Win 8.1 to 8. This is so absurd. I've always been a windows guy but ready to make the switch after this abuse.
Posted by Andy Schmidt on 11/28/2013 at 10:30 AM
Just FYI: For OUR application, we WERE able to replace FtpOpenFile()/InternetWriteFile() with FtpPutFile() and have been testing this successfully. We do have a callback in place for progress reporting.

We do NOT have any problems with FtpRenameFile() - so this may just be a secondary problem AFTER an FtpOpenFile()/InternetWriteFile() causes the WinInet to lag behind one response. It doesn't matter what other commands follow the initial sequence, they may act unpredictibly.

Basically, anything that looks for a specific server response MAY see the wrong response and thus indicate errors that don't exist (we had two "deletes" in a row, the first one was for a non-existing file, that returned "success" because that was still a PRIOR server response. The next delete for an EXISTING filee returned "file not found", which was of course the server response to the FIRST delete.)
Anything that looks for an intermediate server response (like the Rename) - or a second file transfer - will "time out" because it won't see the correct intermediate response.
Posted by Top Notcher on 11/27/2013 at 12:08 PM
I have issues uploading files (mostly larger ones). I have a non-microsoft solution in place until this is repaired. Thanks MS for getting some resources on this,
Posted by Paul Baker on 11/27/2013 at 11:23 AM
I tried replacing FtpOpenFile()/InternetWriteFile() with FtpPutFile() and using various file sizes starting at 1 KB and incrementing by 1 KB. I got up to 37,724,184 (35.9 MB) before terminating the test. All but one test was successful. In that test, the file I just uploaded was not present when I tried to check its file size in a new session (I cannot explain this).

This gives me more confidence than FtpPutFile() might be a viable workaround, but of course I am still concerned that MichaelTDN saw a problem around 10 MB. Microsoft's current recommendation is not to try any of the workarounds documented in this bug report, as they might not work for some users, and to wait for the product team to respond.
Posted by Alan - Glover on 11/26/2013 at 10:16 AM
Probably more of the same... Excel 2010, IE 10 upgraded to IE 11, Win 7 64 bit. With IE 10 I can use Excel to upload via save as web page to a ftp location set up to appear as a Network Location in Computer (the remote server runs Ubuntu). With IE 11 it fails 100% of the time and works again when IE 11 is reverted to IE 10.
Posted by Paul Baker on 11/24/2013 at 12:03 PM
Andy, I think we're misunderstanding each other. Basically, all I am saying is that when sending a command, it should wait for the reply before sending another one. That explains ALL this behaviour.

Your comments about a callback remind me that I suppose using FtpPutFile() asynchronously could make it a viable workaround. Again, only if that reliably works (which I am doubtful of, I suspect it just changes the timing a bit, enough to make it rarer).

I have opened a support case with Microsoft about this.
Posted by Andy Schmidt on 11/23/2013 at 7:44 AM
I suspect that is another facet of the broken WinInet:
In THIS case, it is the FtpRenameFile() that fails, because it is a two-step server interaction. I suspect that WinInet submits the RNFR, waits for the server response, but lags one response behind. So it never sends the RNTO.
I will have to see on Monday, if the RENAME is broken too for our app, then any "upload" workaround won't matter much, because in reality it's not just a very isolated scenario (PASV STOR) for which there might be an alternative - it would indicate that it's a global problem through WinInet in IE11.

Paul, as far as the NOOP/226 loop, that's why I suggested investigating a callback as an alternative to a loop - hoping it may be less vulnerable.

As far as the Command vs. Data connection. Well, yes, the Data connection is supposed to have been closed by the client, before it logs off and closes the Command connection. Specifically, as the programmer you are not supposed to use InternetCloseHandle() against the command session handle from InternetConnect(), without first having used InternetCloseHandle() against the FtpOpenFile() handle, if you have a file transfer in progress. Also, any calls against the FTP session handle will fail with "file transfer in progress" to remind you if you forget you still have a data connection open. In fact, we make a point to explicitly submit an FtpCommand to properly logoff instead of just dropping the command connection when our app is done. This avoids some servers waiting a few minutes before eventually timing out those open ports for non-activity (during which time some recentaly manipulated files on the server may be "locked" by the still-running FTP server session).

(I'm in agreement with you on the mechanics, it's just that I haven't observed any problem with the command connection being lost/closed by WinInet as part of the bug we are discussing?)
Posted by Paul Baker on 11/22/2013 at 5:14 PM
I forgot - the packet summaries attached are intended to show the incorrect sequence of commands/replies. They do not necessarily reflect a truncated upload (BTW, each is supposed to be 64 KB).
Posted by Paul Baker on 11/22/2013 at 3:45 PM

The attached packet summary should show if all the bytes actually made it over the wire, though I never actually added them up!

I am not satisfied with the FtpPutFile() workaround, and I worry about MichaelTDN's comment that it does not always work.

I too am uncomfortable with the NOOP idea, especially as I have it implemented, and I thank you for the further advice on that. Even if I refined it, it seems like it could break things just as much as it could help.

I may be interpreting the RFC incorrectly, I thought it was saying that you're supposed to deal with the open data port (which it does) and the reply (which it does not) before you disconnect the command port, or else you are doing so "unexpectedly" and essentially aborting. People who are more knowledgeable than me about this can decide that. All I would say at this point is that closing the command port while there is a reply that has not been read is a risk, one that apparently causes problems for some servers (including IIS, but not very often). The problem seems to be with not reading the reply from the command port (after using a data port), therefore I see it as a command port problem.
Posted by Andy Schmidt on 11/22/2013 at 3:29 PM
In our specific case, we may be able to use FtpPutFile() - assuming this problem is limited to the InternetWriteFile() and possibly limited to PASV mode. So they are trying THAT workaround first.

Correct, we too see Bytes Written = Bytes Sent, but after giving this some thought, I'm no longer certain that really is based on server response (e.g., how many bytes were received AT the server), but simply how many bytes were locally read and submitted to the protocol.

Your NOOP loop idea, waiting for 226, may not be widely applicable. There are 18 possible status codes defined in response to the STOR command, 1xx are just confirming the start, 226 and 250 could indicate successful completion - but there are also various 4xx and 5xx temporary/permanent conditions that might indicate errors (such as "no space", connection dropped, etc.) that you would have to handle, otherwise you'd be running an eternal loop if there are ANY file transfer errors EVER!

I'm not clear why you feel that the control connection citations are relevant here? 5.2 simply states that the CONTROL connection needs to be "hung up" once you end the session. That seems to work just fine. 4.4.1 deals with what the server should do if the CONTROL connection drops... again, I have ONLY seen problems with the DATA port NOT the command port!?
Posted by Paul Baker on 11/22/2013 at 11:06 AM
Let me know how InternetSetStatusCallback() works for you.

The fact that InternetQueryDataAvailable() is for reading is basically what I was saying.

Bytes written = bytes sent in every single test I performed, successful or unsuccessful (of which there were many thousands).

Did you check the result of InternetCloseHandle() before looking at GetLastError? If not, GetLastError is undefined.

I tried sending a REIN command, which I noticed when poking around RFC 959. It makes the incidence less, but it still happens.

Here are two quotes from RFC 959 that vaguely suggest what WinInet is doing could cause the kind of problem we see. Certainly, it's not being a friendly member of the Internet community :)
Section 5.2 CONNECTIONS "The control connection shall be closed by the server at the user's request after all transfers and replies are completed.".
Section 4.1.1 ACCESS CONTROL COMMANDS "An unexpected close on the control connection will cause the server to take the effective action of an abort (ABOR) and a logout (QUIT)."
Posted by Andy Schmidt on 11/22/2013 at 10:51 AM
Funny, I was just debating whether a NOOP was worth a test.

Paul, it almost looks as if WinInet accidentally handles the WriteFile in "asynch" fashion. Rather than looping on a NOOP using FtpCommand(), I wonder if InternetSetStatusCallback could be set up to be notified. (I suspect InternetQueryDataAvailable only works for reading, not writing).

I also wonder, if bytes written = bytes sent in your InternetWriteFile? If not, that would indicate that the upload was not yet complete.
Finally, if a GetLastError immediately after InternetCloseHandle returns ERROR_IO_PENDING, then this would be further confirmation!
Posted by Paul Baker on 11/22/2013 at 9:12 AM
Actually, it would not accept my .pcapng files. I attached .csv packet summaries instead. It seems like they have to be moderated.
Posted by Paul Baker on 11/22/2013 at 9:10 AM
Yes, Andy, I came to the same conclusion as you earlier today :) It lead me to a workaround, which I posted and am currently testing.

Attached are two Wireshark logs that demonstrate this. After uploading the file, I am calling FtpFindFirstFile() to check whether or not the file size is accurate, and getting an ERROR_INTERNET_EXTENDED_ERROR error. The reason is that although it uploaded all the data to the data port, disconnected and waited for the TCP acknowledgement, it did not read the response to the STOR command. If, instead of calling FtpFindFirstFile() and instead of sending another command, you disconnect the session, the server is confused because the response to the STOR command is abandoned. The exact behavior depends on the server, but it often results in file truncation rather than flushing. The file tends to get truncated near the end.

IE11FTPnemesis.pcapng - Server is Serv-U
IE11FTPpaulb-win8_1.pcapng - Server is IIS on Windows 8
Posted by Andy Schmidt on 11/22/2013 at 8:48 AM
We have traced this bug to be a problem with WinInet getting out of synch with the FTP server responses after the FIRST completed file transfer, when using FtpOpenFile/InternetWriteFile/InternetCloseHandle sequence, in particular when using PASV mode, but it may not be limited to that. (We confirmed this against a variety of DIFFERENT FTP server brands!)

This can be proven by using InternetGetLastResponseInfo to query the last server response after every WinInet call.


-> 200 Transfer mode set to BINARY
-> 227 Entering Passive Mode (a,b,c,d,19,147).
-> 125 Uploading in BINARY file x
-> (NULL ResponseInfo)

-> 226 Transfer completed
-> 200 Transfer mode set to BINARY
... result = timeout

The underlying problem is that the Response "226 Transfer completed" belongs to the END of the FIRST file transfer, e.g., after the InternetCloseHandle() call. The SECOND file's FtpOpenFile() should be seeing a fresh combination of 200/227 responses (which the FTP server actually DID sent - we checked!). The 227 response would contain the port information for WinInet to open the next PASV data connection for that second FtpOpenFile.

But, because WinInet sees the old 226/200 combination and doesn't SEE the necessary "227" response, it fails the connection and the server sits with the open port, until timeout.

Posted by Paul Baker on 11/20/2013 at 1:28 PM
What server are you guys using?

I can reproduce this on a server that uses ServU. I cannot reproduce this if the server is localhost (IIS on Windows 8.1) or another machine (IIS on Windows 7). It oculd be a coincidence, or it could be a problem with non-Microsoft servers.

I am going to use Wireshark to examine the commands it is sending.
Posted by Paul Baker on 11/20/2013 at 1:14 PM
Posted by Paul Baker on 11/20/2013 at 11:25 AM
There are thousands of instances a day of customers using WinInet to upload a file to us, of which this problem is reported dozens of times a day. This is a large burden on our limited support staff.

Who is affected? My experience has been that the Internet Explorer 11 for Windows 7 update is marked as "Important" on Windows Update but is not installed automatically. However, this seems contrary to the setting that indicates it should automatically install important updates. Lack of information I can use to understand why this is so makes it hard for me to estimate who may or may not have automatically gotten the update. I worry that more people will, for whatever reason, get the update and be affected.
Posted by Paul Baker on 11/20/2013 at 11:21 AM
Anyone reading this, feel free to contact me at paulb@bccsoftware.com.

I have seen an ERROR_INTERNET_CONNECTION_ABORTED error twice over thousands of tests. I do not know which WinInet function returned it because my error handling was not designed to report that detail when it happened.
Posted by Zardos11 on 11/20/2013 at 12:45 AM
I can also reproduce the problem.
My FTP program does not work with IE 11
There is a bug in the Winint.dll!
I have the same error messages as already mentioned.

FtpOpenFile and InternetWriteFile no longer work correctly.
FtpPutFile is not a substitute for it.

Please Mirosoft fixes the problem and makes an update
Posted by Paul Baker on 11/19/2013 at 11:03 AM
This looks like a report of the same problem.
Posted by Paul Baker on 11/19/2013 at 10:00 AM
This still happens when Windows Defender and Windows Firewall are both off.
Posted by Paul Baker on 11/19/2013 at 9:57 AM
The amount of data actually written is variable/sporadic, but it seems to always be either a multiple of 1 KB or the entire file, regardless of the actual size of the writes.