Win7 (SMB1) oplock issues
- <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman";} span.EmailStyle15 {mso-style-type:personal; mso-style-noshow:yes; mso-style-unhide:no; mso-ansi-font-size:11.0pt; mso-bidi-font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->
Hi there,
I am observing an issue with Win7 oplock behavior (SMB1 protocol).Note: i am enforcing SMB1 protocol between Win7 client and Win7 server.
I just copied a file 20MB.doc ( remote write ) from win7 client to win7 server. ( I disabled SMB2 and SMB1 is the protocol used ).
scenario
- Win7 client opens the 20mb.doc on Win7 server and acquires a batch oplock
- Win7 client writes contents on to the file
- Win7 client reads the contest of the file
- Win7 client issues QPI File Basic Info request
- Win7 server breaks the batch oplock to L2 oplock
- Win7 client does seem to ACK the break
- Win7 server timed out after 1.2 seconds and responds back to QPI File Basic Info
- Win7 closes the handle
Questions
1. Why does a QPI (basic info ) break the batch oplock?
2. Why does win7 client does not respond to break ( batch to L2 ) ?
I have the tcpdump ( 23MB ). I don't know where to attach.
Any help is much appreciated.
All Replies
Hi,
Thanks for your question. One of our team member will work on your question and respond to you when the investigation is finished.
Thank!
Hongwei Sun -MSFTGood morning, and thanks for your post regarding the [MS-SMB] protocol specification. My name is Bill Wesse, from the Protocol Support team; I will be your contact for the issue you raised concerning Win7 SMB/oplock behavior.
You indicated you have a network capture of the oplock behavior. I would deeply appreciate it if you would email that capture to 'dochelp@microsoft.com' (title: Win7 (SMB1) oplock issues).
Regards,
Bill Wesse
Escalation Engineer- Good morning! I neglected to ask about the specifics on client activity. Could you advise me of the sequence of operations on the client? That is, what version of Office/Word are you using on the client to open the file, or are you using something else?
Regards,
Bill Wesse
Escalation Engineer - I have sent the traces to the specified email address.
I am using copy.exe to copy a file from Win7 client to Win7 server ( dos utility ).
To clarify on the sequence of the client activities
1. From Win7 client's console i executed the following commands to disable SMB2
sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled
2. Power cycle Win7 client
3. After reboot, On Win7 client console
net use z: \\<Win7 server>\<share> /USER:Administrator ( Win7 client )
copy 20mb.doc z:\
Regards,
Mohan Thanks Mohan - I expect to run the test later today (I have some VM configurations to accomplish first).
Regards,
Bill Wesse
Escalation EngineerMohan - I have tested the steps you provided (copy a 20MB file from Windows 7 to Windows 7, using the copy command). I tested on 2 Virtual Machines (Windows 7 Ultimate <release>), with SMB2 disabled.
The SMB Transact2 / Query Path Info / Query File Basic Info should not be causing the Windows 7 target system (server) to issue an Oplock break (SMB Locking Andx). Also, the client should respond to the Oplock break with a follow up SMB Locking Andx with LockType OPLOCK_RELEASE flag (0x02) set.
Unfortunately, my setup did not reproduce the odd oplock behavior you are seeing. My traces do not show any file read operations, plus all of the Transact2 (Query Path/File/FS info, and set file info all occurred before the writes, and nothing after).
Did I miss a step?
- net use z: \\<Win7 server>\<share> /USER:Administrator ( Win7 client )
- copy 20mb.doc z:\
==============================================================================
BTW - another way to disable SMB2 is shown in the workaround section of the following knowledge base article:You encounter poor performance when you use the SMB 2.0 protocol to perform network-related operations, such as ADMT migration, on computers that are running Windows Server 2008 or Windows Vista
http://support.microsoft.com/kb/950836/EN-US==============================================================================
References:MSDN / MSDN Library / Win32 and COM Development / Windows Development (General) / Specifications / CIFS
CIFS Packet Formats
http://msdn.microsoft.com/en-us/library/dd327709.aspx[MS-CIFS]: Common Internet File System (CIFS) Protocol Specification
http://msdn.microsoft.com/en-us/library/ee442092.aspx[MS-CIFS]: 3.3.4.2 Server is Notified of an OpLock Break
http://msdn.microsoft.com/en-us/library/ee441998.aspx[MS-CIFS]: 3.2.5.43 Receiving an OpLock Break Notification
http://msdn.microsoft.com/en-us/library/ee441694.aspxRegards,
Bill Wesse
Escalation Engineer- Mohan - right after I posted the previous, I realized that I need to redo the test with 'copy /v 20mb.doc z:\'. The verify operation should account for the reads & additional query info calls. I will get to this first thing tomorrow morning (out of time today).
Regards,
Bill Wesse
Escalation Engineer - Thanks Bill
To clarify on my exact windows version, it is Windows 7 Enterprise Version 6.1 ( Build 7600 ).
>>Unfortunately, my setup did not reproduce the odd oplock behavior you are seeing. My traces do not show any file read operations, plus all of the Transact2 (Query >>Path/File/FS info, and set file info all occurred before the writes, and nothing after).
>>Did I miss a step?
I did the test couple of times so the copy command prompted for overwrite ( Yes/No/xxx). May be overwriting an existing file would trigger these reads and trans2 messages. I did not use /v option. Good morning Mohan. I have retested, and duplicated the oplock break behavior - but not exactly as you have seen. The server issued an oplock break to L2, which was replied to properly by the client.
I will email you the captures (both Netmon .cap and tcpdump .pcap). I have additional investigations to do - specifically, in the capture, there is a second break to no oplock.
1. server sends (Locking Andx) oplock break to Level 2
2. client response to Locking Andx
3. server sends (Locking Andx) oplock break to none
4. no client response in the capture, I will be retesting to ensure no dropped packets
Regards,
Bill Wesse
Escalation Engineer- Thanks for you update Bill.
I am definitely seeing the problem consistently.
1. Would Win7 enterprise server behave different from Win7 ultimate ( i am using enterprise 6.1)?
2. Would copy.exe behave differently for text file and doc file ( i am using doc file )?
Could you try copying a MS doc file on a Win7 enterprise client and server ?
Mohan
You are very welcome - my answers are in-line below.
1. Would Win7 enterprise server behave different from Win7 ultimate ( i am using enterprise 6.1)?
They should behave the same way; and I will verify that.
2. Would copy.exe behave differently for text file and doc file ( i am using doc file )?
The file extension should make no difference in the server or redirector. The trace you sent indicates no attempts to open IStorage streams in the target file, or anything indicitive of filter driver intervention - other than the Locking Andx oplock break.
Regardless, I will test also with a doc file.
Hopefully my test setup will misbehave again, so I can yank more info (using Procmon, etc.). I will status you by tomorrow morning at the latest.
Regards,
Bill Wesse
Escalation Engineer- Good morning Mohan. So far - after numerous attempts, I have been able to get only one instance of an oplock break from the server (Windows 7 Ultimate and Windows 2008 R2 Enterprise). I tested with both .txt and .doc files - no differences (which is what I expected).
This is inconvenient for both of us, of course. I will continue to test - while monitoring the file on the server with Procmon. I suspect there is something going on in the server service (netsvcs) that is triggering this - oplock breaks are handled asynchronously in the file server service.
Is the server your are using under any kind of traffic load? Perhaps there is another condition necessary to cause this on a consistent basis.
Regards,
Bill Wesse
Escalation Engineer - Bill,
Thanks for the update.
>>I have been able to get only one instance of an oplock break from the server (Windows 7 Ultimate and Windows 2008 R2 Enterprise).
I am seeing this problem only with win7 ultimate client and win7 ultimate server ( i don't see this problem with any other severs like win2003 and win2008). Are you trying Win7 ultimate client and win7 ultimate server ?
>> I tested with both .txt and .doc files - no differences
Thanks for confirming this.
>>Is the server your are using under any kind of traffic load?
This server is in a private network and win7 ultimate is the only client accessing it.
Regards,
Mohan - Mohan, I am indeed using Win7 Ultimate on both ends of the file copy - private network, no other systems involved. It happened once, then stopped - with no system reconfigurations. I will just have to keep slugging away at it.
Regards,
Bill Wesse
Escalation Engineer - Good day Mohan - I will be emailing you some trace utility scripts within the next day or so. We have some setup & test to perform here first (these are new tracing scripts from our developers, that nab plenty from the server / redirector & file system drivers).
Thanks for your patience!
Regards,
Bill Wesse
Escalation Engineer Hello Mohan - please let me know if you run into any snags with the data gathering tools. I would be glad to help if needed.
Regards,
Bill Wesse


