There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?

1

Resolved

Creating New Project Hangs - Network Drives

description

Hi,

I have been experimenting with PTVS quite happily creating projects on my local drive.

Tonight I decided to start creating projects on my NAS using a network share, however I am running into issues. After selecting the location '\NASII\rdouble\documents\trading' in the New Project Dialog box, and clicking OK, Visual Studio then notifies me it
is creating the project with a progress bar but never finishes. Eventually I have to kill the Visual Studio process.

I have tried creating other types of Visual Studio projecs i.e. Visual Basic etc., on the network share and this works fine, so presumably this something to do with PTVS? Any help or suggestions would be welcome.

I was creating a Python application. I have just upgraded to the latest RC release and the issue still exists. I have also tried creating an IronPython application and the same issue presents itself. As noted before, other VS application templates e.g.
Visual Basic seem to work fine.

Since my last post I have discovered a little oddity. When creating the project VS becomes stuck with presenting a never-ending progress bar for creating the project, which I cannot break. However, at this point VS has actually created all the files, well at
least the .SLN, .pyproj, and a .py. If I then go and try to delete the project directory it causes VS to come back indicating "Error reading <path to direct>".

This may be specific to your NAS, it certainly doesn't repro with just any file share. Since the files are created, we've presumably made it into our loading code, which means we can fix it once we figure out what's going on.

The workaround is probably a good hint for us, though I don't believe we do anything significantly different there. If you are able to attach to VS with another instance of VS and see where we are getting stuck while loading is frozen, that would be a great
help. Our symbols are on the Microsoft Symbol Server, and that should get you line numbers for our code (or you can grab our source and see exactly where it is). Problems like this tend to be obvious once we know where to look.

Unfortunately I am unable to get the symbol tables loaded. I have them downloaded from the MS Symbol Server but for some reason VS can't locate. I even try to locate the Symbol file manually by selecting it e.g. "Microsoft.Python.Tools.Debugger.Helper.x64.pdb"
but VS complains "A matching symbol file was not in this folder.

If pause the debugger while the progress bar is in a never-ending state then I can see a number of threads running.

That looks like enough information to go on, and the main thread is about where I expected it to be.

It's still very interesting that the problem doesn't exist without the solution folder. We don't care about that folder, but VS probably puts its own file system watcher on it - there may be some race condition between those two when the path is on a remote
machine.

Looks like we really need a process dump so we can inspect the native locks and stacks.

As far as I can tell we're deadlocking on calling CloseHandle on an open directory handle. The place in the main thread where this happens is hardly our fault (more specifically, we can't fix it there) but we may be doing something somewhere else that is causing
this.