Partager via

Changes in WinInet API validation code could lead to Unexpected Behavior

  • Article

In Windows Vista and IE7 we have changed the parameter validation code in WinInet to be more consistent with other Win32 APIs. Specifically the parts that tried to detect bad pointers and unallocated memory (via the IsBadReadPtr() API and it’s brethren) and returned ERROR_INVALID_PARAMETER (87) when it found an issue. With Windows Vista/IE7, we will only do the standard checking such as NULL checks for pointers. If you pass invalid data to the WinInet APIs you will get anything from data corruption to an Access Violation exception. For more detail on the why this change is a good thing for developers and users, check out Larry Osterman’s post on “Should I check the parameters to my function?”

The affected functions are:

  • HttpAddRequestHeaders
  • InternetCreateUrl
  • InternetOpenUrl
  • HttpQueryInfo
  • InternetUnlockRequestFile
  • HttpSendRequest
  • HttpSendRequestEx

If you are an application developer using WinInet and you start getting crashes in these functions, take a look at the pointer values getting passed to these functions. You should also consider signing up to get your application crash data from Microsoft’s Windows Error Reporting service to find out what your customers are hitting that you may not be. We are also thinking about creating an application compatibility shim to help legacy applications by mimicking the old behavior.

Since WinInet is a component that helps access content from the Internet, exposing coding flaws and getting them fixed is even more important. The short term pain for developers experiencing new crashes during development will hopefully be balanced by the long term reduction of weird corruptions and potential security issues on our customer’s computers.

   -- Reymarx Gereda