Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
Sometimes when reviewing network captures, there are messages in the trace that seem to be indicative of the issue, but once you dig deeper, you realize that they are informational, not a sign of the problem. This article is being written so you can understand one SMB message better and not get concerned if you see it in a trace. The message we are going to discuss is the scary-sounding STATUS_BUFFER_TOO_SMALL.
So imagine that you’re finding that when you are transferring data to a server, you have a slow-down or a disconnect. Your first troubleshooting steps should be to take a network capture. You start pouring through the capture when the words jump out at you – “STATUS_BUFFER_TOO_SMALL”. “Aha!” you think, but if you understand the significance of the message, you will soon realize that you need to look elsewhere for the root of the problem.
In the trace, the frame will look something like this, which is an NT Transaction Response:
0.000208 192.168.1.11 192.168.1.10 SMB SMB:R; Nt Transact, NT Query Security Description, FID = 0x4019 - NT Status: System - Error, Code = (35) STATUS_BUFFER_TOO_SMALL
In a trace, you can find these with Network Monitor filter SMB.NTStatus.Code == 0x23. In the above frame, the message is being sent from the server to the client. You might think this means that the server’s buffer is getting too small, but that actually isn’t the case. The message is the server telling the client that the client’s buffer is too small. You will understand this better if we dig into the NT Transact sent to the server before the message appears:
0.000000 192.168.1.10 192.168.1.11 SMB SMB:C; Nt Transact, NT Query Security Description, FID = 0x4019
Frame: Number = 1, Captured Frame Length = 142, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-17-94-4B-AC-43],SourceAddress:[00-21-70-77-95-BC] + Ipv4: Src = 192.168.1.10, Dest = 192.168.1.11, Next Protocol = TCP, Packet ID = 6396, Total IP Length = 128 + Tcp: Flags=...AP..., SrcPort=L2TP(1701), DstPort=Microsoft-DS(445), PayloadLen=88, Seq=1366185756 - 1366185844, Ack=426719751, Win=64173 - Nbtss: SESSION MESSAGE, Length =84 PacketType: SESSION MESSAGE, 0(0x00) + Flags: Add 0 to Length Length: 84(0x54) - Smb: C; Nt Transact, NT Query Security Description, FID = 0x4019 Protocol: SMB Command: Nt Transact 160(0xA0) + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS + SMBHeader: Command, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3A80 - CNTTransaction: WordCount: 19 (0x13) MaxSetupCount: 0 (0x0) Reserved: 0 (0x0) TotalParameterCount: 8 (0x8) TotalDataCount: 0 (0x0) MaxParameterCount: 4 (0x4) MaxDataCount: 0 (0x0) ParameterCount: 8 (0x8) ParameterOffset: 76 (0x4C) DataCount: 0 (0x0) DataOffset: 0 (0x0) SetupCount: 0 (0x0) Function: NT Query Security Description ByteCount: 11 (0xB) Pad1: Binary Large Object (3 Bytes) + NTQuerySecurityDescParameterBlock:
What you should notice is that within the NT Transact message, the MaxDataCount sent by the client to the server is “0.” This is the size of the buffer currently allocated by the client for the Security Descriptor data. If we then dig into the STATUS_BUFFER_TOO_SMALL message (the response from the server), we see this:
Frame: Number = 2, Captured Frame Length = 134, MediaType = ETHERNET Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-21-70-77-95-BC],SourceAddress:[00-17-94-4B-AC-43] Ipv4: Src = 192.168.1.11, Dest = 192.168.1.10, Next Protocol = TCP, Packet ID = 18417, Total IP Length = 120 Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=L2TP(1701), PayloadLen=80, Seq=426719751 - 426719831, Ack=1366185844, Win=65535 Nbtss: SESSION MESSAGE, Length =76 PacketType: SESSION MESSAGE, 0(0x00) + Flags: Add 0 to Length Length: 76(0x4C) Smb: R; Nt Transact, NT Query Security Description, FID = 0x4019 - NT Status: System - Error, Code = (35) STATUS_BUFFER_TOO_SMALL Protocol: SMB Command: Nt Transact 160(0xA0) + NTStatus: 0xC0000023, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_ERROR, Code = (35) STATUS_BUFFER_TOO_SMALL + SMBHeader: Response, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3A80 - RNTTransaction: WordCount: 18 (0x12) Reserved: 0 (0x0) TotalParameterCount: 4 (0x4) TotalDataCount: 0 (0x0) ParameterCount: 4 (0x4) ParameterOffset: 72 (0x48) ParamDisplacement: 0 (0x0) DataCount: 0 (0x0) DataOffset: 76 (0x4C) DataDisplacement: 0 (0x0) SetupCount: 0 (0x0) ByteCount: 5 (0x5) Pad1: Binary Large Object (1 Bytes) - QuerySecDescParameterBlock: SecurityDescriptorLength: 104 (0x68)
You should notice that in the server’s response, it’s telling the client that the Security Descriptor Length, which is the information the client requested, is 104 bytes in length. Obviously “0” isn’t big enough so the server is just informing the client what the size needs to be. The client then sends a new NT Query for the Security Descriptor:
Frame: Number = 3, Captured Frame Length = 142, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-17-94-4B-AC-43],SourceAddress:[00-21-70-77-95-BC] + Ipv4: Src = 192.168.1.10, Dest = 192.168.1.11, Next Protocol = TCP, Packet ID = 6397, Total IP Length = 128 + Tcp: Flags=...AP..., SrcPort=L2TP(1701), DstPort=Microsoft-DS(445), PayloadLen=88, Seq=1366185844 - 1366185932, Ack=426719831, Win=64093 - Nbtss: SESSION MESSAGE, Length =84 PacketType: SESSION MESSAGE, 0(0x00) + Flags: Add 0 to Length Length: 84(0x54) - Smb: C; Nt Transact, NT Query Security Description, FID = 0x4019 Protocol: SMB Command: Nt Transact 160(0xA0) + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS + SMBHeader: Command, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3AC0 - CNTTransaction: WordCount: 19 (0x13) MaxSetupCount: 0 (0x0) Reserved: 0 (0x0) TotalParameterCount: 8 (0x8) TotalDataCount: 0 (0x0) MaxParameterCount: 4 (0x4) MaxDataCount: 104 (0x68) ParameterCount: 8 (0x8) ParameterOffset: 76 (0x4C) DataCount: 0 (0x0) DataOffset: 0 (0x0) SetupCount: 0 (0x0) Function: NT Query Security Description ByteCount: 11 (0xB) Pad1: Binary Large Object (3 Bytes) + NTQuerySecurityDescParameterBlock:
Notice that the new client request has the MaxDataCount set to the value it received from the server – 104 bytes. With the buffer sized appropriately, the server then sends the data:
Frame: Number = 4, Captured Frame Length = 238, MediaType = ETHERNET Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-21-70-77-95-BC],SourceAddress:[00-17-94-4B-AC-43] Ipv4: Src = 10.33.10.22, Dest = 10.33.31.167, Next Protocol = TCP, Packet ID = 18420, Total IP Length = 224 Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=L2TP(1701), PayloadLen=184, Seq=426719831 - 426720015, Ack=1366185932, Win=65447 Nbtss: SESSION MESSAGE, Length =180 Smb: R; Nt Transact, NT Query Security Description, FID = 0x4019 Protocol: SMB Command: Nt Transact 160(0xA0) + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS + SMBHeader: Response, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3AC0 - RNTTransaction: WordCount: 18 (0x12) Reserved: 0 (0x0) TotalParameterCount: 4 (0x4) TotalDataCount: 104 (0x68) ParameterCount: 4 (0x4) ParameterOffset: 72 (0x48) ParamDisplacement: 0 (0x0) DataCount: 104 (0x68) DataOffset: 76 (0x4C) DataDisplacement: 0 (0x0) SetupCount: 0 (0x0) ByteCount: 109 (0x6D) Pad1: Binary Large Object (1 Bytes) - QuerySecDescParameterBlock: SecurityDescriptorLength: 104 (0x68) - SecurityDescriptor: OwnerSID: S-1-5-21-1697806599-1153585985-1472874943-33115 Unknown SID GroupSID: S-1-5-21-1697806599-1153585985-1472874943-513 Domain Users -- A global group that, by default, includes all user accounts in a domain. When you create a user a Revision: 1 (0x1) Sbz1: 0 (0x0) + SecurityDescriptorControl: 0x8004 OffsetToOwnerSID: 20 (0x14) Offset: 0x9A OffsetToGroupSID: 48 (0x30) Offset: 0xB6 OffsetToSacl: 0 (0x0) OffsetToDacl: 76 (0x4C) Offset: 0xD2 + OwnerSid: S-1-5-21-1697806599-1153585985-1472874943-33115 Unknown SID + GroupSid: S-1-5-21-1697806599-1153585985-1472874943-513 Domain Users -- A global group that, by default, includes all user accounts in a domain. When you create a user account in a domain, it is added to this group by default + Dacl: ACE Entries: 1
If you look at the time offset in a trace, you should see that the time from the initial request to the successful response takes almost no time at all and does not result in any problems. In fact, because this is happening at the SMB layer, TCP is not aware of the above transaction (study that OSI model again for additional information).
While Network Monitor can provide a wealth of information, sometimes the data you get may take you down the wrong path. Once you understand how SMB works, you can see how the information flows between the client and the server.
A list of SMB message codes can be found at http://msdn.microsoft.com/en-us/library/cc212457(PROT.10).aspx.
The latest version of Network Monitor is 3.2 and can be found at http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en.
Thanks and happy hunting!
- Michael Rendino
203 Microsoft Team blogs searched, 88 blogs have new articles in the past 7 days. 199 new articles found
hi michael,
i have a question, what happens when there is a pipe communication from your example ?
AFAIK, maxdatacount is the number of byte client reads from the pipe , in this case how does client determine the data to be read ?
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using RSS