VS2015 crashes every time I update npm package version

[alanpurple]

windows 10 pro x64
vs 2015 enterprice
nodejstool 1.1 rc
iojs 3.0.0
python 2.7.10 x64
node-gyp in iojs 3.0.0 is intalled globally

stop working -> restarting

[mousetraps]

Thx for reporting this. Since VS crashed, there should be a corresponding entry (or entries) in the windows event log. Mind grabbing that for us?

Also can you be a little more specific about how you're updating the package version? Are you using the context menu command, or something else?

[alanpurple]

@mousetraps where is log? I can't find it in C:\user\username\AppData\Roaming\Microsoft\VisualStudio\14.0

package doesn't matter I think, this time mongoose 4.1.1 -> 4.1.2, I usually just modify package.json and save and then addon run script automatically

anyway package was updated successfully after these crash and restart

[mousetraps]

Control Panel > System and Security > Administrative Tools > Event Viewer

[billti]

Or just use the "Windows Key + X" (the handiest but least known Windows shortcut) to open the menu, and then press "V" (for Event Viewer).

p.s. "Win + X, A" is another super handy combo I use all the time for an Admin prompt.

[billti]

p.s. The log to look at will be under 'Windows Logs / Application'. Most app crashes get an event in here.

[alanpurple]

@mousetraps 2 errors occured one other right after one

1. Event 1026, .NET runtime
   Application: devenv.exe
   Framework Version: v4.0.30319
   Description: The process was terminated due to an unhandled exception.
   Exception Info: System.IO.PathTooLongException
   Stack:
   at System.IO.Path.NormalizePath(System.String, Boolean, Int32, Boolean)
   at System.IO.Path.GetDirectoryName(System.String)
   at Microsoft.VisualStudio.Services.DirectoryWatcher+d__132.MoveNext()
   at System.Linq.Enumerable+d__11[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext() at System.Linq.Enumerable.Contains[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.Collections.Generic.IEnumerable1<System.__Canon>, System.__Canon, System.Collections.Generic.IEqualityComparer1<System.__Canon>) at System.Linq.Enumerable.Contains[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.Collections.Generic.IEnumerable1<System.__Canon>, System.__Canon)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessDirectoryChanges(System.Collections.Generic.IEnumerable1<System.Collections.Generic.KeyValuePair2<System.String,Microsoft.VisualStudio.Services.ChangeStreamDigest>>, Int32)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessChanges(System.Collections.Generic.IEnumerable1<System.Collections.Generic.KeyValuePair2<System.String,Microsoft.VisualStudio.Services.ChangeStreamDigest>>, Int32)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessChanges(System.Collections.Generic.IEnumerable1<System.Collections.Generic.KeyValuePair2<System.String,Microsoft.VisualStudio.Services.ChangeStreamDigest>>, Int32)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.OnChangedAsync()
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
2. Event 1000, Application Error
   Faulting application name: devenv.exe, version: 14.0.23107.0, time stamp: 0x559b7ead
   Faulting module name: KERNELBASE.dll, version: 10.0.10240.16384, time stamp: 0x559f3b2a
   Exception code: 0xe0434352
   Fault offset: 0x000b3e28
   Faulting process id: 0x2114
   Faulting application start time: 0x01d0d440e6db3ccb
   Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
   Faulting module path: C:\Windows\SYSTEM32\KERNELBASE.dll
   Report Id: 749ac6f7-d457-4dbb-922c-a4dfc2ab5c9e
   Faulting package full name:
   Faulting package-relative application ID:

looks like this is caused by "Too long path" related. similar to warning when I first try to build my node.js project.

[billti]

This is an unfortunately limitation of .NET that impacts some Node projects due to the way node modules nest in the file system (see http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx ).

As a potential workaround, is the project stored at an already lengthy path (e.g. "C:\users\some name\documents\visual studio 2015...")? If so, can you try moving the project to somewhere like "C:\src" and seeing if the problem persists?

[billti]

(note: that doesn't change the fact this shouldn't crash and we need to handle this exception better - and give useful guidance when caught - but hopefully that will unblock you)

[mousetraps]

I think this might actually be coming from web tools, not from ntvs - he mentioned that the script is run immediately after he saves.

[alanpurple]

@billti my project is like F:\VSWorkspace\project1\src\project1, not that long I think

@mousetraps It's not web tool, I didn't use any tool other than VS2015 itself and ntvs

[alanpurple]

@billti I think express plugins' dependency hierarchy is usually bit deep, maybe that's reason how the path is so long

[billti]

@mousetraps This is the area where we may be creating this watcher: https://github.com/Microsoft/nodejstools/blob/master/Nodejs/Product/Npm/SPI/NpmController.cs#L252 .

Edit: Though from the crash looks like a VS provided directory watcher, whereas the above creates a .NET one directly... so maybe not).

@alanpurple Any idea how deep? (I'll knock up a quick script to grab it if unsure)

[mousetraps]

@alanpurple sorry for not being totally clear there. web tools is a component installed with VS2015, and I'm thinking they may have introduced a bug with their own npm integration that conflicts with ours.

Can you try opening up Options > Projects and Solutions > External Web Tools, and unchecking all of those boxes under "locations of external tools" as shown below, restart VS, and see if that helps work around the crash?

[alanpurple]

@billti like this
\node_modules\connect-mongo\node_modules\mongodb\node_modules\mongodb-core\node_modules\kerberos\node_modules\nan

[alanpurple]

@mousetraps I'm trying now, but I need gulp, git, and many things.

anyway I'm trying right now, and VS got too slow, it take times.

[alanpurple]

@mousetraps yeah, tested, same

and I need them also

[billti]

FYI: Below PowerShell line, run from the root of the project, will report the longest filepath

Get-ChildItem -Recurse | Select-Object -Property @{Name="Len";Expression={$_.FullName.Length}},FullName | Sort-Object Len -Descending | Select -First 1

It would be useful to see what the longest path is.

[alanpurple]

@billti mongoose is the longest

259

that powershell couldn't even search them all, it got error because it's too long
I can't even manually find by myself

maybe it's the only way that I just see and take a minute for VS to restart.....if I have to use mongodb and mongoose with Visual Studio

[billti]

Yeah, once you add in the null terminator... I think the limit it 256.

Can you try moving from 'F:\VSWorkspace\project1\src\project1' to 'F:\src\project1'? Sounds like that should just squeak under the line.

[alanpurple]

@billti F:\VSWorkSpace\project1\src\project1BE is my backend part, and I doubt if it can make any difference since mongoose module has almost infinite hierarchy length

okay, at least I can try

[alanpurple]

@billti
same crash
F:\VSWorkspace\NewStart
F:\VSWorkspace\NewStart\node_modules
F:\VSWorkspace\NewStart\package.json

[billti]

Hmmm, weird. I think we'll need to actually see the exception details to figure out what file path is causing this (as based on the move above, it shouldn't be anything under the Node project location).

Are you able to get your instance of VS ready just before the repro, then launch another instance of VS as an Admin (either right click/run as admin or launch devenv.exe from an Admin prompt). From the Admin instance select 'Debug / Attach to Process', then from the dialog select the other Devenv.exe instance, ensure "Attach to" is 'Managed code', and then 'Attach'. If you then go back to the instance and repro the crash, the Admin instance should catch and break on the exception. If you expand the exception object (i.e. from the Autos or Locals window or some such) the exception should have additional details attached (such as file path causing the exception, maybe an inner stack, etc...).

Sorry for the trouble. Thanks for helping get to the bottom of it.

[alanpurple]

stopped happening, after iojs 3.1.0 and mongoose 4.1.3.

I don't know how, and why

[billti]

Thanks for the update. Did you update both of those at the same time and the issue went away (i.e. you are still using the same install of VS & Node Tools, but just updated those packages)? If you can detail what version of io.js/NodeJS & Mongoose you had previously when the error was occurring I'll try one last time to get a repro here.

[alanpurple]

@billti I'm not 100% sure but it might be after iojs3.0.0->iojs3.1.0

[amyspark]

Guys, there is an issue at the npm project regarding this problem: npm/npm#3697

[paxibay]

I encountered a similar problem when I converted an old node app based on the follows environment.

Windows Server 2012 R2
VS 2015 enterprice
NTVS 1.1 rc

I narrowed the scope and found that the crash came from gulp modules when saving package.json file. The difference was that my VS 2015 was thoroughly crashed and without a chance to figure out what happened. I tried to repair and even reinstall VS 2015, crash was the same as before. I have to use Acronis backup to restore the while operation system which including VS 2015, but I'd better not use NTVS 1.1 rc anymore, until the formal version released and to see if it would be ok.

[billti]

@paxibay What version of Node were you using? See the few prior comments where updating resolved the issue? If that's not the case, see the few comments prior to that and see if you might be hitting MAX_PATH issues due to folder layout.

If VS is crashing that's no good though. Please see if there is an event in Event Viewer that contains a call stack we can look at. (Also, on the releases page your find NTVS RC2 which fixes a few issues and works with npmv3, which might also be an option if it is a MAX_PATH issue).

[billti]

Moving out of current milestone until we get more info to help track down.

[dariagrigoriu]

Just ran into this as well after

• express 4 azure template in default project folder
• during .npm install in interactive window
• 1.1 RC2.1

  at System.IO.Path.NormalizePath(System.String, Boolean, Int32, Boolean)
   at System.IO.Path.GetDirectoryName(System.String)
   at Microsoft.VisualStudio.Services.DirectoryWatcher+<FilterDescendentDirectories>d__132.MoveNext()
   at System.Linq.Enumerable+<DistinctIterator>d__1`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext()
   at System.Linq.Enumerable.Contains[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.Collections.Generic.IEnumerable`1<System.__Canon>, System.__Canon, System.Collections.Generic.IEqualityComparer`1<System.__Canon>)
   at System.Linq.Enumerable.Contains[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.Collections.Generic.IEnumerable`1<System.__Canon>, System.__Canon)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessDirectoryChanges(System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<System.String,Microsoft.VisualStudio.Services.ChangeStreamDigest>>, Int32)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessChanges(System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<System.String,Microsoft.VisualStudio.Services.ChangeStreamDigest>>, Int32)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessChanges(System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<System.String,Microsoft.VisualStudio.Services.ChangeStreamDigest>>, Int32)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessChanges(System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<System.String,Microsoft.VisualStudio.Services.ChangeStreamDigest>>, Int32)
   at Microsoft.VisualStudio.Services.DirectoryWatcher.OnChangedAsync()
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)

[ghost]

Visual Studio 2015 used to crash all the time for me when I did npm things outside of VS, but then I disabled Save To Disk under Options -> Text Editor -> Node.js -> Intellisense and I haven't had a problem since. (I also turned off Intellisense logging).

This is fine for my machine which has a Intel Core i5-4690 @ 3.5 GHz, 32 GB of RAM and a couple of new, fast SSDs. Not sure how well it works on lesser machines.

[mousetraps]

I ran into this today as well, and managed to attach a debugger.

Here's a stack trace with line numbers:

    mscorlib.dll!System.IO.Path.NormalizePath(string path, bool fullCheck, int maxPathLength, bool expandShortPaths)    Unknown
    mscorlib.dll!System.IO.Path.GetDirectoryName(string path)   Unknown
>   Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.Services.DirectoryWatcher.FilterDescendentDirectories(System.Collections.Generic.IEnumerable<System.Collections.Generic.KeyValuePair<string, Microsoft.VisualStudio.Services.ChangeStreamDigest>> digests) Line 1704    C#
    System.Core.dll!System.Linq.Enumerable.DistinctIterator<string>(System.Collections.Generic.IEnumerable<string> source, System.Collections.Generic.IEqualityComparer<string> comparer) Line 724  C#
    System.Core.dll!System.Linq.Enumerable.Contains<string>(System.Collections.Generic.IEnumerable<string> source, string value, System.Collections.Generic.IEqualityComparer<string> comparer) Line 1251   C#
    System.Core.dll!System.Linq.Enumerable.Contains<string>(System.Collections.Generic.IEnumerable<string> source, string value) Line 1244  C#
    Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessDirectoryChanges(System.Collections.Generic.IEnumerable<System.Collections.Generic.KeyValuePair<string, Microsoft.VisualStudio.Services.ChangeStreamDigest>> digests, int depth) Line 1623 C#
    Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessChanges(System.Collections.Generic.IEnumerable<System.Collections.Generic.KeyValuePair<string, Microsoft.VisualStudio.Services.ChangeStreamDigest>> digests, int depth) Line 1559  C#
    Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.Services.DirectoryWatcher.ProcessChanges(System.Collections.Generic.IEnumerable<System.Collections.Generic.KeyValuePair<string, Microsoft.VisualStudio.Services.ChangeStreamDigest>> digests, int depth) Line 1604  C#
    Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.Services.DirectoryWatcher.OnChangedAsync() Line 1353    C#
    WindowsBase.dll!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate callback, object args, int numArgs)  Unknown
    WindowsBase.dll!System.Windows.Threading.ExceptionWrapper.TryCatchWhen(object source, System.Delegate callback, object args, int numArgs, System.Delegate catchHandler) Unknown
    WindowsBase.dll!System.Windows.Threading.DispatcherOperation.InvokeImpl()   Unknown
    WindowsBase.dll!System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(object state)  Unknown
    mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) Unknown
    WindowsBase.dll!System.Windows.Threading.DispatcherOperation.Invoke()   Unknown
    WindowsBase.dll!System.Windows.Threading.Dispatcher.ProcessQueue()  Unknown
    WindowsBase.dll!System.Windows.Threading.Dispatcher.WndProcHook(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled)  Unknown
    WindowsBase.dll!MS.Win32.HwndWrapper.WndProc(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled) Unknown
    WindowsBase.dll!MS.Win32.HwndSubclass.DispatcherCallbackOperation(object o) Unknown
    WindowsBase.dll!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate callback, object args, int numArgs)  Unknown
    WindowsBase.dll!System.Windows.Threading.ExceptionWrapper.TryCatchWhen(object source, System.Delegate callback, object args, int numArgs, System.Delegate catchHandler) Unknown
    WindowsBase.dll!System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority priority, System.TimeSpan timeout, System.Delegate method, object args, int numArgs)   Unknown
    WindowsBase.dll!MS.Win32.HwndSubclass.SubclassWndProc(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam)  Unknown

But what's interesting is that there's actually a MAX_PATH "check" in FilterDescendentDirectories. However this check clearly won't work for all cases, as it only checks whether the string exceeds the max filepath length of 260 (not the max directory length), and there is no fallback exception handling.
https://github.com/dotnet/corefx/blob/c6b0d8fa614a6e3dbc88474db74047cf5753256f/src/Common/src/Interop/Windows/mincore/Interop.MaxLengths.cs

I reproduced this on the release builds of VS, so some of the code is optimized away, and I can't verify that the string does indeed have these properties, but the trace and src code is clear enough to go by here.

We'll chat with the team responsible, so hopefully it can be fixed in Update 1.

[mousetraps]

Thanks all for reporting this! The fix for this issue will be available in VS Update 1 when it's released (not available in the Update 1 RC bits that were released today, though.)

[patrickrobbins]

We have had this issue for 2 years on our build server that uses gulp tasks with node. the path is way way too long. node can create the files, but nothing in .net can clean them up. We found a .net dll that wrapped the win32 file tools. we would use that in our build to delete the dev tools after the build was complete or else tfs would not be able to delete the long file path, and our build would break consistently.

[ghost]

@patrickrobbins You can also use .net to run the rimraf CLI.

[jmevel]

April 2016. VS2015 Update 2, the bug is still here...

[manuelmoyaroldan]

Very frustrating. VS2015 Update 2 too... it is impossible to work with it... i have moved to other IDE.

[michaelvolz]

May 2016: VS 2016.Update 2.1 still having the same problem. Editing any JSON file would freeze Visual Studio after a while.

Two things made it much, much better: Disabling the "(DevEnvDir)..." folders in "External Web Tools", (because I already have nodejs installed) and disabling Schemavalidation in "Text Editor/JSON/Schema"

Maybe this helps someone.

[mjbvz]

This seems to be a problem with ASP Web Tools and not NTVS. We've reached out to the Web Tools team to let them know about the problem, and there is already a bug tracking the issue: aspnet/Tooling#219 (comment)

Thanks.