Wireshark mailing list archives
Re: Slowdown after mounting DFS network drives
From: Kevin Cullimore <kcullimo () runbox com>
Date: Wed, 07 Apr 2010 17:05:49 -0400
On 4/7/2010 11:26 AM, János Löbb wrote:
Folks, Thanks a lot for all your comments. Now I see more clearly :-) For system trace tool - on Windows - I was suggested to use FileMon: <snip>The Sysinternals FileMon utility (Filemon.exe) monitors and displays file system activity on the computer in real time. When this problem occurs, multiple error messages that resemble the following are logged in the FileMon log file: 589 2:54:14 PM wscript.exe:2212 QUERY INFORMATION C:\WINNT\System32\*wshENU.DLL* NOT FOUND Attributes: Error</snip> Thanks again,
If you're stuck with windows, utilities written by Mark Russinovich generally provide you with more visibility than competing alternatives. Separately, do keep in mind that Network Monitor allows you to filter by process ID.
János On Apr 7, 2010, at 10:35 AM, M K wrote:Aha. You have hit on something when you said "possible culprit applications to determine the system calls they are making (and hence trigger the network traffic you see)." What system trace tools do you suggest to help perform the analysis for these system calls? Currently I am using multiple tools that provide some sort of visibility and then cross-referencing the results. I am also reducing the number of apps as a process of elimination. Or, to maybe put it another way, does anyone have suggestions for ethical apps (OS, Word processing, spreadsheet, browser, etc) ? I have had way too many experiences with apps acting otherwise in the background. Thanks for any insight.On 4/6/10, Martin Visser <martinvisser99 () gmail com <mailto:martinvisser99 () gmail com>> wrote:Also remember in troubleshooting these issue, that what is seen on thenetwork (via Wireshark) is only part of the picture. You should try to marry network traffic with activity or events seen on the workstation. Sometimethis will be invisible to you, however you might need to workthrough the scripts or startup applications, as well look at logs (or on windowsmachines,the event viewer). Sometimes you might have opportunity to increasethe log verbosity (to a debug level) or even use system trace tools onpossible culprit applications to determine the system calls they are making(and hence trigger the network traffic you see).As has been stated the client is choosing to wait between server requests. The server always responds promptly, with what it believes to be the rightanswer. The client seems not to be satisfied and hence tries again. Notknowing what the client is making visible to the user at this time (or its effect on the start process or applications) makes further diagnosis on ourpart pretty much speculative. Regards, Martin MartinVisser99 () gmail com <mailto:MartinVisser99 () gmail com>On Wed, Apr 7, 2010 at 12:54 AM, Kevin Cullimore <kcullimo () runbox com <mailto:kcullimo () runbox com>>wrote:On 4/6/2010 7:14 AM, Ian Schorr wrote:On Tue, Apr 6, 2010 at 5:19 PM, Kevin Cullimore<kcullimo () runbox com <mailto:kcullimo () runbox com>>wrote:That data would appear to be insufficient in isolation. To their unlikely credit, Microsoft maintains decent documentation as far as their protocol stacks are concerned. Conjoining both your capture and knowledgebase articles referencing their networking client behavior could result in an argument more difficult to deny/refute.As several people have mentioned, there doesn't appear to be anything to take back to the CIFS server admin. The client appears to be 100% behind the search for the DLLs and the timeout inbetween each attempt. The CIFS server isn't doing anything to trigger this (except existing as a system serving a mapped drive) and so can't be considered responsible for the problem. The problem exists on the 10.84.10.173 PC and needs to be resolved there.This may well be the best summary of the actual problem. Often, one needs total buy-in and affirmation from the sever admin in order to inspire those responsible for the client software to take appropriate action (the "no other choice but to stop practicing denial and fix the problem" scenario).-Ian___________________________________________________________________________Sent via: Wireshark-users mailing list<wireshark-users () wireshark org <mailto:wireshark-users () wireshark org>>Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe___________________________________________________________________________Sent via: Wireshark-users mailing list <wireshark-users () wireshark org <mailto:wireshark-users () wireshark org>>Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org ?subject=unsubscribe-- All that is necessary for evil to succeed is that good men do nothing. ~Edmund Burke ___________________________________________________________________________Sent via: Wireshark-users mailing list <wireshark-users () wireshark org <mailto:wireshark-users () wireshark org>>Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe___________________________________________________________________________ Sent via: Wireshark-users mailing list<wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Slowdown after mounting DFS network drives, (continued)
- Re: Slowdown after mounting DFS network drives Bill Meier (Apr 05)
- Re: Slowdown after mounting DFS network drives János Löbb (Apr 05)
- Re: Slowdown after mounting DFS network drives M Holt (Apr 05)
- Re: Slowdown after mounting DFS network drives Andrew Hood (Apr 05)
- Re: Slowdown after mounting DFS network drives Kevin Cullimore (Apr 06)
- Re: Slowdown after mounting DFS network drives Ian Schorr (Apr 06)
- Re: Slowdown after mounting DFS network drives Kevin Cullimore (Apr 06)
- Re: Slowdown after mounting DFS network drives Martin Visser (Apr 06)
- Re: Slowdown after mounting DFS network drives M K (Apr 07)
- Re: Slowdown after mounting DFS network drives János Löbb (Apr 07)
- Re: Slowdown after mounting DFS network drives Kevin Cullimore (Apr 07)
- Re: Slowdown after mounting DFS network drives M K (Apr 08)
- Re: Slowdown after mounting DFS network drives János Löbb (Apr 05)
- Re: Slowdown after mounting DFS network drives Bill Meier (Apr 05)
- Re: Slowdown after mounting DFS network drives Ian Schorr (Apr 06)