-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WinHttp buffer supplied to the function was too small error should not be exposed #17005
WinHttp buffer supplied to the function was too small error should not be exposed #17005
Comments
Failed again, but this time with a different exception message:
|
From https://github.com/dotnet/corefx/issues/8038: The exception of "The buffers supplied to a function was too small" doesn't seem like something due to just network vagaries. http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_debug_prtest/408/ |
"The buffers supplied to a function was too small" |
That particular WinHTTP error is never supposed to bubble out. It means that we called WinHTTP and didn't give it a buffer big enough to return information. That would mean there is a bug in our code. We didn't start seeing these errors until we added |
I also occasionally get this error using System.Net.Http 4.1.0 on Windows with a custom ServerCertificateCustomValidationCallback. |
This error is happening to me in a production environment. Packet capture shows the error happens during key exchange. The certificate is valid. I am doing no custom validation. When it happens it is intermittent with ~30% of requests failing for approx. hour period of time. HttpClient client = new HttpClient(); |
Thanks for the updated info. It sounds like this is a problem with the low-level windows WinHTTP component. Do you have a stack trace for where the error "The buffers supplied to a function was too small" is coming from? It would be useful to catch this bug in a debugger since that is the only way to get actionable information to diagnose. |
How would you advise setting up the debugger? This happens once every 2-3 days at seemly random times of day. Stack:
[EDIT] Format call stack by @karelz |
If the exception is unhandled,then normally your process was crash. If so, you can use "windbg /I" to set up post-mortem debugging. When the process crashes, Windbg will launch automatically and you'll be able to debug and see threads, stack, etc. |
Could be a product bug....need more investigation. |
I'm encountering these same errors in an azure production environment. I run asp.net core on top of the full .net 4.6.1 so I suspect it's not specific to .net core.
|
@davidsh any reason for moving it to Future? |
I believe this is a real product bug. Getting this exception, for example, surfaced "the buffers supplied to a function was too small" should never occur. That particular exception is usually caught internally and we have logic to do the right thing with WinHTTP (which is to resize our buffer and call WinHTTP again). We haven't seen this a lot, though. So, in terms of prioritizing all the other important 2.0 bugs, we could probably defer it to Future. |
Thanks! That makes sense, moving back to Future. |
After re-reading the thread, it actually looks that 2 people hit it in the wild. That's concerning. I think we should look into it in 2.0. |
Also this issue happens to me randomly, along with "WinHttpException: A security error" sometimes, and only if I using https protocol. |
I am as well seeing this error in production. My code is posting a SOAP request to an HTTPS endpoint. The request does have an embedded encoded document, but the specific document that last caused the error was only 1.1MB. The additional data is less than 1K. As with others, another error received is "An error occurred in the secure channel support" on the same code block. The server is using TLS 1.2, AES with 256 bit encryption; DH with 2048 bit exchange. Public Function HTTPRequest(PostURL)
Set objHTTP = CreateObject("MSXML2.ServerXMLHttp.6.0")
objHTTP.open "POST", strURLProduction, False
objHTTP.setRequestHeader "Content-Type", "text/xml;charset-UTF-8"
objHTTP.setRequestHeader "SOAPAction", """"""
objHTTP.send objXMLRequest.xml
HTTPRequest = objHTTP.responseText
Set objHTTP = Nothing
End Function |
I have implemented the workaround provided as the first solution on StackOverflow to use a MSXML2.XMLHttp.6.0 object instead of MSXML2.ServerXMLHttp.6.0. As this was just implemented, I do not know if this will resolve the error but will post back accordingly. |
@steveharter can you please try to repro this issue? It will help us triage it. If we don't have repro, it is likely not actionable in 2.0. |
The MSXML2.XMLHttp.6.0 object did not resolve the issue. I have since created and implemented a different module using the endpoint WSDL and a COM-Visible DLL in the customers production environment, so unable to revert or reproduce. |
@steveharter ping? |
I will kick off a test soon and report back tomorrow. A previous mass-run of Http.Functional tests with all ActiveIssue tests disabled was not successful (or trustworthy) due to certain re-enabled tests to cause hangs, thus requiring selective re-enablement of tests going forward. |
release/2.0.0 failure The test
Build : 2.0.0 - 20170927.01 (Core Tests)
|
Porting the same logic from master branch to disable these tests on systems that don't have the fix to SCHANNEL regarding DHE cipher suites. Addresses #23822
Triage: We need to disable the test only on older OS's (Win7, Win8.1, Win10 before build - see above https://github.com/dotnet/corefx/issues/7812#issuecomment-313154522). |
The root cause issue was already fixed in Windows but old versions still hit this issue. This change makes the failing test to ignore the known issue on these old Windows versions. Fixes #7812 (just so GH closes the issue at merge time, the actual issue was fixed in Windows).
The root cause issue was already fixed in Windows but old versions still hit this issue. This change makes the failing test to ignore the known issue on these old Windows versions. Fixes #7812 (just so GH closes the issue at merge time, the actual issue was fixed in Windows).
@pjanotti there is still one test disabled against this bug: Is that on purpose? Can it be re-enabled? Or do we need to track more work? (Maybe there was mix up of multiple problem here?) |
Somehow I missed that one... re-opening... |
/cc @Priya91 @wfurt @davidsh (area owners) The test fails when [InlineData(null, SslProtocols.Tls11)]
[InlineData(SslProtocols.Tls11, null)] Since if (PlatformDetection.IsWindows && PlatformDetection.WindowsVersion >= 10)
{
Assert.True(_clientStream.HashAlgorithm == HashAlgorithmType.Sha256 ||
_clientStream.HashAlgorithm == HashAlgorithmType.Sha384 ||
_clientStream.HashAlgorithm == HashAlgorithmType.Sha512);
} Is this a product bug? The test implies that we shouldn't be going back to Sha1. |
@bartonjs Do you know if the above test is valid, that on Windows 10, the hashalgorithm cannot be Sha1? |
That claim probably holds when the protocol is 1.2; but 1.1 didn't have any SHA256/SHA384/SHA512 options. If you look at all of the entries marked as "TLS 1.1" on https://msdn.microsoft.com/en-us/library/windows/desktop/mt808163(v=vs.85).aspx you'll see that they just say "SHA" (except for the couple that say "MD5"). |
Protected against error in old versions of Windows and updated assert to include the case when hash algorithm can be Sha1. Fixes #7812 (actual fix done on Windows, just re-enabling affected tests with proper guard)
* Enable ClientAndServer_OneOrBothUseDefault_Ok test Protected against error in old versions of Windows and updated assert to include the case when hash algorithm can be Sha1. Fixes #7812 (actual fix done on Windows, just re-enabling affected tests with proper guard) * Waiting for tasks w/ test cfg wrapper * Skip test on Windows 7 On Windows 7 only Tls is supported OOB, so only few test cases can actually pass. Others fail with: ``` System.Security.Authentication.AuthenticationException : A call to SSPI failed, see inner exception. ---- System.ComponentModel.Win32Exception : The client and server cannot communicate, because they do not possess a common algorithm ```
@davidsh Is there any KB for that issue? I am curious about updates for older systems. |
This issue was fixed in Windows 10 releases:
I am not aware if there are KB articles directly addressing this. |
Our CI builds have intermittent failures in our online tests, e.g. with the message "A provided buffer was too small". This is not a programming error in libgit2 but rather an error in the SChannel component of Windows. Under certain circumstances involving Diffie-Hellman key exchange, SChannel is unable to correctly handle input from the server. This bug has already been fixed in recent patches for Windows 10 and Windows Server 2016, but they are not yet available for AppVeyor. Manually pamper over that issue by disabling all ciphersuites using DHE via the registry. While this disables more ciphers than necessary, we really don't care for that at all but just want to avoid build failures due to that bug. See [1], [2] or [3] for additional information. 1: aws/aws-sdk-cpp#671 2: https://github.com/dotnet/corefx/issues/7812 3: https://support.microsoft.com/en-us/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n
Our CI builds have intermittent failures in our online tests, e.g. with the message "A provided buffer was too small". This is not a programming error in libgit2 but rather an error in the SChannel component of Windows. Under certain circumstances involving Diffie-Hellman key exchange, SChannel is unable to correctly handle input from the server. This bug has already been fixed in recent patches for Windows 10 and Windows Server 2016, but they are not yet available for AppVeyor. Manually pamper over that issue by disabling all ciphersuites using DHE via the registry. While this disables more ciphers than necessary, we really don't care for that at all but just want to avoid build failures due to that bug. See [1], [2] or [3] for additional information. 1: aws/aws-sdk-cpp#671 2: https://github.com/dotnet/corefx/issues/7812 3: https://support.microsoft.com/en-us/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n
Our CI builds have intermittent failures in our online tests, e.g. with the message "A provided buffer was too small". This is not a programming error in libgit2 but rather an error in the SChannel component of Windows. Under certain circumstances involving Diffie-Hellman key exchange, SChannel is unable to correctly handle input from the server. This bug has already been fixed in recent patches for Windows 10 and Windows Server 2016, but they are not yet available for AppVeyor. Manually pamper over that issue by disabling all ciphersuites using DHE via the registry. While this disables more ciphers than necessary, we really don't care for that at all but just want to avoid build failures due to that bug. See [1], [2] or [3] for additional information. 1: aws/aws-sdk-cpp#671 2: https://github.com/dotnet/corefx/issues/7812 3: https://support.microsoft.com/en-us/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n
Our CI builds have intermittent failures in our online tests, e.g. with the message "A provided buffer was too small". This is not a programming error in libgit2 but rather an error in the SChannel component of Windows. Under certain circumstances involving Diffie-Hellman key exchange, SChannel is unable to correctly handle input from the server. This bug has already been fixed in recent patches for Windows 10 and Windows Server 2016, but they are not yet available for AppVeyor. Manually pamper over that issue by disabling all ciphersuites using DHE via the registry. While this disables more ciphers than necessary, we really don't care for that at all but just want to avoid build failures due to that bug. See [1], [2] or [3] for additional information. 1: aws/aws-sdk-cpp#671 2: https://github.com/dotnet/corefx/issues/7812 3: https://support.microsoft.com/en-us/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n (cherry picked from commit 723e1e9)
We had issues related to our https .NET application (F5 BIGIP Load balanced) where it used to break intermittently for 1 hour window. and then started working again by itself after an hour. The server event logs showed "Schannel Error - The TLS protocol defined fatal alert code is 40, while the application logs showed the error "HttpRequestException: The buffers supplied to a function was too small ". The issue was due to what is mentioned in the BIGIP F5 article https://support.f5.com/csp/article/K40424522 and was resolved when we disabled the DHE/EDH cypher on the impacted application VIP. |
We're seeing this today on a production server Windows Server 2012 R2, .NET Core 3.1. My understanding based on reading this thread was that it was supposed to be have been fixed in .NET Core 2.1? Is the SSL workaround still the best way to handle this? |
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/80/consoleFull
The text was updated successfully, but these errors were encountered: