Re: Network Drive Issue

"Gary Chanson" <gjchanson@xxxxxxxxxxxxxxxxxxxx> wrote in message

> > I consider this too. Trust me. I ran CHKSDK on drive G:
> CHKDSK isn't sufficient to determin the heath of the drive. It's
job is
> determining the health of the file system. You should run a good
hard drive
> diagnostic on the drive.

Yes, I realize CHDSK isn't low level diagnostic check.

> > If the hard ware was "locked" due to some marginal sector retry,
then I
> > would think that accessing the drive via G: would be locked as well.
> > wouldn't matter. This was the first thing I checked once I saw it
> > locking on the mapped drive.
> Maybe, but It might be masked by caching. The problem sounds
enough like
> a hard drive problem that it's worth testing the drive carefully.

Good point, no doubt for piece of mind, worth looking into more for

But this still doesn't make sense. If "info" was cached, then the
request were completed and the "lock" should of ended. As Pavel
indicated, you would expect some OS level device I/O error logging too
at this point.

But overall, it doesn't explain why a API call:

GetDiskFreeSpaceEx("S:\\",,,) --> locks up
GetDiskFreeSpaceEx("G:\\",,,) --> no lock up

and the only relationship is S: mapped to G$

As I mentioned, if I disable the network, the above works but with a
small <1 second delay. This is related to some network device driver

Incidentally, the IntelliSense thread indicated that a FEACP.DLL can be
renamed to disable it in VS 2005 due to slow and long delay loading
issues. I just did this for VS 2005.

For VS 6.0, I ran MSDEV.EXE under depends and noticed when loading a
project, the last DLL loaded is FEACP.DLL as well. Different location
but similar functionality.

The lock up rears its head (intermittently) when loading a VS 6.0
project during the "loading workspace" phrase which is when this DLL is

What this is telling me that MS has integrated VS 6.0 "intellisense"
stuff with some common denominator "networking" dll, device driver,
component, installed with VS 2005.

It is the only logical explanation.

What I am trying to see now is what new files were installed and
replaced by VS 2005 that the VS 6.0 version of FEACP.DLL is using.

Hector Santos, Santronics Software, Inc.