Prev: Where are the Vista/ Windows7 newsgroups?
Next: FAX Console not printing
From: John Wunderlich on 9 Mar 2010 11:32
Bo Berglund <boberglund(a)myotherhome.sec> wrote in
news:c5ubp59ipeae4uqo524mai6divffqcscaj(a)4ax.com:

>> My first step would be to eliminate all mapped network drives,
>> particularly ones that map to XP Home and Pro machines. Instead,
>> use
>
> My problems happen on our corporate LAN and there are absolutely
> no XP-Home machines there. All mapped drives (I have 4) are
> towards Windows 2003 Servers, so these should be OK.

OK. This is new information. Your problem still seems to be associated
with re-attaching to a network mapping which has apparently gone idle.

>
>> shortcuts to a UNC path or a UNC path itself to access a network
>> resource. The advantage here is that accessing "My Computer"
>> will not attempt to connect to these networked drives and
>> possibly eliminate your delay. (Mapped drives are shown under "My
>> Computer"
>
> I never ever use "My Computer" or "My Documents".....

Maybe not directly but "select the dropdown combobox at top of dialog"
brings up a window that contains "My Computer and the lettered drives
within. "Scroll the folder list in Windows Explorer until network
drive..." (same thing); "Dir I:" references network drive; MS Word
lockup may be different... are you editing a file on a network drive at
the time? It could be when "autosave" kicks in it accesses contents of
"My Computer" behind the scenes.

I still would eliminate network drive mapping in favor of UNC/shortcut
access, at least temporarily, in an attempt to discover which network
connection is having problems.

John-John's suggestion of not allowing network card to power down also
has merit.

HTH,
John

From: Bo Berglund on 9 Mar 2010 12:22
On Tue, 09 Mar 2010 08:29:01 -0400, John John - MVP
<audetweld(a)nbnot.nb.ca> wrote:

>Bo Berglund wrote:
>Check the Power Management setting on the network adapter's properties
>and see if it is set to 'Allow the computer to turn off the device to
>save power', maybe the adapter gets turned off while you are working.
>

I don't think it is a powerdown problem because whenever the lockup
happens (it lasts for 3 minutes) then I can use my web browser just
fine via the same NIC and I can open a command window and ping
successfully the server on which my mapped drive resides.

So it seems that neither my own nor the server's NIC is in fact dead,
it is just the UNC name handling that has gone haywire....

--

Bo Berglund (Sweden)
From: Bo Berglund on 9 Mar 2010 12:31
On Tue, 09 Mar 2010 16:32:58 GMT, John Wunderlich
<jwunderlich(a)lycos.com> wrote:

>Bo Berglund <boberglund(a)myotherhome.sec> wrote in
>news:c5ubp59ipeae4uqo524mai6divffqcscaj(a)4ax.com:
>
>>> My first step would be to eliminate all mapped network drives,
>>> particularly ones that map to XP Home and Pro machines. Instead,
>>> use
>>
>> My problems happen on our corporate LAN and there are absolutely
>> no XP-Home machines there. All mapped drives (I have 4) are
>> towards Windows 2003 Servers, so these should be OK.
>
>OK. This is new information. Your problem still seems to be associated
>with re-attaching to a network mapping which has apparently gone idle.

As I said above this happens at work, so today (I'm back home now) I
made an experiment:
I created a Delphi application that has a timer inside and every time
this times out I run a FileExist call on a file that I have put on the
server (\\server\share\path\filename)

The timer interval is set to 1 second and I read the current time tick
before and after the FileExist call. Then I compute the execution time
and if it is longer than 2 s I log the event.

During 5 hours of monitoring it detected 4 events of this kind, each
lasting between 174 and 186 seconds....

>
>I still would eliminate network drive mapping in favor of UNC/shortcut
>access, at least temporarily, in an attempt to discover which network
>connection is having problems.

Well, the test described above uses a unc path to the file but it does
not help....

>John-John's suggestion of not allowing network card to power down also
>has merit.
>
As I replied to him, while the UNC problem is on I can use my own NIC
for standard TCP/IP connections like web browsing and ping. And the
server I am trying to access by UNC responds immediately to ping
requests. So its NIC is also not dead.

So it is definitely something amiss with the UNC handling.

I downloaded and installed Wireshark in order to try and see what is
going on on my NIC, but unfortunately it records way too much data for
me to make anything sensible out of.....

--

Bo Berglund (Sweden)
From: John Wunderlich on 9 Mar 2010 17:22
Bo Berglund <boberglund(a)myotherhome.sec> wrote in
news:7v0dp59iftllhk1ce0h4l8ql3ntr6ibafm(a)4ax.com:

> So it is definitely something amiss with the UNC handling.
>
> I downloaded and installed Wireshark in order to try and see what
> is going on on my NIC, but unfortunately it records way too much
> data for me to make anything sensible out of.....
>
>

It would probably help a little with the volume of data to only
capture the data of interest. When you start Wireshark, click the
"Capture Option" and where you see "Capture Filter", enter a filter of:

host 192.168.1.123 && (port 135 || port 137 || port 138 || port 139 || port 445)

Where you substitute the IP address of your server where you see "192.168.1.123"
This still may capture a lot of data but once you hit your hangup,
you can examine the last of the capture.

HTH,
John
From: Bo Berglund on 10 Mar 2010 15:22
On Tue, 09 Mar 2010 22:22:12 GMT, John Wunderlich
<jwunderlich(a)lycos.com> wrote:

>Bo Berglund <boberglund(a)myotherhome.sec> wrote in
>news:7v0dp59iftllhk1ce0h4l8ql3ntr6ibafm(a)4ax.com:
>
>> So it is definitely something amiss with the UNC handling.
>>
>> I downloaded and installed Wireshark in order to try and see what
>> is going on on my NIC, but unfortunately it records way too much
>> data for me to make anything sensible out of.....
>>
>>
>
>It would probably help a little with the volume of data to only
>capture the data of interest. When you start Wireshark, click the
>"Capture Option" and where you see "Capture Filter", enter a filter of:
>
>host 192.168.1.123 && (port 135 || port 137 || port 138 || port 139 || port 445)
>
>Where you substitute the IP address of your server where you see "192.168.1.123"
>This still may capture a lot of data but once you hit your hangup,
>you can examine the last of the capture.
>

Thanks for this! It really cut back on the info being recorded.

I have kept my test application running all day while at the same time
letting Wireshark record with your filter in place. I have had more
than 10 blackouts during this time each lasting 3 minutes. :-(

With the log from my test application I can see the timestamp of the
probelm and locate the right spot in the Wireshark capture file.

The result is really strange. Here are events from one of the lockups:

2612 13:02:03.660702 172.30.176.35 172.30.177.70 SMB Tree
Disconnect Request
2613 13:02:03.660967 172.30.177.70 172.30.176.35 SMB Tree
Disconnect Response
2614 13:02:03.661084 172.30.176.35 172.30.177.70 SMB Logoff
AndX Request
2615 13:02:03.661523 172.30.177.70 172.30.176.35 SMB Logoff
AndX Response
2616 13:02:03.661616 172.30.176.35 172.30.177.70 SMB Tree
Disconnect Request
2617 13:02:03.661846 172.30.177.70 172.30.176.35 SMB Tree
Disconnect Response

The above is where the blackout starts.
After 2 minutes there are a bit of activity from KeepAlive packets:

2623 13:04:03.100948 172.30.177.14 172.30.176.35 TCP [TCP
Keep-Alive] microsoft-ds > fg-fps [ACK] Seq=158703 Ack=117676
Win=63014 Len=1
2624 13:04:03.100999 172.30.176.35 172.30.177.14 TCP [TCP
Keep-Alive ACK] fg-fps > microsoft-ds [ACK] Seq=117676 Ack=158704
Win=36451 Len=0 TSV=4957644 TSER=16429060
2625 13:04:03.802338 172.30.177.70 172.30.176.35 TCP [TCP
Keep-Alive] microsoft-ds > abcvoice-port [ACK] Seq=2848 Ack=6057
Win=65536 Len=1
2626 13:04:03.802389 172.30.176.35 172.30.177.70 TCP [TCP
Keep-Alive ACK] abcvoice-port > microsoft-ds [ACK] Seq=6057 Ack=2849
Win=145688 Len=0 TSV=4957650 TSER=163213097

Then this happens 2.5 minutes into the blackout:
2627 13:04:29.636063 172.30.177.70 172.30.176.35 TCP
microsoft-ds > abcvoice-port [RST, ACK] Seq=2849 Ack=6057 Win=0 Len=0

And finally the end of blackout is signalled by these packets:
2628 13:04:58.511867 172.30.176.35 172.30.177.14 SMB Trans2
Request, QUERY_PATH_INFO, Query File Basic Info, Path: \Bosse
2629 13:04:58.512593 172.30.177.14 172.30.176.35 SMB Trans2
Response, QUERY_PATH_INFO
2630 13:04:58.513369 172.30.176.35 172.30.177.14 SMB Trans2
Request, FIND_FIRST2, Pattern: \Bosse\CheckFile.txt
2631 13:04:58.514038 172.30.177.14 172.30.176.35 SMB Trans2
Response, FIND_FIRST2, Files: CheckFile.txt

From now on the network is OK until the next blackout, which can
happen anytime....
All blackouts last 3 minutes within about 5 seconds and they have the
same basic structure as shown above. Sometimes there are a few TCP
packets inside the blackout (the .... section above) but most often
there is nothing the first 2 minutes until the KeepAlive starts.

What can I do to find out why there are disconnect and logoff requests
posted to the domain controller (172.30.177.70)???
And most importantly to stop it from happening....

--

Bo Berglund (Sweden)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Where are the Vista/ Windows7 newsgroups?
Next: FAX Console not printing