Post Mortem Debug of Windows Mobile with Visual Studio 2005

We saw on the previous post on Post Mortem debugging, the way to open KDMP files with WinDbg. But those system dump files can also be loaded using Visual Studio 2005 (and higher).

First step : Configure your device
Just follow the instructions in the previous post for the configuration of you Windows Mobile device (registry configuration to specify the location of the kdmp files).

Second step : Locate and copy the kdmp files
Locate the kdmp files on your device and copy it to your Development machine.

Third step : Open the kdmp file and run debugger
From VS2005, go to File -> open project/solution, and select the kdmp file.

Then go to Debug -> Start menu or hit F5 key, this will launch the debugger locally. The exception is then catch, and the assembly source code is shown.

At this time, the debugger is not able to make the link between the binary and the source code, as the symbols are not set. For this show the modules by going in Debug -> Windows -> Modules menu (screen must looks like the screen shot above). Select the module on which the exception occurs in our case it MemException.exe, right click on it and select the "Load Symbols" popup menu.
Provide the path to the pdb files and TAADAAA the source code is displayed.



Have a good debugging then...

- Nicolas

IE8and Smart Device project issues

The Visual Studio team have blogged about an issue with Visual Studio 2005/2008 after installing IE8 (Here’s a link to the blog article). You can have this issue when creating a Smart Device project in Visual Studio 2008, the fix is very simple, a change to your desktop registry.

- Nicolas

Debugging Windows Mobile devices

Another boring notification while debugging Windows Mobile devices, is linked to the default security level of the OS. On every start of the debugger, VS2005 launch required applications on the device that are not digitally signed, so device warn you.
One solution to disable those warning messages, is to disable and change the security level. Of course this will completely remove all the security on the device... so make sure to revert your changes after debugging process to avoid any damages on your device.
On the device you have to set the following :
[HKEY_LOCAL_MACHINE\Security\Policies\Policies]
"00001001"=dword:1
"0000101a"=dword:1

- Nicolas

Smart Device deployment and debugging using VS2005

When developing smart device application, in C# or C++ (Win32 or MFC) using Visual Studio 2005, you have different solutions for the deployment and debugging of your application.

ActiveSync :

This is the easiest way as it just required the support of ActiveSync in your Run Time image and a Serial or USB Function interface correctly setup. When connecting the device to you development computer ActiveSync should start and connect to the device. VS2005 is setup to use the ActiveSync link automatically for the deployment and debugging. No particular actions are required for this connection type.

KITL :

If you have the chance to have a KITL connection between the device and Platform Builder, you can directly use this connection with another instance of VS2005.

Pre-requisite

Before been able to use the KITL connection from VS2005, you have to create and setup a device configuration. To do so you have to open the Connectivity Options window in the VS2005 instance running the Platform Builder plug-in. Use the Create Device button to add a new device to the list of devices identified by Platform Builder. Associate this new device to an SDK if you got one or to the Generic Platform Builder OSDesign in the drop list as shown bellow.

Then select this new device and setup the Transport and Download information as you are usually doing it with your target device. Then attach and download the Runtime image to the target. This VS2005 instance will be use to debug the OS, and not your application. You will be able to add break point in the drivers and/or OAL.

Connect

In the second VS2005’s instance start/load your application solution and go to the Tools menu followed by Options then Device Tools group, select Devices, select the device created previously in the list and edit the Properties. Check that the Transport configuration is KITL. Validate all the open windows and close.

Now your system is ready to deploy and debug your application on the device using the KITL layer.

Corecon :

Corecon use the network interface to communicate with Visual Studio and requires to launch two applications on the device, but before you need least the following files on your device:

• clientshutdown.exe
• CMAccept.exe
• ConmanClient2.exe
• DeviceDMA.dll
• eDbgTL.dll
• TcpConnectionA.dll

Those files can be directly integrated in the nk.bin using the project.bib file or copied on the device at runtime using USB flash key or FTP connection.

Those files are not provided directly with the Windows Embedded CE 5.0/6.0 development environment, but are located in the VS2005 folders in the folder :

c:\Program Files\Microsoft Shared\CoreCon\1.0\Target\wce400\ProcessorType\

Binary versions are available for all processors supported by WinCE (ProcessorType).

Pre-requisite

The two applications, CMAccept and Conmanclient2 have to be launched manually when a connection to VS2005 is required. To do so you have to get a way to launch them, using the explorer window on the device, or using a telnet connection. You will also need the IP address of your device to correctly setup VS2005 connection. Without this IP address VS2005 would not be able to connect to the device.

Launch and connect

Under VS2005 you have to select and edit the device connection property by going to the menu Tools followed by Options then Device Tools group, select Devices, select the device in the list and edit the Properties.

In the Properties window select the Transport as TCP Connect Transport and then Configure. In the Configure window check the Use Specific IP address andx enter the IP address of the device. Validate all the open windows and close.

On the device you have to launch the ConmanClient2 application, followed by CMAccept. At this time you have approximately 3 minutes to connect the VS2005/2008 instance with your target. Elapsing this time you will have to launch the CMAccept application again before trying to connect.

In the VS2005, select the device in the device drop box list and click on Tools followed by Connect To Device. The connection may succeed and you should be able to start the deployment and/or debugging.

Those three configuration are using different communication layers but will provide the same set of functionalities for the deployment and debugging of Smart Device applications.

[Updated on 02/19/2008]
For the Windows Mobile user, to get all the steps for those platforms, you can check out the article on the Fabien blog.

- Nicolas

Automatically add files to an SDK

When building an SDK using Platform Builder 6.0 (and previous), you may need to include your own files. Those files are the list of IOcontrols of drivers you implemented, or header files required to link to a new library that you want to provide in your SDK. In that case you have to include those files to your SDKs.

The first one is a manual inclusion of those files using the configuration wizard of the SDK. That’s mean that every time you generates the SDK you have to take care of those files.
The second solution is to automated this mechanism by copying those files to a specific folder that will be used automatically by the wizard during the generation of the SDK.

Identification of the sdk folder :

The SDK tool uses the content of the cesysgen folder (located in your OSDesign folder), and the sdk folder located in the same folder as the cesysgen and OAK folder.

$(_PROJECTROOT)\sdk or $(_PROJECTSDKROOT)

The SDK tool adds the content of the sdk\Inc and sdk\Lib folder to the SDK msi file. So you must store the files you need to provide with the SDK in those sub folders. Doing it manually is never the solution, so by asking the Windows embedded CE build environment to do it, it is more reliable. This could be done during the build of those libraries or drivers.

Add an automated task :

Using the sources files you can add dependencies and enable automated task for the build engine. You could also use the postlink macro, but this is not the purpose of this article.
In the sources file add the following lines :

#------------------------------------------------------------------------------
# SDK files
#------------------------------------------------------------------------------
# Enable copy to the SDK directory
WINCETARGETFILES=$(WINCETARGETFILES) CopyFilesToSDK
SDK_FILES=gpio_iocontrol.h driverheadertoshare.h

Any target files that you specify using WINCETARGETFILES are added to the list of dependencies that must be satisfied to generate a successful build. Also by listing the files you need for your SDK in the SDK_ FILES variable, you will generate a list actions that will be solved later in the makefile.inc.
In association to the sources file you must provide a makefile.inc (located in the same folder), this file is proceeded after your sources files during the build. In this file you must satisfy the dependency list, so it must contain information about the CopyFilesToSDK.

Makefile.inc content will be something like this :

CopyFilesToSDK:
#REM copy the files listed in SDK_FILES to $(_PROJECTSDKROOT)
....

The copy will be done in batch script language and executed by the build engine.
After the build of the driver or the library, you may find all your required files in the $(_PROJECTSDKROOT) folder.
In this article I described only one list of files to be proceeded, but it make sense to have two lists, one for the header files and the sdk\Inc folder and another one for the sdk\Lib folder for the libraries.

-Nicolas

Error while opening pbxml file

If you have the following error while opening a Windows Embedded CE 6.0 OSdesign, that means that in the path to this OSDesign there is a space character.

Platform Builder reported an error while trying to load the OS design file:
System.ArgumentException: Invalid characters in path.
The OS design could not be loaded.

The solution is to remove this or those space characters from the path to your OSDesign files, by simply removing the space or replacing the space by an underscore (_). Usually OSDesign files are located inside the OSDesign subfolder of the WINCE600 folder. By default the WINCE600 is located at the root on the C hard drive.

Do not move your OSDesign to your desktop, as this one is located in C:\Documents and Settings\user name\Desktop, and this path contains a space !!


- Nicolas

VS2005 and square selection

To make a square selection under Visual Studio 2005, use the Alt key and your mouse.


- Nicolas

Windows CE QFE's

Every month the Windows Embedded team is realizing Quick Fix Engineering (QFE) to fix some software issues for Windows CE 5.0 and Windows Embedded CE 6.0.
Those patches have to be installed on your development computer. So you have to regenerate your Windows CE binary image to integrate those new improvements in your device. Every year all the QFE's are grouped into one single MSI file to reduce the time spent to install those QFE's on a clean computer.
So do not forget to update your development computer every month :-)

All QFE are available from the Microsoft website
- Nicolas

Windows CE 6.0 and SDKs

Every time you have to develop an application using VS2005 for Windows CE devices (smart devices) you have to generate the SDK associated to the OSDesign used to generate the current Windows CE binary image.
The SDK contains all the API enabled by selecting components in the OSDesign for the Common component and specific components (drivers, BSP applications, ...). Those APIs will be available in you VS2005 project, so the compiler will be able to build your application. This protect you on the usage of unsupported API by your Windows CE Image, in that case checking is done a build time and not at runtime.
Under VS2005 development environment they are some restrictions, that will be solved in the future by Microsoft (Hope so !). You must add the following components to your OSDesign, even if you do not need those functionalities :

• AYGShell API Set
• Windows Networking API/Redirector (SMB/CIFS)

Otherwise you will have that kind of error during the build :
fatal error C1083: Cannot open include file: 'winnetwk.h': No such file or directory

-Nicolas

Remote Tools Framework for Windows CE

You want to use the Remote Tools but you do not want to install Platform Builder 6.0 extension, on your computer. So the Remote Tools Framework for Windows CE is the solution to your need.
That Framework also provides tools and facilities to implement your own Remote Tools.

[Update 7/12] : You still need to install Visual Studio 2005 to use the framework

- Nicolas

Remote Tools, ARM processor and Windows CE 6.0

You are using an ARM processor, ActiveSync, and the Remote Tools are not working with your device...
Then you are reading the right article !
Lots of users want to use Remote Tools using ActiveSync, but the connection always fails. Why ?

Remote Tools launched from Platform Builder 6.0 are using platman (Platform Manager) over ActiveSync to connect your device, when platman starts, it asks Windows CE to return the processor type, through a KernelIoControl, to download the right binary file to the device (client side of the tool). In the case of the ARM processor, Platform Manager do not seem to identify correctly the ARMV4i processor type, but identify ARMv4 instead. Therefore the tool cannot copy the right files to your device. The files used by the remote tools are located in C:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\target\wce600\. Each sub folders contains the binary version for a specific processor familly (x86, ARMV4i, ....)
As there is no ARMv4 subdirectory, platform manager cannot copy the right file to the platform. The workaround to solve this issue is to duplicate your ARMV4I folder to ARMV4 one, and then, TADAAAA, it works !

- Nicolas

Windows CE 6.0 remote tools over activesync workaround

A lot of Windows CE 6.0 users have troubles with activesync and remote tools, they can't connect to a Windows CE device to use their favorite remote tool.

There are some pre-requirement for using the remote tools.

1. Add the 'C++ Runtime Support for Exception Handling and Runtime Type Information' component to your OSdesign
2. Use the remote tools not from the VS2005 menu but from the 'Start Menu' in Progams -> Microsoft Visual Studio 2005 -> Visual Studio Remote Tools
3. Open your favorite remote tool, and go to the Target -> Connectivity Options ... menu
   
4. Select the Platformbuilder entry and edit the properties
5. Set- Transport to TCP Connect Transport - Startup Server to Activesync Startup provider
6. Validate and connect to the device using that entry.