I've just had a similar problem where a supposed N: network drive was listed
as a disconnected drive in Windows Explorer, but I could double-click on it
to view the drive's contents. However, shortcuts that pointed to locations on
this N: drive didn't work, I couldn't disconnect the drive through Windows
Explorer, and it wasn't listed using the Net Use command.

The problem was with a shortcut in the user's Startup folder that pointed to
a command file on this N: drive. It was as if the N: drive definition was
being created on the fly in response to trying to execute the shortcut, but
not correctly.

The following resolved the problem:

1. Log on as the affected user.

2. Move the shortcut from the Startup folder.

3. Open a Command window, and execute the following commands:
net use /persist:no
net use * /delete

4. Log off, and then back on again, and verify there were no mapped drives.

5. Open a Command window, and execute the following command:
net use /persist:yes

6. Run our standard .cmd file to create our standard drive mappings.

7. Log off, and then back on again, and verify that the drive mappings were
as expected.

8. Restore the shortcut to the Startup folder.

9. Log off, and then back on again, and check that behaviour was as intended.

Your set-up won't match ours, but to generalise, you could look for any
start-up processes that point to your problem mapped drives, disable them,
and ensure that drives are mapped correctly before they are used by any other
processes.

"Mayy" wrote:

> Hi,
>
> A Windows XP domain client has logon scripts applied to map three network
> drives, P, M and T. One client machine today has the old chestnut of
> "Disconnected Network Drive" showing against each of the shares in My
> Computer, and right click/disconnect gives the error "The network connection
> could not be found".
>
> I've been through all the usual tried and tested suggestions from this
> newsgroup and others - net use * /delete ("There are no entries in the
> list"), net use /persistent:no, rebooting, logging on as the local
> administrator and doing it all again, renaming the drive to "kjshdfljdhfl",
> searching the registry for the corresponding key and deleting it (it
> resurrected itself on the next reboot), all to no avail.
>
> No other client machines are affected, even in the same OU/Site where all
> login scripts are generic.
>
> Searching various newsgroups shows this exact problem occurring as early as
> 2004, and yet there still doesn't seem to be a coherent resolution for this
> problem.
>
> Any clues?