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.

 

We are hearing some reports of VSD debugger popping up "Unable to start debugging" dialog sometimes on customer boxes trying to debug with Win CE 5.0 device. We are suspecting this to be a issue with side by side installations_and_usages of PB and VS 2005. When this happens on the customer box, he is however able to connect to the device and deploy the files normally.

The current workaround is to delete the data store entries conman_ds_* from %userprofile%\Local Settings\Application Data\Microsoft\CoreCon\1.0. Do remember to backup this directory as a safety measure before deleting the entries.

We are trying for a consistent repro. Anyone hitting on it and willing to share the repro steps please mail me.

Stay tuned for more updates.

 

In this blog, I shall touch upon two important and cool features in VS 2005 device debugging.

Feature1: Attaching to NET CF V2 process

VS 2005 allows for attaching to a NET CF V2 process running on the device/emulator. This is disabled by default for performance reasons.To enable it one needs to set the value AttachEnabled to 1 at HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\.NETCompactFramework\Managed Debugger

 

Couple of notes:

-Any NET CF V2 process started after the above setting is attachable.

-Processes started before enabling are still not attachable.

-This is applicable only to V2 processes. This feature is not available for V1 processes.

-The feature can be disabled by setting the value AttachEnabled to 0.

 

https://blogs.msdn.com/davidklinems/archive/2005/05/24/421566.aspx talks in detail about this feature. So I would not want to duplicate the facts.

 

Feature2: Just In Time (JIT) debugging is an all powerful paradigm. Visual Studio 2005 provides infrastructure to do native JIT debugging on devices.

The way this is enabled is

- Go to <VS Install Directory>\SmartDevices\Debugger\target\wce400\cpu (for example, cpu is ARMV4i for Windows Mobile 5.0). 
- Copy eDbgJit.exe to the \windows folder on the device. 
- Start the executable file. This will enable the JIT debugging (if you are running on a device with a CE OS version < 5.0 you need to soft reset as well)

 

Assume now you have started a native application on the device and then it crashes for some reason. Then you would be prompted with a dialog whose contents should look like

An unhandled exception

was raised in "exe path +name"

(process id = xxxxxx)

To debug attach with

Visual Studio

To terminate, click OK.

 

Happy debugging !

 

Thanks

Srinivas N

 

This is my first official blogging experience and that explains the topic.

Let me introduce myself before getting into anything techie. I am Srinivas N working as a developer for the Visual Studio for Devices (VSD) team  where I currently drive the Managed Debugger effort and as well contribute to the Native Debugging story .

My current planning for this blog space is to provide commentary on the debugging story for VSD team: how the debugger differs from the desktop debugger, why it is designed the way it is and so on. I hope this blog would also serve as a useful platform for interfacing with the VSD customer issues.

Apart from this I would also like to pen on one of my favorite (does not necessarily mean that I am expert at it :-)) topic: tools for increasing the productivity at work, in particular debugging.

Recently I got a chance to contribute in a deceptively tricky bug in VS. The issue was that of a crash in different components of VS at various stages of using the VS due to a cycle of events from the user. This resulted in Watson dumps in different components . The call stack in some of the Watson dumps had ntdll.dll:"RtlpAllocateHeapLookaside" and I immediately suspected this could be a possible heap corruption based on my past experience. The non-deterministic nature of the crash was another key hint. I have learnt from Rich Hanbidge that using NT “Page Heap”  offers the quickest way to debug heap corruption issues. gflags tool can be used to enable page heap verification. Once I monitored the user scenario with this, the function causing heap corruption was identified. The issue was that of double free triggered as part of handling a CANCEL event from the user. Reverse engineering from the code gave us a consistent repro scenario for the crash to happen.

I believe the way heap corruption is detected by such tools is by having a verification/validation layer between the application and the system so that all the dynamic memory operations of the application can be monitored.

Can't imagine life without such tools! Stay tuned for more.