Getting troubleshooting logs

When you are trying to understand if you are missing an interface, or why you code isn't being called, it can be very helpful to enable logging from the dispatcher. This will print out information about what Concord interfaces were invoked, and why that implementation was chosen.

Enabling logging with Visual Studio 2022 version 17.8 or newer

Visual Studio 2022 version 17.8 integrates logging controls into the command window, for a much easier experience:

1. View->Other Windows->Command Window
2. To enable at the same level as the previous logging, use: Debug.SetLogging /DebugEngineAPIMethod. Additional, verbosity levels are also available.

Logging will be written into a new 'Debugger Logging' output window pane. If you have a debugger attached at the time that the debugger was initialized, it will also write to the 'Debug' output window pane of the attached debugger (either a native or managed debugger). Output from both the Visual Studio and remote debugger (msvsmon.exe) processes will be included in the output.  

Enabling logging in the Experimental Visual Studio instance

By default, if you launch a Visual Studio extensible project, it will fire up a new "Experimental" instance of Visual Studio. This is handy because it means that you can change Visual Studio's behavior without potentially breaking the instance of VS that you are using to develop your extension.

Unfortunately, unless you are using Visual Studio 2017 version 15.8 or newer, the SetEngineLogMode.cmd script will not work with the experimental instance. Here is how you can enable logging by hand:

1. Start the experimental instance of VS by F5'ing (Start Debugging) or Ctrl-F5'ing your project. Note: This must be done before updating the registry (step #4) or your changes might get removed as the Experimental instance's registry settings are usually reset when it is started.
2. Note: Do NOT start debugging yet in the experimental instance. You need to update the registry before you start debugging the first time.
3. Go to the Windows Start Menu, and open a Developer Command Prompt
4. In the developer command prompt run: "%DevEnvDir%vsregedit.exe" set "%VSINSTALLDIR:~0,-1%" Exp HKLM Debugger EngineDiagEnableState DWORD 2
5. Now you are free to start using the debugger in the experimental instance.
6. If at any point you want to check if method logging is still enabled, run: "%DevEnvDir%vsregedit.exe" read "%VSINSTALLDIR:~0,-1%" Exp HKLM Debugger EngineDiagEnableState DWORD

If you would also like logging for the msvsmon.exe process, see below.

Enabling logging in a NON-Experimental instance

The Visual Studio SDK ships with a script to enable/disable/dump logging state. To use it, go to the Windows Start Menu, and open a Developer Command Prompt. Then run the following:

cd /d "%VSINSTALLDIR%\VSSDK\VisualStudioIntegration\Tools\Bin"
.\SetEngineLogMode.cmd method "%VSINSTALLDIR%"

If this fails because the VisualStudioIntegration directory is missing, this means that your Visual Studio installation is missing the "Visual Studio extension development" workload. You can add it from the Visual Studio installer.

To restore logging to the default (disabled) state, use SetEngineLogMode.cmd default "%VSINSTALLDIR%".

If you would also like logging for the msvsmon.exe process, see below.

Enable logging in the msvsmon.exe process

For either remote debugging, or for local scenarios that require a 64-bit worker process, code will be loaded into msvsmon.exe. If you would like logging from msvsmon.exe you need to manually set the following registry key:

1. Open a command prompt as an administrator
2. Run: reg add HKLM\Software\Microsoft\VisualStudio\17.0\Debugger /v EngineDiagEnableState /t REG_DWORD /d 2 /f /reg:32 replacing '17.0' with whatever version of the remote debugger you want.
3. When you are done, remove the key with: reg delete HKLM\Software\Microsoft\VisualStudio\17.0\Debugger /v EngineDiagEnableState /reg:32 /f

Viewing logs

To view logs you can either have a native or mixed mode debugger attached to VS/msvsmon process that you are interested in and look in the Output Window, or run without a debugger and look at the %TMP%\vsdebugeng.dll.log file.

Logging output looks like the following:

CALL: IDkmLaunchResumeProcess.LaunchProcess (ThreadId=23308 Class=BaseDMServices::CService IP=0x3148E10A Object=0x226C47E8 TickCount=320451421 ComponentId={8DAA4962-CC99-40D4-97F5-EFB6A7B7F206})
  Skipped: ScriptDM::CScriptDebugMonitor {520B05FA-C8E6-434C-8B1D-21E20AB22865} for 'EngineId' filter
  Skipped: ReflectionBDM.CReflectionBaseDebugMonitor {6D997B7B-E8AF-49EE-8C53-2A3C970B8A6A} for 'EngineId' filter
CALL: IDkmProcessLaunchEnvironmentFilter140.GetAdditionalEnvironmentVariables (ThreadId=23308 Class=CStandardCollectorBridge IP=0x2264D3CD Object=0x226C4898 TickCount=320451453 ComponentId={5EFFD3A6-3BF4-4A49-B6BE-2369DF2E4FD2})
RETURN: IDkmProcessLaunchEnvironmentFilter140.GetAdditionalEnvironmentVariables (hr = 0x0, ThreadId=23308, TickCount=320453031)
CALL: IDkmProcessLaunchEnvironmentFilter.GetAdditionalEnvironmentVariables (ThreadId=23308 Class=GpuEnvSetup.CGpuEnvSetup IP=0x53CE32BE Object=0x226C47C0 TickCount=320453062 ComponentId={C5D8535C-4DFE-42C7-A65F-301163C92A11})
RETURN: IDkmProcessLaunchEnvironmentFilter.GetAdditionalEnvironmentVariables (hr = 0x1, ThreadId=23308, TickCount=320453062)
CALL: IDkmProcessLaunchEnvironmentFilter.GetAdditionalEnvironmentVariables (ThreadId=23308 Class=ManagedDM::CCommonEntryPoint IP=0x31468E19 Object=0x226C47C0 TickCount=320453062 ComponentId={38A59583-E6B1-4EE4-A53C-133BE0F45E55})
RETURN: IDkmProcessLaunchEnvironmentFilter.GetAdditionalEnvironmentVariables (hr = 0x1, ThreadId=23308, TickCount=320453062)
CALL: IDkmProcessLaunchEnvironmentFilter.GetAdditionalEnvironmentVariables (ThreadId=23308 Class=PixCaptureEngine.CPixCaptureEngine IP=0x300D378E Object=0x226C47C0 TickCount=320453109 ComponentId={0C4D1BEA-0ABB-4F57-972B-4FE5368747C5})
RETURN: IDkmProcessLaunchEnvironmentFilter.GetAdditionalEnvironmentVariables (hr = 0x1, ThreadId=23308, TickCount=320453109)
RETURN: IDkmLaunchResumeProcess.LaunchProcess (hr = 0x0, ThreadId=23308, TickCount=320453109)

Logging on Linux or Mac

Dispatcher logging is also available on Linux or Mac. To enable it, vsdbg/vsdbg-ui needs to be run from a prompt which has exported the Concord_EngineDiagEnableState environment variable. The values of this key are the same as on Windows, so to enable method logging:

export Concord_EngineDiagEnableState=2

The log will be written to $TMPDIR/vsdebugeng.dll.log (/tmp/vsdebugeng.dll.log if TMPDIR is undefined).

Note that if you are testing a scenario where vsdbg is automatically spawned (example: SSH Attach to Process in VS) you will want to export this from your automatic login script.