Trying to attach locally with a process that was started with the --debug flag causes a 'General Exception' box to display.
With both July 22 and September 26 releases of the tools the attach fails on VS2013 Update3. However, the September 26th version works on VS2012 Update 3.
There seems to be a Visual Studio specific issue that is causing this break possibly a difference in the remote debugging interface from VS.
Here are the steps to reproduce:
start a node.js process (I did this with an express 4.x project)
$ node --debug app.js
debugger listening on port 5858
In Visual Studio attach dialog switch the transport to Node.js remote debugging and set the host to localhost:5858 (or 127.0.0.1:5858).
Expected:
Visual Studio Attaches and allows for debugging of the script files.
Actual:
Visual Studio 2012 Update 3 properly attaches
Visual Studio 2013 Update 3 fails to attach with the attached screenshot dialog 'General Exception'.
This reproduces on my test machine with a clean install of VS 2013 Update 3.
Comments: (copy/paste from the email thread where we discussed this) I’ve looked into this, and it seems that the problem is on Node (or rather, V8) side here. When you type in the qualifier in the Attach to Process dialog, we briefly attach to node.exe to ping it, to make sure that it’s there and retrieve the version info, so as to populate the process list in the dialog. Then when you click “Attach”, we attach again, and this time it’s the real thing. For some reason, this first brief attach/detach sometimes throws V8 debugger off, and it mishandles future connections to the same process (in a weird way, too – it allows them to connect, but then drops them shortly after). This is what is happening here. Now, there are two workarounds. One is to use RemoteDebug.js proxy, even though this is technically not a remote scenario. In this case, V8 only ever sees a single incoming connecting (from the proxy), and double-connecting from VS to the proxy doesn’t trigger the bug. The catch with this method is that, when attaching locally, you need to use the machine’s actual name (%COMPUTERNAME%), rather than localhost or 127.0.0.1, in the Qualifier textbox in the attach dialog. The proxy prints it out when you start it, so you can just copy/paste it into the textbox: ``` >node RemoteDebug.js app.js node: node scriptToDebug: app.js passThroughArgs: localClientPort: localhost:5859 remoteServerPort: NTVSSEDOUARD:5858 startDebuggeeOnRemoteConnect: false startDebuggeeBrokenAtEntryPoint: false remoteServerSocket listening for connection Debugee started: node --debug=5859 app.js debugger listening on port 5859 Express server listening on port 3000 ``` Alternatively, you can avoid the proxy and attach directly if you suppress the “ping” when listing processes. There is an undocumented qualifier syntax to do so – when attaching, append #ping=0 to the qualifier URL. E.g. instead of tcp://localhost:5858/, use tcp://localhost:5858/#ping=0. It will still show a process in the process list in the dialog, but we won’t do any ping to make sure that there actually is Node running there. This will also avoid a bug. We’ve had troubles with this whole ping business and directly using node.exe --debug before, and I tweaked that code to avoid them. But it might be that new Node/V8 versions do something differently now, and we are still hitting it. Also, this seems to be very dependent on the timing, which is why it doesn’t consistently repro on all machines, and not even on the same machine depending on the circumstances. Given that we’re basically trying to hack around an undocumented quirk of V8, I’m inclined to just say that we should stop advertising support for direct attach to --debug in the docs, and guide everyone to use RemoteDebug.js, even in local scenarios, since it sidesteps the problem entirely and in a reliable way.
With both July 22 and September 26 releases of the tools the attach fails on VS2013 Update3. However, the September 26th version works on VS2012 Update 3.
There seems to be a Visual Studio specific issue that is causing this break possibly a difference in the remote debugging interface from VS.
Here are the steps to reproduce:
start a node.js process (I did this with an express 4.x project)
$ node --debug app.js
debugger listening on port 5858
In Visual Studio attach dialog switch the transport to Node.js remote debugging and set the host to localhost:5858 (or 127.0.0.1:5858).
Expected:
Visual Studio Attaches and allows for debugging of the script files.
Actual:
Visual Studio 2012 Update 3 properly attaches
Visual Studio 2013 Update 3 fails to attach with the attached screenshot dialog 'General Exception'.
This reproduces on my test machine with a clean install of VS 2013 Update 3.
Comments: (copy/paste from the email thread where we discussed this) I’ve looked into this, and it seems that the problem is on Node (or rather, V8) side here. When you type in the qualifier in the Attach to Process dialog, we briefly attach to node.exe to ping it, to make sure that it’s there and retrieve the version info, so as to populate the process list in the dialog. Then when you click “Attach”, we attach again, and this time it’s the real thing. For some reason, this first brief attach/detach sometimes throws V8 debugger off, and it mishandles future connections to the same process (in a weird way, too – it allows them to connect, but then drops them shortly after). This is what is happening here. Now, there are two workarounds. One is to use RemoteDebug.js proxy, even though this is technically not a remote scenario. In this case, V8 only ever sees a single incoming connecting (from the proxy), and double-connecting from VS to the proxy doesn’t trigger the bug. The catch with this method is that, when attaching locally, you need to use the machine’s actual name (%COMPUTERNAME%), rather than localhost or 127.0.0.1, in the Qualifier textbox in the attach dialog. The proxy prints it out when you start it, so you can just copy/paste it into the textbox: ``` >node RemoteDebug.js app.js node: node scriptToDebug: app.js passThroughArgs: localClientPort: localhost:5859 remoteServerPort: NTVSSEDOUARD:5858 startDebuggeeOnRemoteConnect: false startDebuggeeBrokenAtEntryPoint: false remoteServerSocket listening for connection Debugee started: node --debug=5859 app.js debugger listening on port 5859 Express server listening on port 3000 ``` Alternatively, you can avoid the proxy and attach directly if you suppress the “ping” when listing processes. There is an undocumented qualifier syntax to do so – when attaching, append #ping=0 to the qualifier URL. E.g. instead of tcp://localhost:5858/, use tcp://localhost:5858/#ping=0. It will still show a process in the process list in the dialog, but we won’t do any ping to make sure that there actually is Node running there. This will also avoid a bug. We’ve had troubles with this whole ping business and directly using node.exe --debug before, and I tweaked that code to avoid them. But it might be that new Node/V8 versions do something differently now, and we are still hitting it. Also, this seems to be very dependent on the timing, which is why it doesn’t consistently repro on all machines, and not even on the same machine depending on the circumstances. Given that we’re basically trying to hack around an undocumented quirk of V8, I’m inclined to just say that we should stop advertising support for direct attach to --debug in the docs, and guide everyone to use RemoteDebug.js, even in local scenarios, since it sidesteps the problem entirely and in a reliable way.