Long standing Network File Share error..

I've had this annoyance for a long time and today thought I'd see if
sometime could be done about it.

It doesn't effect performance or use, but does fill up the event logs.

For a number of a reasons, (perfectionist?), I want my event logs to remain
as "clean" as possible. By "clean", I mean no warnings and such unless they
are legit. (I.e., occassionaly I get a warning when system time doesn't
automatically update itself over the network. That is something small also,
but I consider that "legit".)

My file shares are over a workgroup consider of Windows and Linux computers.
They are setup correctly. For a while, I just wrote off this event logging
as probably some minor issue involving Samba, but looking at closely today
discovered that it occurs with the Windows machines too.

Event ID: 3019
MrxSMB: 'The redirector failed to determine the connection type."

WHAT MICROSOFT HAS TO SAY ABOUT IT:
--------------------------------------------------------------------
http://support.microsoft.com/default...b;en-us;315244

SYMPTOMS
When you map a network drive to a local share, the following error message
may be reported in the system event log:
Event ID: 3019
Source: MRxSmb
Description: The redirector failed to determine the connection type.

CAUSE
This behavior can occur when NetBIOS over TCP/IP (NetBT) attempts to query
the destination device (in this case, the loopback adapter) for network
speed. The loopback adapter does not handle speed negotiation and therefore
cannot negotiate the speed.

This behavior is associated only with the TCP/IP protocol because TCP/IP is
the only protocol that uses the Loopback adapter.

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products
that are listed in the "Applies to" section.

MORE INFORMATION
This error message is only informational. You can safely ignore it.

APPLIES TO
[Basically all WinXP and Win2003 versions.]
--------------------------------------------------------------------

According to Microsoft, this is a "feature" until they fix it. Well, this
"feature" has been around for years now, so I'm not holding my breath on a
"fix" anytime soon.

I found some people offering "fixes" by googling, but their "fixes" come off
the me as shooting from the hip in the dark. (They involve registry entries
which don't directly have anything to do with filesharing and, often,
cripple functionality.)

With lack a real "fix", is it possible to have these events not even be
logged through the registry? I'd rather have them just be completetly
ignored from being logged all-together until a real "fix" becomes available.

Thanks...

You see message 3019 in the System Event log when you map a network
drive or connect to a network share by using a UNC path name in Windows
XP Service Pack 2
http://support.microsoft.com/kb/889000

John

Erscn wrote:

> I've had this annoyance for a long time and today thought I'd see if
> sometime could be done about it.
>
> It doesn't effect performance or use, but does fill up the event logs.
>
> For a number of a reasons, (perfectionist?), I want my event logs to remain
> as "clean" as possible. By "clean", I mean no warnings and such unless they
> are legit. (I.e., occassionaly I get a warning when system time doesn't
> automatically update itself over the network. That is something small also,
> but I consider that "legit".)
>
> My file shares are over a workgroup consider of Windows and Linux computers.
> They are setup correctly. For a while, I just wrote off this event logging
> as probably some minor issue involving Samba, but looking at closely today
> discovered that it occurs with the Windows machines too.
>
> Event ID: 3019
> MrxSMB: 'The redirector failed to determine the connection type."
>
> WHAT MICROSOFT HAS TO SAY ABOUT IT:
> --------------------------------------------------------------------
> http://support.microsoft.com/default...b;en-us;315244
>
> SYMPTOMS
> When you map a network drive to a local share, the following error message
> may be reported in the system event log:
> Event ID: 3019
> Source: MRxSmb
> Description: The redirector failed to determine the connection type.
>
> CAUSE
> This behavior can occur when NetBIOS over TCP/IP (NetBT) attempts to query
> the destination device (in this case, the loopback adapter) for network
> speed. The loopback adapter does not handle speed negotiation and therefore
> cannot negotiate the speed.
>
> This behavior is associated only with the TCP/IP protocol because TCP/IP is
> the only protocol that uses the Loopback adapter.
>
> STATUS
> Microsoft has confirmed that this is a problem in the Microsoft products
> that are listed in the "Applies to" section.
>
> MORE INFORMATION
> This error message is only informational. You can safely ignore it.
>
> APPLIES TO
> [Basically all WinXP and Win2003 versions.]
> --------------------------------------------------------------------
>
> According to Microsoft, this is a "feature" until they fix it. Well, this
> "feature" has been around for years now, so I'm not holding my breath on a
> "fix" anytime soon.
>
> I found some people offering "fixes" by googling, but their "fixes" come off
> the me as shooting from the hip in the dark. (They involve registry entries
> which don't directly have anything to do with filesharing and, often,
> cripple functionality.)
>
> With lack a real "fix", is it possible to have these events not even be
> logged through the registry? I'd rather have them just be completetly
> ignored from being logged all-together until a real "fix" becomes available.
>
> Thanks...
>
>

"John John" <audetweld@nbnet.nb.ca> wrote in message
news:OOtgfZDXHHA.4880@TK2MSFTNGP05.phx.gbl...
> You see message 3019 in the System Event log when you map a network drive
> or connect to a network share by using a UNC path name in Windows XP
> Service Pack 2
> http://support.microsoft.com/kb/889000
>

Again:

--------------------------------------
STATUS
Microsoft has confirmed that this is a problem in the Microsoft products
that are listed in the "Applies to" section.

(There is also a "note"):

Note This problem is resolved in the file Tcpip.sys version 5.1.2600.2505
and later versions.
--------------------------------------

I just checked my tcpip.sys and it is 2685. It doesn't look like it was
"resolved" to me.