0

I'm trying to use URLDownloadToFile to download a file, but am getting INET_E_DOWNLOAD_FAILURE after the file is partially downloaded. My call looks like:

HRESULT hRes = ::URLDownloadToFile( NULL, strTemp, strDestination, 0, pCallback );

strTemp gives the URL in the form:

https:////

pCallback is an implementation of IBindStatusCallback, IHttpSecurity, and IWindowForBindingUI.

I am able to get to the point of having windows show a dialog warning me about the security certificate of the website (by returning S_FALSE in IHttpSecurity::OnSecurityProblem).

I get several calls in IBindStatusCallback::OnProgress, with this succession of ulStatus values:

BINDSTATUS_PROXYDETECTING BINDSTATUS_COOKIE_SENT BINDSTATUS_CONNECTING BINDSTATUS_SENDINGREQUEST

After that last OnProgress call, a packet sniffer shows that I get 100+ KB of data downloaded from the server (The file is 18+ MB.) Then I get a call to IBindStatusCallback::OnStopBinding with an hResult value of INET_E_DOWNLOAD_FAILURE.

I know that permission to write to the destination directory is not a problem.

I am not sure whether I am handling IBindStatusCallback::GetBindInfo and ::OnStartBinding correctly. Here is my code for each:

STDMETHODIMP CDownloadCallback::GetBindInfo( DWORD* pBINDF, BINDINFO* pBindinfo )
{
   *pBINDF = BINDF_PULLDATA | BINDF_NOWRITECACHE | BINDF_GETNEWESTVERSION;
   return S_OK;
}

STDMETHODIMP CDownloadCallback::OnStartBinding( DWORD dwReserved, IBinding* pBinding )
{
   return E_NOTIMPL;
}

Any ideas on what could be going wrong?

Wayne
  • 321
  • 1
  • 3
  • 7

1 Answers1

0

I am also having this problem now, although when I last used/developed the program 6 months ago it worked fine. However if I run the program with administrator rights it works fine.

My symptoms are very similar to Wayne's. Process monitors shows it communicating with the server via TCP (although slightly less data than when it doesn't have Admin rights) It is also making calls to the status callback in both modes. The location of the file to download to is the temp directory and doesn't require admin rights.

The version of urlmon.dll is 11.00.96.17041 32bit dated March 2014 which is newer than the one that it was previously working with but is this the cause or something else?

eskdale
  • 11
  • 1
  • 2