FIX: FtpOpenFile Fails in Asynchronous WinInet

• Microsoft Internet Explorer (Programming) versions 4.0, 4.01, 4.01 SP1, 4.01 SP2

SYMPTOMS

In asynchronous WinInet mode you open a remote file with the FtpOpenFile function, read it with the InternetReadFile function, and then close the handle returned from FtpOpenFile with the InternetCloseHandle function. InternetCloseHandle returns TRUE. However, if you try to open another file with FtpOpenFile it fails with the error code 12110 (ERROR_FTP_TRANSFER_IN_PROGRESS). If you wait for the state of handle closing before opening another file anyway, you never get the status indication of INTERNET_STATUS_HANDLE_CLOSING from the callback function. The program stops responding.

The problem occurs only when the previous call to InternetReadFile was asynchronous or it failed with the error code of 997 (ERROR_IO_PENDING) at the first place.

CAUSE

InternetReadFile does not reset the refcount on a HANDLE_OBJECT after reaching EOF.

RESOLUTION

You can write a multiple-thread program in synchronous WinInet mode. The primary thread spawns a worker thread, which calls synchronous WinInet functions (blocking) so that the primary thread is free. Use any synchronization mechanisms, such as event object, to synchronize the primary thread and worker thread.

STATUS

The bug has been fixed in Internet Explorer 5 and later. There is no need to wait for the callback indication of INTERNET_STATUS_HANDLE_CLOSING before calling another FtpOpenFile if InternetCloseHandle returns TRUE.

Additional query words:

Keywords : kbIE400bug kbIE401bug kbIE500fix kbGrpInetServer kbDSupport
Version : WINDOWS:4.0,4.01,4.01 SP1,4.01 SP2
Platform : WINDOWS
Issue type : kbbug