Unable to start debugging: How to attack the issue.

I am the owner for the device debugging efforts from the Visual Studio for Devices team. If you are hitting "Unable to start debugging" or any similar issue in F5 experience, please feel free to convey the information via MSDN feedback centre. While doing so try to provide as much information as possible.

BTW F5 e2e scenario contains three stages: connection to the device, deployment of the files and then starting the debugger.

What information is needed?

Sample Template for the diagnosis in the order of value.

Stage1:

  1. Is Connect to Device working (VS->tools->connect to Device)?
  2. Is Ctrl F5 scenario working (start without debugging)?
  3. Are the RemoteTools working from the Visual Studio root? (Microsoft Visual Studio 2005->Visual Studio Remote Tools)

The above information will ensure if it is a debugger specific issue or not. Now to the next stage

Stage2

  • A simplified repro.
  • Error Dialog. Example "Unable to start debugging".
  • Managed debugging (C#/VB) or Native Debugging or Both
      -If Managed debugging V1 or V2 or both.
      -If Native debugging is it SDK/architecture specific. 
  • Physical Device or Emulator or both.
       -Architecure of the device
       -Transport (DMA, Active Sync) specific or not.
  • When you hit the issue is edm.exe running on the device [ Use Remote Tools Process Viewer ]
  • Version of the Visual Studio being used.

The more the information the resolution would be quicker. Then the next stage

Stage3:

Running the scenario by running the scenario using VSD Logging instructions and sending the logs to us. I would defer the details of this stage to a subsequent blog as this applies to any scenario in VSD and not specific to debugger.

Why does it happen?

Let me highlight the most common reasons for hitting the same.

  • edm.exe service (the remote debug device monitor) not starting up.
     - This could be either a bad datastore as explained in an earlier blog OR
     - Due to a missing type map entry in the global datastore (C:\Documents and Settings\All Users\Application Data\Microsoft\corecon\1.0\addons or equivalent)  file Microsoft.TypeMaps.8.0.xsl . 
        You can double check this by quickly running the following snippet on the device.
    hmod = LoadLibrary(TEXT("coredll.dll"));
        if (hmod != NULL)
        {
            BOOL (*QueryInstructionSetFunc)(DWORD, DWORD*) = (BOOL (*)(DWORD, DWORD*)) GetProcAddress(hmod, L"QueryInstructionSet");

              if (QueryInstructionSetFunc != NULL)
                  QueryInstructionSetFunc(PROCESSOR_QUERY_INSTRUCTION,
                                       &instructionSet);

                  FreeLibrary(hmod);
              }

and then verifying if the instructionset is present in Microsoft.TypeMaps.8.0.xsl.

The workaround here would be adding an equiavalent entry in the global datastore. However this needs be done with utmost care. So better backup the globa datastore before doing the same. We know one entry which is missing currently....84017153 during one of our customer interactions. More details on this in subsequent blogs.

  • ICordbg.dll not being registered properly due to an unknown bad installation. This is for the managed case only. Check for the InproceServer32 registry entries  at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{83F64ACD-26BF-4FFE-87A8-43AE2C9872E3}
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{48C2DAF2-F746-41D8-B0A9-D8FE3A0753BB}

           and ensure that icordbg.dll is infact present at the given path.

 The workaround here would be to do regsvr32 icordbg.dll. However this should not be the normal case and we would love to hear why you are hitting it for root cause analysis.