Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

WinHTTP 5.1: WinHTTPSetOption crash with WINHTTP_OPTION_USERNAME

84 views
Skip to first unread message

Ostapenko@discussions.microsoft.com Alex Ostapenko

unread,
Oct 15, 2004, 4:35:08 PM10/15/04
to
I am calling WinHTTPSetOption(hRequest, WINHTTP_OPTION_USERNAME, pUserName,
dwSize) having dwSize = wcslen(pUserName) * sizeof(WCHAR). This sometimes
lead to a crash in MultiByteToWideChar call inside the WinHTTPSetOption. From
the dump anylisys I see the there is an attemt to read data beyond the string
end. Looks like WinHTTPSetOption incorrectly interprets size as a string
length (although by the documentation it should be a buffer size in bytes).
All this happens under Win2k SP4.

With best wishes,
Alex Ostapenko,
Helicon Tech.

Biao Wang [MSFT]

unread,
Oct 18, 2004, 3:29:02 PM10/18/04
to
Hi Alex,

The document for this API is inaccurate -- for string options the buffer
length should be in characters, not bytes.

Newer version of WinHttp 5.1, such as the version included in Windows XP
SP2, contains added logic to handle string buffer length being passed as
bytes as suggested by the doc and would fix this problem as long as the
string in the buffer is null terminated.

For Win2K SP4, you must pass buffer size in characters for string options
for your WinHttp app to work robustly.

Hope this helps,
Biao.W. [MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.

Alex Ostapenko

unread,
Oct 19, 2004, 4:06:29 AM10/19/04
to
Hello Biao,
You wrote on Mon, 18 Oct 2004 12:29:02 -0700:

BWM> The document for this API is inaccurate -- for string options the
BWM> buffer length should be in characters, not bytes.

BWM> Newer version of WinHttp 5.1, such as the version included in Windows
BWM> XP SP2, contains added logic to handle string buffer length being
BWM> passed as bytes as suggested by the doc and would fix this problem as
BWM> long as the string in the buffer is null terminated.

OK, thank you for the clarification.

0 new messages