2

We run a server (Win2k) with several tools on it. The workstations (XP) all have their PATH set to include that folder.

When we run a tool (e.g. grep) from a DOS box on a workstation, sometimes there is a long delay (up to a minute) before the tool runs. After the delay everything happens as normal. The subsequent runs don't have the delay, even when run from another DOS box.

Any ideas?

* MORE DETAILS*

This scenario always produces the delay. We are working on a tool in a particular folder on the server. The tool is edited and compiled on one workstation in a DOS box that is positioned in the folder where the tool is built, and then run, the delay is always there. The following run is fine. So regenerating the EXE results in the delay.

Oliver Salzburg
  • 86,445
  • 63
  • 260
  • 306
rossmcm
  • 1,576
  • 5
  • 34
  • 59
  • 1
    Time to bust out Procmon. . . – surfasb Aug 18 '11 at 05:33
  • So if you move it to a different directory, there is no more delay? If so, then I wonder if the delay might be related to loading other files in the first directory (prior to re-locating). – Randolf Richardson Aug 18 '11 at 17:11
  • I know was a while ago and you're not still playing with this but anyhow, As a diagnosic step, try set path= then run the command. – barlop Jun 12 '12 at 11:07

3 Answers3

3

Windows is logging into the server to see if the command you want is in that folder. After the first time, it's already logged in. We have the same issue opening documents and folders on the server every day.

You may be able to speed it up (in Windows) by running the following command during login:

Net Use \\ServerName

The command will take a minute to process, but it may happen as a background task that the user won't notice. However, I don't know if this will cause "too many connections" issues in your case.

Hand-E-Food
  • 4,911
  • 1
  • 19
  • 38
  • See the additional details I have added to the question. The path is not involved as the EXE is in the current folder. – rossmcm Aug 18 '11 at 01:24
1

There could be a network location in your path that's timing out -- when you try to run a program from DOS or from the "Run" option in the Start Menu, if the executable or script/batch file isn't first found in the current working directory then each directory listed in the PATH is searched as well.

You can type "PATH" at the DOS window to see if anything outside of drive C: is in the list. If not, then the next suspects could be:

  1. First-time loading of a very large program can be an issue too (because subsequent uses will come from a cache). Do you have a link to the "grep" tool you're using? If it's a small stand-alone program, then this shouldn't be an issue

  2. Slow anti-virus software (very rare)

  3. Disk failures are beginning to develop (get a full backup as soon as possible)

  4. Excessive fragmentation in your file system (easily remedied by running Disk Defragmenter which can be found in: Start Menu -> Programs -> Accessories -> System Tools -> Disk Defragmenter)

Randolf Richardson
  • 14,634
  • 39
  • 52
  • See the additional details I have added to the question. We chcked the path but it happens when the EXE is in the current folder so presumably the path would not be involved. It seems to be some sort of caching issue. – rossmcm Aug 18 '11 at 01:27
  • +1 for antivirus. Does the server run antivirus software? – boot13 Aug 19 '11 at 22:49
1

grep is not a Win32 command but a Unix one, so you may have invoked the Unix subsystem which is present in older versions of Windows.

A special system process must be started to support these Unix commands which can explain for the initial delay. I can't remember the name of the process, but if you use something like Process Explorer, you can see it starting.

Maybe this TechNet series can be of some help. Details about the subsystem can be found in the "Windows Internals" book.

billc.cn
  • 7,099
  • 20
  • 36
  • See the additional details I have added to the question. It's not the unix grep - it's the Borland one. And it's not confined to grep - that was an example. – rossmcm Aug 18 '11 at 01:25
  • Then it must be the time required to find and login to the server as @Hand-E-Food suggested. You can put that `net use` into a bat file that runs at startup to speed-up future access. – billc.cn Aug 18 '11 at 01:31
  • @Hand-E-Food, billc.cn - that hasn't solved it. – rossmcm Aug 18 '11 at 05:19
  • According to the documentation of [CreateProcess ()](http://msdn.microsoft.com/en-us/library/ms682425.aspx), the current working directory is consulted way earlier than `%PATH%`, so the delay should be caused by something in the current directory. Maybe it's antivirus or expired network connection. – billc.cn Aug 18 '11 at 23:37