1

What tools (out of the box or otherwise) do you utilize to give useful/verbose information about what might be causing an issue with windows sharing?

I have a specific example below, but I'd like to see some general answers for how to collect data on the performance/stability characteristics of windows shares.

Edit: As Izzy noted below, my specific example might be indicating a deeper issue, so I am looking for some specific tools/logs I can look at to get a better indication of what might be occurring, the example is just there to show one scenario.

Edit2: Sadly, I never found out why this was occurring. We rolled back in time to a "known good state", and removed all traces of antivirus software from the machine. This is largely the same as "yep, reinstall".
Thus I'm marking John's as the correct answer, albeit a bit frustrated I never was able to find any tools for troubleshooting Windows sharing issues.


Specific example:

I have created a regular smb share (not DFS) on a Windows 2008 server, and the share is normally accessible by the clients (thus, the permissions as created seem to be a non-issue)

However, after a random amount of time (and perhaps accesses against the share), that share disappears for the client, and becomes inaccessible over the network.

However, the server is not busy at all, and seems to happily accept requests for other network services without a hitch. Rebooting the server will make the share accessible once again until the problem resurfaces shortly thereafter.

The general System/Application/Security event logs show nothing out of the ordinary.

Kevin Radcliffe
  • 135
  • 6
  • I bet you're going to find out in the end that this is a much deeper issue than the surface symptom, file sharing – Izzy Jul 01 '09 at 15:46
  • Yes, good point, which is part of why I wanted to see if there were tools for troubleshooting. I'm hoping one of them might lead me to an insight into another, deeper problem – Kevin Radcliffe Jul 01 '09 at 17:39
  • Can you access the administrative shares during the time that you can't access the other ones? – MathewC Jul 01 '09 at 15:45
  • The "server" service is the traditional service that handles this. I would be interested to know what happens if you restart this, although I'm not sure if that's what it's called on 2008 – MathewC Jul 01 '09 at 15:52
  • Good point - even c$, is that accessible? – Izzy Jul 01 '09 at 15:53
  • I don't have access to the server at the moment, but yes, I believe admin shares (C$,D$) were unaffected. My main issue is that I can't seem to get feedback from the system to even give me the possibilities of what is wrong. I believe restarting the server service had no effect. I went through a lot of hunches and intuitive guesses, but ultimately, I wondered if there were any tools (or just a plain old log I couldn't find) that might give me some harder data. – Kevin Radcliffe Jul 01 '09 at 17:44
  • Alright. If administrative shares are working then it's not: Server availability, and it's not the service crashing. It's something unique about that share, or the users accessing it. – MathewC Jul 02 '09 at 12:21

2 Answers2

0

Can you even ping the server from the client when you can't access the share? If not, it sounds like a connectivity issue. If so, then it sounds like something on the server itself, perhaps some kind of Max Connections thing.

Adam Brand
  • 6,057
  • 2
  • 28
  • 40
  • Yes, good thought, but all other network services were responding to requests (including ping). The server seemed not busy, and responded quickly to other requests. – Kevin Radcliffe Jul 01 '09 at 17:45
0

I don't use either 2008 or Vista but have experienced the same problem with earlier versions (95 to XP). What happened in those cases was after a period of inactivity Windows stops checking the connection. That is when Explorer makes the drives appear as if disconnected. What should happen is the connection gets picked up when required and the world is a happy place. On just a few machines that connection got broken while it was idle and Windows was unable to pick up the connection and was too dumb to realise it had to reestablish it.

Now for the bad news. I was never able to solve the problem and in every case the only option was to reinstall Windows on the client, which had a 100% success rate.

My guess as to the underlying cause is some kind of corruption at a very low level. Too low to be able to repair it, even by uninstalling and reinstalling the network stack. Of course it might also have been a faulty registry key, who knows?

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
  • 1
    Similar to the above, this is one case where I just wish Windows were a big more verbose (or rather that I was good at finding out where the output is going). I'm more familiar with Windows than *nix, but when I've used Linux regularly in the past, there is almost always some way to get verbose output (which we can then plug into Google and get some help).. This makes this type of issue on Windows so frustrating, because until you figure out the necessary log-fu, all info about what's wrong seems to go into a black hole, and you're left with "Okay, reinstall Windows"Sorry for the comment rant – Kevin Radcliffe Jul 02 '09 at 15:22
  • Exactly. No information means little or no chance of debugging. – John Gardeniers Jul 02 '09 at 21:47