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.
It
> > wouldn't matter. This was the first thing I checked once I saw it
was
> > 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
sure.

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
layer.

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
loaded.

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.
http://www.santronics.com





.



Relevant Pages

  • Re: DLL fight
    ... What you're linking to discusses mainly remote ... the news, but it's really a network security issue, ... loading from the current directory. ... Preventing loading of a DLL from app.path would break ...
    (microsoft.public.vb.general.discussion)
  • Re: Dynamic DLL Loading or Static ?
    ... Loading it on demand the cuts down on load time for the app and on memory foot ... the DLL contains functionality that depends on specific platform features. ... There are two areas where static and dynamic loading differ. ... If you use static loading the DLL will be loaded and its Initialization ...
    (borland.public.delphi.nativeapi)
  • Re: Dynamic DLL Loading or Static ?
    ... A DLL is dynamic linked always: ... terms are load-time dynamic linking and run-time dynamic linking. ... > initialize this DLL and I'm loading it dynamically. ... This is the default value for WinXP SP1 and WinSrv03. ...
    (borland.public.delphi.nativeapi)
  • Re: Manifest Requires Win2K Compatibility?
    ... You need to call InitCommonControlsEx() in a controlled manner in order to load the new version Common Controls before the VB6 runtime gets the chance to force loading of the older version DLL. ... Once VBRUN has made this call, the system won't try to handle DLL loading failures - expecting the "I'm so smart" VBRUN to handle them. ...
    (microsoft.public.vb.general.discussion)
  • Re: Unloading a DLL to update it.
    ... Since I am loading the dll ... >> Private Shared Sub StartApplication() ...
    (microsoft.public.dotnet.languages.vb)