Unfortunately, not a problem in your code.
It's one of the few cases, where you actually are getting caught in a brandnew, yet major problem in the updated WinInet included with the just released IE 11. It will break most FTP apps using Microsoft's FTP classes for Win 7/8 users who upgrade. I recommend you add yourself to this bug report: https://connect.microsoft.com/IE/feedback/details/808279/ftpopenfile-and-internetwritefile-broken-changed-in-ie11 to hopefully instill some urgency into Microsoft.
Details
The underlying problem appears to be any FTP interaction where WinInet depends on specific server responses. It will work the FIRST time in an FTP session but after that, WinInet always lags behind one response - thus never seeing the correct response codes it needs to handle subsequent requests.
Example
PASV mode STOR requires the WinInet to parse the server response for the open data port. It will fail for the second upload, if FtpOpenFile() is used (although FtpPutFile seems to work, and possible PORT mode).
Related Problems
There are also reports about any more than the very first FtpRename failing - because after the RNFR piece, WinInet waits for a specific response before sending the RNTO piece. When WinInet lags behind, it will never see the PREVIOUS server response code, never the necessary Server response code it is waiting for (although traces confirm that the server did send it).
How to Reproduce
This can be observed by using InternetGetLastResponseInfo() after each FTP API call. After the first PASV upload using FtpOpenFile() or the first Rename, all subsequent FTP API calls will show the server response to the PRECEDING FTP API call.
(PS: I thought I had pointed this bug out yesterday - no sense everyone trying to "fix" their own code when the problem is elsehwere. But somehow the info disappears by the next day. Hopefully people will find the information on other sites using Google.)