Azure Debugging Environment in VS2015 crashes on start

Question

This just started happening out of the blue recently. I tried all the solutions I can find on Stack and other forums but nothing so far has worked.

When I try to start debugging on an Azure worker role, this is as far as I get:

The Debug window reads: The program '[2208] WaIISHost.exe' has exited with code 0 (0x0).

I'm running Visual Studios in Administrative mode, with the correct project set as start-up and using IIS Express as the dev server.

I've tried creating a new Azure worker role with the same underlying project but that didn't work. System event logs don't have any information. I've tried reinstalling VS2015 and separately the Azure SDK (v.2.7.1), no change. When I view the compute emulator, before it disappears it says:

[fabric] Role Instance: deployment27(250).Web.0
[fabric] Role state Unhealthy
[fabric] Role state Stopped

I am however able to start other worker role projects in the solution, which leads me to believe that something must have gotten corrupted in the project tied to the broken worker role somehow. I'm out of ideas at this stage so any help is greatly appreciated.

UPDATE

Looking at the WallSHost.log file inside C:\Users\<UserAccount>\AppData\Local\dftmp\Resources\<GUID>\directory\DiagnosticStore gives me an Invalid name error:

WaIISHost Information: 0 : [00003568:00000001, 2015-10-06 20:02:05.472, INFO ] Attempt Deploy with RoleInstanceId=deployment27(252).Web_IN_0 RoleRoot=C:\Web\csx\Debug\roles\Web\ optional SitesDestination=
WaIISHost Information: 0 : [00003568:00000001, 2015-10-06 20:02:08.153, ERROR] Exception:System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Invalid name.
Parameter name: name (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.ArgumentException: Invalid name.
Parameter name: name
   at System.Security.AccessControl.NativeObjectSecurity.CreateInternal(ResourceType resourceType, Boolean isContainer, String name, SafeHandle handle, AccessControlSections includeSections, Boolean createByName, ExceptionFromErrorCode exceptionFromErrorCode, Object exceptionContext)
   at System.Security.AccessControl.FileSystemSecurity..ctor(Boolean isContainer, String name, AccessControlSections includeSections, Boolean isDirectory)
   at System.Security.AccessControl.DirectorySecurity..ctor(String name, AccessControlSections includeSections)
   at System.IO.DirectoryInfo.GetAccessControl(AccessControlSections includeSections)
   at Microsoft.WindowsAzure.ServiceRuntime.IISConfigurator.FileManager.AddAllowAceIterative(DirectoryInfo dir, FileSystemRights rights, IdentityReference[] accounts)
   at Microsoft.WindowsAzure.ServiceRuntime.IISConfigurato...).


WaIISHost Information: 0 : [00003568:00000001, 2015-10-06 20:02:08.157, ERROR] Exception:System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Invalid name.
Parameter name: name (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.ArgumentException: Invalid name.
Parameter name: name
   at System.Security.AccessControl.NativeObjectSecurity.CreateInternal(ResourceType resourceType, Boolean isContainer, String name, SafeHandle handle, AccessControlSections includeSections, Boolean createByName, ExceptionFromErrorCode exceptionFromErrorCode, Object exceptionContext)
   at System.Security.AccessControl.FileSystemSecurity..ctor(Boolean isContainer, String name, AccessControlSections includeSections, Boolean isDirectory)
   at System.Security.AccessControl.DirectorySecurity..ctor(String name, AccessControlSections includeSections)
   at System.IO.DirectoryInfo.GetAccessControl(AccessControlSections includeSections)
   at Microsoft.WindowsAzure.ServiceRuntime.IISConfigurator.FileManager.AddAllowAceIterative(DirectoryInfo dir, FileSystemRights rights, IdentityReference[] accounts)
   at Microsoft.WindowsAzure.ServiceRuntime.IISConfigurato...).

Answer 1

After re-installing Visual Studios, the Azure SDK, IIS and thralling through log files, I finally found the issue: the node_modules folder in the web project that is associated with my worker role.

Soon as I deleted the folder, debugging started straight away; even though it is not part of the Visual Studios solution.

I've since searched for this specific issue on Stack and found this post: https://stackoverflow.com/a/28188299/654708

Adding rmdir /s /q "$(ProjectDir)node_modules\" to the post-build events inside the properties of the project associated with the worker role, will delete the node_modules folder prior to the Azure debugger starting. Not a perfect fix but it will do until this ridiculous problem with Windows not being able to handle long file names is fixed.

UPDATE

Just found a better solution. Update npm to >= 3.x by using the npm-windows-upgrade module from the Microsoft dev team here:

https://www.npmjs.com/package/npm-windows-upgrade

In npm 3.x, the modules in the node_modules folder are stored in a flat structure. This should help to avoid the 256 character limit on paths which causes the Azure debugger to crash (provided the path to your solution root isn't already too long).

By default when installing Node on Windows, npm version 2 come pre-bundled (as of 8th Sep 2015). Using the regular npm update command npm -g install npm@<version> won't work as Node will always look at the version of npm that came with the installation; which is where npm-windows-upgrade comes in.

Open Windows PowerShell with Administrator rights and run the following tasks to choose the version of npm you want to install.

1. Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force
2. npm install -g npm-windows-upgrade
3. npm-windows-upgrade

Additional reading:

https://github.com/npm/npm/wiki/Troubleshooting#upgrading-on-windows https://github.com/npm/npm/issues/3697#issuecomment-114665926