Srini

Breakpoints not getting hit during NET CF Device Debugging...

SriniNa — Thu, 22 Nov 2007 09:46:00 GMT

We have seen a lot of customers reporting the fact that sometimes the breakpoints are not getting hit and the connection to the device is lost popping the error dialog "The connection to the device is lost ...", while debugging a NET CF V2 application using VS 2005. This issue has been traced to a code defect and has been fixed in NET CF V2 SP2.

Hope that helps and also please keep sending feedback.

Reporting F5 experience to Visual Studio for Devices Team: Debug the Device Debugger.

SriniNa — Thu, 07 Sep 2006 09:56:00 GMT

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:

Is Connect to Device working (VS->tools->connect to Device)?
Is Ctrl F5 scenario working (start without debugging)?
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.

Addendum

SriniNa — Thu, 05 Jan 2006 14:57:00 GMT

Let me also add that the below issue is very sporadic and not a common one.

"Unable to Start debugging" with VS 2005 issue

SriniNa — Thu, 05 Jan 2006 14:46:00 GMT

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.

Useful pointers

SriniNa — Tue, 27 Dec 2005 09:01:00 GMT

In VS 2005, VSD does not support Seamless "Mixed mode" debugging a.k.a interop debugging. However this is being actively considered for future releases of VS and .NET CF.

However if you need to debug a solution that includes both Managed and Native Code check out the following walkthroughs.

http://msdn2.microsoft.com/en-us/library/ms228818.aspx

http://blogs.msdn.com/davidklinems/archive/2005/06/02/424595.aspx

Stay tuned!

Srinivas N

About two cool device debugging features in VS 2005

SriniNa — Wed, 19 Oct 2005 14:50:00 GMT

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

Key component in VSD Managed Debugging : icordbg.dll

SriniNa — Wed, 05 Oct 2005 11:20:00 GMT

Visual Studio 2005 debugger component cpde.dll (debug engine) hosts components which implement ICorDebug, the managed debugging API.
(For details refer ICorDebug blogs at http://blogs.msdn.com/jmstall).

This API is implemented in mscordbi.dll for Managed Debugging of desktop applications in Visual Studio.

Before we get into VSD specific details let me briefly summarize the essence of managed debugging.

Managed debugging is implemented entirely by the run time. There is a special thread (called the Helper thread) in every managed process that services requests from the managed debugging API (ICorDebug interfaces). Managed debugging is an In-Process model. The helper thread must be present and running in the debuggee’s process in order for managed-debugging to function.

Having said that, the key things that differentiate Visual Studio for Devices (VSD) Managed Debugger with the Desktop debugger is the following two facts
- VSD Managed Debugging is always remote debugging. That is the debugee process is not running on the desktop where the debugger process (devenv) is running. The debuggee process runs either on the emulator or on the device.
- VSD Managed Debugging invloves .NET Compact Framework runtime whereas for the desktop world it is CLR. Hence we cannot equate remote debugging of a desktop application with that of VSD Managed Debugging even at 10000 feet height considering that managed debugging follows a in-proc model.

The actual implementation of the VSD managed debugging API sits in icordbg.dll. As mentioned above, icordbg.dll interacts directly with the .NET CF running process which spawns and runs the debuggee helper thread.

That much for the brief introduction. Stay tuned for further details on end to end story of F5 in Managed Debugging.

I am in !

SriniNa — Thu, 15 Sep 2005 12:42:00 GMT

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.