IDE Hangs Up when Debugging Macros

Q:

In some of my machines, debugging macro code will cause the IDE to hang up. The IDE won’t responsed when F10 is pressed. I have to stop debugging, and I get the below exception:

System.Runtime.Remoting.RemotingException: Failed to read from an IPC Port: The pipe has been ended. I think I have found the reason. When debugging with “Autos” window opened, the IDE will hang up when executing proxy code. It runs fast when the “Autos” window is closed.

A:

You can solve this issue by using the AllThreadsRunOnFuncEval registry workaround:

There is a registry setting that the ShapeAppMacroRecordingCSharp sample adds which prevents the hang you are experiencing.  The registry setting is added when the SetupShapeAppMacroRecordingCSharp.js setup file is run.  If this registry entry is removed, similar hangs occur when debugging the macro project for the ShapeAppMacroRecordingCSharp sample with the immediate/locals/auto/watch windows open, or when hovering the mouse over a variable to get its value.  Here is some documentation on this work around:

Note:  Using this workaround will affect what is shown in the immediate/locals/auto/watch windows of the debugger and values shown when hovering the mouse over a variable. 

Registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VSTAHost\ShapeAppCSharp\9.0\AD7Metrics\Engine\{449EC4CC-30D2-4032-9256-EE18EB41B62B}]

"AllThreadsRunOnFuncEval"=dword:00000001

SetupShapeAppMacroRecordingCSharp.js:

        wshShell.RegWrite("HKLM\\Software\\Microsoft\\VSTAHost\\" +

            hostID + "\\9.0\\AD7Metrics\\Engine\\{449EC4CC-30D2-4032-9256-EE18EB41B62B}\\AllThreadsRunOnFuncEval", "1", "REG_DWORD");

ReadMe ShapeAppMacroRecordingCSharp.htm:

Known issues

1.     Evaluating a Variable may stop the debugger during out-of-process debugging.

To resolve the issue, make sure AllThreadsRunOnFuncEval registry value exists and is set to 1 (a DWORD value) for the following registry key:

HKLM\SOFTWARE\Microsoft\VSTAHost\_replace_with_intended_hostid_\9.0\AD7Metrics\Engine\{449EC4CC-30D2-4032-9256-EE18EB41B62B\

The setup script file for this sample sets this registry value.

VSTA documentation on MSDN

Non-Destructive Debugging That Works with a Running Host Application
During an out-of-process debugging session, the Visual Studio Tools for Applications debugger, add-in, and host application each run in a separate process. The debugger process evaluates symbol names and functions on the thread for the add-in process. When the debugger evaluates a host object in the add-in process, the add-ins calls a host function, which is executed by Visual Studio Tools for Applications. The Visual Studio Tools for Applications runtime calls the add-in process to retrieve add-in lifetime management information. Because the add-in process is frozen by the debugger and only one thread is allowed to run to evaluate variables, the call from the host cannot be serviced and the add-in process stops responding. To resolve this problem, the registry can be modified to instruct the debugger to enable execution of all threads when evaluating an object. When all threads execute, the add-in process can service the call from the host process, and the debugger is not blocked. However, this workaround may cause side effects if the add-in has multiple threads scheduled to run when the debugger breaks.

If you want Visual Studio Tools for Applications to use all threads to evaluate a variable, you must set a registry key.

The following procedure demonstrates how to configure the debugger to use all threads.

To debug your add-in using all threads

1.      In the registry, navigate to the following key. Replace HostID in the path with the name of your add-in. For example, you can replace HostID with ShapeAppCSharp.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VSTAHost\HostID\9.0\AD7Metrics\Engine\{449EC4CC-30D2-4032-9256-EE18EB41B62B}

2.      Create a DWORD subkey called AllThreadsRunOnFuncEval.

3.      Assign the value of dword:00000001.